缓冲和削峰：上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。
解耦和扩展性：项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。
消息广播：可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。
健壮性：消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。
异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

(3) pull和push，Kafka支持哪种类型，为什么这么设计？

和RabbitMQ不同的是，Kafka只支持pull模式。原因是为了防止push模式下，消息生产速度和消费速度不匹配时，大量的消息堆积在Consumer端导致的服务不可用。

(4) kafka 为什么那么快

Cache Filesystem Cache PageCache缓存
顺序写由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。
Zero-copy 零拷技术减少拷贝次数
Batching of Messages 批量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。
Pull 拉模式使用拉模式进行消息的获取消费，与消费端处理能力相符。

(5) Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么

AR:Assigned Replicas 所有副本

ISR:In-Sync Replicas 副本同步队列

ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度，当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR，存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。

AR = ISR+OSR。

(6) kafka中的 zookeeper 起到什么作用，可以不用zookeeper么

zookeeper 是一个分布式的协调组件，早期版本的kafka用zk做meta信息存储，consumer的消费状态，group的管理以及 offset的值。考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖，

但是broker依然依赖于ZK，zookeeper 在kafka中还用来选举controller 和检测broker是否存活等等。

(7) kafka follower如何与leader同步数据

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据，kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

(8) 什么情况下一个 broker 会从 isr中踢出去

leader会维护一个与其基本保持同步的Replica列表，该列表称为ISR(in-sync Replica)，每个Partition都会有一个ISR，而且是由leader动态维护，如果一个follower比一个leader落后太多，或者超过一定时间（一般30秒）未发起数据复制请求，则leader将其重ISR中移除。

(9) kafka producer如何优化消息发送速度

增加线程
提高 batch.size
增加更多 producer 实例
增加 partition 数
设置 acks=-1 时，如果延迟增大：可以增大 num.replica.fetchers（follower 同步数据的线程数）来调解；
跨数据中心的传输：增加 socket 缓冲区设置以及 OS tcp 缓冲区设置。

(10) kafka producer 消息确认机制是什么？

1（默认）数据发送到Kafka后，经过leader成功接收消息的的确认，就算是发送成功了。在这种情况下，如果leader宕机了，则会丢失数据。
0 生产者将数据发送出去就不管了，不去等待任何返回。这种情况下数据传输效率最高，但是数据可靠性确是最低的。
-1 producer需要等待ISR中的所有follower都确认接收到数据后才算一次发送完成，可靠性最高。当ISR中所有Replica都向Leader发送ACK时，leader才commit，这时候producer才能认为一个请求中的消息都commit了。

(11) kafka unclean 配置代表啥，会对 spark streaming 消费有什么影响

unclean.leader.election.enable 为true的话，意味着非ISR集合的broker 也可以参与选举，这样有可能就会丢数据，spark streaming在消费过程中拿到的 end offset 会突然变小，导致 spark streaming job挂掉。如果unclean.leader.election.enable参数设置为true，就有可能发生数据丢失和数据不一致的情况，Kafka的可靠性就会降低；而如果unclean.leader.election.enable参数设置为false，Kafka的可用性就会降低。

(12) 如果leader crash时，ISR为空怎么办

kafka在Broker端提供了一个配置参数：unclean.leader.election，这个参数有两个值：

true（默认）：允许不同步副本成为leader，由于不同步副本的消息较为滞后，此时成为leader，可能会出现消息不一致的情况。
false：不允许不同步副本成为leader，此时如果发生ISR列表为空，会一直等待旧leader恢复，降低了可用性。

(14) kafka中consumer group 是什么概念

同样是逻辑上的概念，是Kafka实现单播和广播两种消息模型的手段。同一个topic的数据，会广播给不同的group；同一个group中的worker，只有一个worker能拿到这个数据。

换句话说，对于同一个topic，每个group都可以拿到同样的所有数据，但是数据进入group后只能被其中的一个worker消费。group内的worker可以使用多线程或多进程来实现，也可以将进程分散在多台机器上，worker的数量通常不超过partition的数量，且二者最好保持整数倍关系，因为Kafka在设计时假定了一个partition只能被一个worker消费（同一group内）。

(15) Kafka中的消息是否会丢失和重复消费？

要确定Kafka的消息是否丢失或重复，从两个方面分析入手：消息发送和消息消费。

1、消息发送

Kafka消息发送有两种方式：同步（sync）和异步（async），默认是同步方式，可通过producer.type属性进行配置。Kafka通过配置request.required.acks属性来确认消息的生产：

0---表示不进行消息接收是否成功的确认；
1---表示当Leader接收成功时确认；
-1---表示Leader和Follower都接收成功时确认；

综上所述，有6种消息生产的情况，下面分情况来分析消息丢失的场景：

（1）acks=0，不和Kafka集群进行消息接收确认，则当网络异常、缓冲区满了等情况时，消息可能丢失；

（2）acks=1、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；

2、消息消费

Kafka消息消费有两个consumer接口，Low-level API和High-level API：

Low-level API：消费者自己维护offset等值，可以实现对Kafka的完全控制；
High-level API：封装了对parition和offset的管理，使用简单；

如果使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就“诡异”的消失了；

解决办法：

针对消息丢失：同步模式下，确认机制设置为-1，即让消息写入Leader和Follower之后再确认消息发送成功；异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；、

针对消息重复：将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。

(16) 为什么Kafka不支持读写分离？

在 Kafka 中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，从而实现的是一种主写主读的生产消费模型。

Kafka 并不支持主写从读，因为主写从读有 2 个很明显的缺点:

1、数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X，之后将主节点中 A 的值修改为 Y，那么在这个变更通知到从节点之前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题。
2、延时问题。类似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程需要经历网络→主节点内存→网络→从节点内存这几个阶段，整个过程会耗费一定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时，它需要经历网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。

