1、kafka靠什么赢得了青睐？
kafka靠它的高可用、高性能、高可靠赢得了青睐。
高可用：
1、broker集群机制
2、kafka多集群模式
3、分区副本及复制机制：kafka使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本，那么副本被保存在broker上，每个broker可以保存成百上千个属于不同主题和分区的副本。副本分为首领副本与跟随者副本，跟随者副本用来同步首领副本的消息，用做容灾处理，比如某个broker挂了，那么在此broker上的首领副本也不可用了，此时跟随者副本中所有同步副本（得到最新消息的副本称为同步副本）会进行首领选举，保证kafka的可用性。高性能:
1、kafka是分布式的：kafka是一个分布式的消息系统，其中producer-broker-consumer三者协同处理消息，各个模块可独立扩展。
2、kafka消息写入或读取都可以合并处理，消息写入时可以将一组消息写入kafka，一组消息就是批次。消息消费时，可构建消费者群组来进行消费消息。
3、kafka可通过分别扩展producer（生产者）、consumer（消费者）、broker（kafka服务）或topic（主题）、partiton（分区）来提高性能或生产消费速度。高可靠：
1、生产者：可以配置确认模式（ack）：
acks=0，代表如果生产者可以通过网络把消息发出去，那么就认为消息已成功写入kafka。
acks=1，意味着首领在收到消息并把它写入到分区数据文件（不一定写入到磁盘上）时会返回确认或错误响应。
acks=all，意味着首领在返回确认或错误响应之前，会等待所有同步副本都收到消息。
2、kafka会持久化消息吗？持久化到磁盘吗？如果持久化到磁盘会一直保留吗？
kafka会持久化消息，并持久化到磁盘，但是数据不会一直保留，kafka默认的保留策略为要么保留一段时间（默认为一周），要么保留一定的大小（默认1GB）。当消息达到这些上限时，旧消息就会过期并被删除。
kafka可以配置消息的保留策略，配置的最小粒度为主题，可以为某个主题定义消息的保留策略。
kafka通过两种配置来自定义消息保留策略:
一是配置消息的保留时间，配置参数有：log.retention.hours、log.retention.minutes、log.retention.ms，如果指定了多个参数，kafka会优先使用具有最小值的这个参数。通过时间来保留数据是根据磁盘上的日志片段的最后修改时间来的。最后修改时间就是日志片段的最后关闭时间，也就是文件里最后一个消息的时间戳。需要注意的是，移动分区的话，可能导致时间有误差。
二是通过设置保留的字节数，配置参数为：log.retention.bytes,作用在主题的每一个分区上，如果一个主题包括8个分区，此参数配置为1GB，那么此主题可保留8GB的消息数据。随着主题中的分区的增加，主题所能保留的数据也越多。
日志片段的关闭时间通过log.segment.bytes和log.segment.ms来设置，具体主题最终消息能保留多久，可以通过此公式得出。retentTime = 日志片段的关闭时间 + 消息配置的保留时间。
3、kafka到底能有多快的消息速度？它的性能关键取决于哪些点？
kafka是一个具备高吞吐的消息系统，它的速度达到每秒百万级。它的性能高的原因可归纳下面几点：
1、kafka是分布式的：kafka是一个分布式的消息系统，其中producer-broker-consumer三者协同处理消息，各个模块可独立扩展。
2、kafka消息写入或读取都可以合并处理，消息写入时可以将一组消息写入kafka，一组消息就是批次。消息消费时，可构建消费者群组来进行消费消息。
3、kafka可通过分别扩展producer（生产者）、consumer（消费者）、broker（kafka服务）或topic（主题）、partiton（分区）来提高性能或生产消费速度。
4、kafka怎么整合SpringBoot项目？
5、kafka会导致重复消费吗？会导致消息丢失吗？哪些场景下会发生重复消费？能避免重复消费吗？哪些场景下会发生消息丢失？能避免消息丢失吗？
会发生重复消费,有以下几个场景1、消费者提交偏移量，如果提交的偏移量小于客户端的最后一个消息的偏移量，那么处于两个偏移量之间的消息就会被重复消费。
发生原因：消费者自动提交偏移量（enable.auto.commit=true），那么每过5s（auto.commit.interval.ms默认为5s），消费者会自动把poll()方法接收到的最大偏移量提交上去。如果在3s时发生了一次rebalance（再平衡），此时各个分区会重新调整，消费者从最后一次提交偏移量的位置开始读取消息，这个时候偏移量已经落后了3s，这时3s内到达的消息将会被重复消费。此种情况不能完全避免重复消费。
还有一种场景，消费者用commitSync()或手动提交偏移量，此种如果忘记提交commitSync()或者在提交之前发生了rebalance，会发生重复消息的消费。消费者用commitAsync()手动提交偏移量，但此时是异步提交，异步提交不会一直重试，如果发生rebalance，也会发生重复消费。
2、重试发送一个失败的消息时，如果因为网络问题，生产者并没有收到broker的确认，但实际上消息已经写入成功，在这种情况下，消息会重复消费。
会发生消息丢失，有以下几个场景：1、当消费者用poll拉取消息后，用commitSync()进行提交偏移量成功后再进行消费消息，但在消费消息时，发生了rebalance，此时消息者将从最近的一次偏移量后继续消费，那么在消费者发生rebalance前消费消息的位置，到最近一次偏移量消息的位置，这中间的消息将被丢失。简洁来说就是在消息还没处理完时就提交了偏移量，下图中说明了此种情况。
避免重复消费和消息丢失的配置:
kafka本身支持“至少一次传递”，结合具有事务模型或唯一键特征的外部存储系统，kafka也能实现消息的“仅一次传递”。
6、kafka消息发送失败，会一直重试吗？
在生产者端可以配置消息重试的次数，配置参数为——retries，如果超过这个次数，生产者会放弃重试并返回错误，默认情况下，生产者会在每次重试之间等待100ms。当然这个参数也是可以配的，通过——retry.backoff.ms来配置重试间隔时间。
7、应用能从kafka里读取消息吗？包括已经处理的消息或者未处理的消息
应用肯定能从kafka读消息，因为消费先由生产者发送到broker中，然后消费者从broker读取消息。但是消费者是不能随意读取消息的，是根据消息的偏移量来的，kafka提供了从特定的偏移量处开始读取消息，或者从分区的起始位置或分区的结尾位置来读取消息的api，这些api可以灵活的让你向后回退几个消息、向前跳过几个消息。消息在kafka消费完之后，并不会马上删除，会根据配置再保存一段时间，所以这段时间内还是可以根据api来读取到之前的消息。
8、如果断电了，kafka怎么知道上次消息消费到了那一条呢？
通过偏移量来记录，在kafka中的每一个partition都有自己的一个最新的偏移量的记录，这个可以是消费者端自动提交的，也可以是手动提交的，偏移量是伴随着消费实时更新的，如果在broker未发现某个分区的偏移量，auto.offset.reset可以设置消费者读取的策略，当设置为earliest时，消费者会从分区的开始位置读取数据，不管偏移量是否有用。当设置为latest时，消费者会从分区的末尾开始读取数据。
9、kafka的Topic的默认Partition是多少个？
默认为1个，可以通过设置——num.partitions来指定创建的主题将包括多少个分区。我们可以增加主题的个数，不能减少主题的个数，除非你新建一个主题。
总结：
1、rebalance行为（分区的所有权从一个消费者转移到另一个消费者，这样的行为被称为再平衡），三种情况下会发生rebalance，第一种，当消费者群组里的消费者被关闭或者崩溃的时候，它就离开群组，原本由它读取的分区将由群组里的其它消费者来读取。第二种，当一个新的消费者添加进消费者群组时，它读取的是由其它消费者读取的消息，第三，当主题发生变化时，比如添加了新的分区，会发生分区重分配。