(17) Kafka中是怎么体现消息顺序性的？

kafka每个partition中的消息在写入时都是有序的，消费时，每个partition只能被每一个group中的一个消费者消费，保证了消费时也是有序的。

整个topic不保证有序。如果为了保证topic整个有序，那么将partition调整为1。

(18) 消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1?

offset+1

(19) 分区Partition的作用是什么？

当Topic压力比较大的时候，会有和单体应用同样的问题：

在高并发时性能下降非常快。所有客户端都要连到同一个Topic进行消息收发，必然会给Topic带来很大压力，性能会大大下降。
很难扩展。如果Topic处理能力或者存储能力不足，需要扩展时，只能垂直升级硬件，无法横向扩展。

Kafka通过Partition(分区)来解决这个问题，一个Topic可以被划分成多个分区，每个分区可以对外单独提供消息服务能力，这也是分片思想的落地。Partition类似于mysql的分库分表，为了达到横向扩展和负载均衡的目的。

一个Topic的不同Partition可以分布在同一个Broker，也可以通过搭建Broker集群部署在不同Broker（横向扩展）。

同一批消息在同一个Partition中能够保证顺序性，Kafka中的消息被消费后不会删除，通过Offset来记录消费位置，消息是被顺序追加到Partition中。

每个Topic在创建时默认至少有一个分区。

(20) 分区数和副本数是怎么设置的？

 ./kafka-topics.sh --create --zookeeper ip:2181 --replication-factor 1 --partitions 1 --topic mypartition

partitions就是指定分区数，replication-factor是指定副本数。

(21) 生产者发送消息如何选择分区？

1、显示指定partition；

2、自定义分区器，指定分区算法，根据发送信息计算分区；

3、使用Kafka默认分区器，基于对key的hash，然后对partition数区域获取位置；

4、使用Kafka轮训分区器，基于一个自增变量，然后对partition数区域获取位置，达到一种轮训的效果；

(22) Kafka消息的主要物理存储文件有哪些？

Kafka以Topic的partition为单位，通过日志文件的形式存储持久化数据。为了防止日志文件过大引起的效率问题，Kafka对文件进行分段，称为Segment。

Segment数据文件分为3个，.log、.index、*.timeindex，这三个文件是成套出现的。

除了Segment的3个数据文件外，leader-epoch-checkpoint文件用于记录每一任Leader上任时开始写入消息的offset。

(23) Kafka有哪些索引类型？消息怎么通过索引进行检索？

Kafka索引分为两种：*.index为根据偏移量记录的索引，*.timeindex为根据时间戳记录的索引。

*.index为稀疏索引，并不是每条消息都有索引记录，索引名称包含了当前索引文件开始的offset。在检索时根据offset先找到文件，然后再文件中找到稀疏索引的区间（二分法），在轮训区间内的消息获取数据。

*.timeindex是记录了时间戳和Offset对应关系，根据时间戳可以找到对应的Offset。

(24) Kafka的稀疏索引间隔是由什么决定的？为什么不用B+树？

稀疏索引间隔是由消息的大小控制的，默认是4KB，由参数log.index.interval.bytes控制。只要写入消息超过4KB，偏移量索引和时间索引都会插入新纪录。

(25) Kafka的日志文件过大时，可以通过哪些方式释放磁盘空间？

Kafka支持两种数据清理策略：直接删除或者压缩文件。

Kafka有负责删除文件定时任务，默认5分钟运行一次。通过参数配置可以删除/压缩的时间段。

(26) Kafka副本Leader是怎么选举的？

首先Broker负责竞选Controller，看谁能够在ZK上先创建/controller节点。

Controller选举出来后负责副本的选举，默认的选举策略非常简单，序号最小且在ISR中成为Leader。如果ISR为空，则要看参数书否允许在OSR中竞选，如果允许则从OSR中选Leader，可能会存在数据丢失。如果不予许从OSR竞选，则等待Leader恢复。

(27) Kafka副本的主从同步机制是什么？

Follower节点向Leader节点发送一个fetch请求，Leader根据当前Follower的LEO发送需要同步的数据，然后更新当前Follower的LEO。
Follower接收数据，完成消息写入，并更新自身LEO。
Leader更新HW（维护的ISR中最小LEO）。

(28) Kafka的Offset是怎么维护的？

1、Offset存储

早起Kafka将offset维护在zk中，但是读写频率高，性能损耗太大。后来是将它维护在一个特殊的Topic中，名为__consumer_offsets，默认有50个分区，每个默认默认1个replica。

__consumer_offsets主要负责存储两种对象：

GroupMetadata：保存了消费者组中各个消费者信息（每个消费者都有编号）。
OffsetAndMetadata：保存了消费者组和各个partition的Offset数据

2、Offset更新

Consumer消费之后，通过自动/手动发送消费确认给Broker后，Offset会被更新。

PT2 参考资料

在整理Kafka学习笔记过程中，参考了以下大佬的资料。

Kafka 中文文档 - ApacheCN

kafka源码解析之一kafka诞生的背景_wl044090432的博客-CSDN博客_kafka源码解析

kafka-producer参数详解_鸭鸭的博客-CSDN博客_kafkaproducer参数

原来 8 张图，就可以搞懂「零拷贝」了 - 知乎

以上是关于10 Apache Kafka补充的主要内容，如果未能解决你的问题，请参考以下文章

10 Apache Kafka补充

Apache Kafka 架构和相关概念

kafka使用Apache Kafka构建可靠的再处理和死信队列

Kafka实践升级和新版本（0.10）特性预研

换个角度看Apache pulsar

Flume 实战，将多台机器日志直接收集到 Kafka