Kafka面试细节

为什么kafka性能非常高

1.使用到零拷贝技术 属于linux操作系统内核自带；参考文章
2.顺序读写

1. kafka 属于日志存储系统实际将消息直接追加在segment 后面，将一个大的日志文件拆分成n多个小不同segment 文件，在访问的时候就可以提高效率
2. 设计原理：segment 分段设计+稀疏索引算法（查找）
   不会对每个msg建立索引。

3.分区模型架构

1. 提高吞吐量
2. 动态的消费者扩容与缩容
3. 消息顺序一致性的问题 消息落地到同一个分区中，最终被一个消费者消费。在kafka中建议：相同分组中，每个分区对应一个消费者。分区为10的情况下，10消费者。
4. Kafka的消息key：告诉我们mq服务器端该消息应该存放那个分区中。所以同样地key可以分到同一个分区被同一个消费者消费，做到顺序消费

4.生产者投递消息 批量投递模型

1. Kafka生产者先将消息投递到Kafka缓冲区中，在批量的形式将消息压缩后投递到Kafka服务器端分区存放消息，减少带宽的占用。
2. Kafka采用分段segment 文件方式，写入segment log文件，此过程中会使用到顺序读写与零拷贝技术减少与内核切换的次数。
3. 消费者根据offset 指定获取broker中的消息，该消息不会立即从kafka中删除，采用定时删除策略。

5.消息压缩

1. 生产者先将消息投递给缓冲区 （Map集合 key=topic名称 value list集合（
   N条本地缓存消息））
2. （在投递消息之前会将该消息实现压缩，压缩在发送给kafka服务器端）----目的是可以
   减少服务器带宽的资源
3. 单独写一个send线程 定时或者实时批量形式获取缓冲区消息发送给kafka服务器端。

高可用

kafka采用副本机制算法，将数据会同步给其他broker存放一份，保证当前Broker如果宕机之后，可以在其他broker中快速恢复该副本数据。

副本的概念实际上是在分区层级下定义的，每个分区配置有多若干副本。所谓的副本，本质上就是一个只能追加写消息的提交日志，根据kafka副本机制的定义，同一个分区下的所有副本保存有相同的消息序列，这些副本分散的保存在不同的Broker上，从而能够对抗部分Broker宕机带来的数据不可用。

基本特性

1.高吞吐、低延迟：kakfa 最大的特点就是收发消息非常快，kafka 每秒可以处理几十万条消息，它的最低延迟只有几毫秒；

2.高伸缩性：每个主题(topic) 包含多个分区(partition)，主题中的分区可以分布在不同的主机(broker)中；

3.持久性、可靠性：Kafka 能够允许数据的持久化存储，消息被持久化到磁盘，并支持数据备份防止数据丢失，Kafka 底层的数据存储是基于 Zookeeper 存储的，Zookeeper 我们知道它的数据能够持久存储；

4.容错性：允许集群中的节点失败，某个节点宕机，Kafka 集群能够正常工作；

6.高并发：支持数千个客户端同时读写。

Kafka如何查找指定offset的Message的

每个Partition分成n多个不同segment file，segment file 默认的大小是为500MB，当如果达到该大小容量之后，开始创建一个新的segment file，以此类推，类似于ConcurrentHashMap1.7成将一个大的ConcurrentHashMap集合拆分成多个小的HashTable，每个segment对应两个文件，分别为.index索引和.log数据文件，
.log存储消息文件
.index存储消息的索引，定位.log文件中消息的位置
.timeIndex，时间索引文件，通过时间戳做索引

那么segment file命名规则是怎样的呢

长度为20个字符，不够用0填充，每个名字从0开始命名，下一个segment file文件的名字就是，上一个segment file中最后一条消息的索引值。在.index文件中，存储的是key-value格式的，key代表在.log中按顺序开始顺序消费的offset值，value代表该消息的物理消息存放位置。但是在.index中不是对每条消息都做记录，它是每隔一些消息记录一次，避免占用太多内存。即使消息不在index记录中，也可以根据稀疏索引采用二分查询来查询，范围也大大缩小了。以此提高Message的查询速率

如何查看Kafka日志和index文件

kafka-run-class.bat kafka.tools.DumpLogSegments --files 00000000000000000000.log
kafka-run-class.bat kafka.tools.DumpLogSegments --files 00000000000000000000.index

ACK 参数配置

0：Producer 不等待 Broker 的 ACK，这提供了最低延迟，Broker 一收到数据还没有写入磁盘就已经返回，当 Broker 故障时有可能丢失数据。

1：Producer 等待 Broker 的 ACK，Partition 的 Leader 落盘成功后返回 ACK，如果在 Follower 同步成功之前 Leader 故障，那么将会丢失数据。

-1（all）：Producer 等待 Broker 的 ACK，Partition 的 Leader 和 Follower 全部落盘成功后才返回 ACK。如果生产者投递消息到Leader 节点之后，已经将数据同步给每个Follower 节点完成之后，但是没有及时的响应ack给生产者的情况下，有可能会造成生产者会重发。

推荐使用参数1

ISR的机制实现原理

ISR分区副本数据集合，如果该副本数据能够与ISR能够建立连接的情况下，就会存放在该集合中，如果某个Follower 节点宕机之后，该副本数据就会从该ISR集合中剔除。如果Leader 节点宕机之后，就会从该ISR列表中选举一个新的Leader 节点。

副本选举实现原理

当Leader 副本宕机之后，会从ISR同步副本列表中剔除，取剩下ISR列表中第一个为Leader 副本，显然有可能还有些副本数据没有及时同步完成，当选择为Leader副本之后有可能数据会丢失。

数据恢复机制

Leo:该副本数据最后一个offset的位置，最大offset值。
Hw：高水位线 消费者能够消费最大的offset值

HW也就是所有副本中共同数据的最大offset值

1. 如果follower2节点宕机的情况下，从isr集合列表中剔除，突然follower2又启动起来了，如何同步leader节点数据？

   截取高于follower2 hw高水位线后面所有的offset消息，删除掉，在从该hw高水位位置开始同步leader节点数据。

2. 如果leader副本节点数据宕机了，从isr集合列表中剔除，此时follower1副本会成功选举为leader副本，之后原来的leader
   副本节点有启动起来了，在这时候做为follower副本同步新的leader副本数据会早成消息丢失

Kafka控制器原理

1.主题管理（创建、删除、增加分区）

指控制器帮助我们完成对 Kafka 主题的创建、删除以及分区增加的操作。换句话说，当我们执行kafka-topics 脚本时，大部分的后台工作都是控制器来完成的

2.分区重分配

分区重分配主要是指，kafka-reassign-partitions 脚本,提供的对已有主题分区进行细粒度的分配功能。这部分功能也是控制器实现的。

3.集群成员管理

自动检测新增 Broker、Broker 主动关闭及被动宕机。这种自动检测是依赖于前面提到的 Watch 功能和 ZooKeeper 临时节点组合实现的。比如，控制器组件会利用Watch 机制检查 ZooKeeper 的 /brokers/ids 节点下的子节点数量变更。

当有新 Broker 启动后，它会在 /brokers 下创建专属的 znode 节点。一旦创建完毕，ZooKeeper 会通过 Watch 机制将消息通知推送给控制器，这样，控制器就能自动地感知到这个变化，进而开启后续的新增 Broker 作业。

侦测 Broker 存活性则是依赖于刚刚提到的另一个机制：临时节点。每个 Broker 启动后，会在 /brokers/ids 下创建一个临时 znode。当 Broker 宕机或主动关闭后，该 Broker 与 ZooKeeper 的会话结束，这个 znode 会被自动删除。同理，ZooKeeper 的 Watch 机制将这一变更推送给控制器，这样控制器就能知道有 Broker 关闭或宕机了，从而进行“善后”。

4.数据服务

控制器的最后一大类工作，就是向其他 Broker 提供数据服务，控制器上保存了最全的集群元数据信息，其他所有 Broker 会定期接收控制器发来的元数据更新请求，从而更新其内存中的缓存数据。

选举原理

1.zookeeper底层核心：临时节点 当如果该会话连接关闭的时候，
该临时节点就会从zookeeper上被自动的删除，发送通知给其他订阅该
临时节点的客户端。临时节点特征：保证唯一不允许重复的，最终只会有一个Broker创建成功。有没有发现这和zookeeper实现分布式锁非常相似的。
2.多个不同的Broker创建相同的临时节点，谁能够创建成功 谁就是为Broker控制器（先到先得）创建临时节点失败的Broker，订阅该临时节点，如果当临时节点再宕机之后（即新的控制器角色），会发送事件通知给订阅了该节点的Broker重新开始竞争控制器角色。

分区中所有的副本统称为AR、所有副本保持同步统称为ISR.

消费者Rebalance机制（再平衡）

消费者消费记录存储位置

在kafkalog 日志文件 可以查看到 __consumer_offsets 默认的情况下分为50个文件夹，因为在以前的老版本 消费者消费的offset信息都记录在zookeeper上不适合于频繁的读写操作，所以新版本的kafka中已经将kafka消费的offset信息保存在 Kafka 内部Topic中。

存储的格式：

Key：group.id+topic+分区号，而 value 就是 offset 的值。
考虑到一个 kafka 生产环境中可能有很多consumer 和 consumer group，如果这些 consumer 同时提交offset ，则必将加重 __consumer_offsets 的写入负载，因此 kafka 默认为该 topic 创建了50个分区，并且对每个 group.id做哈希求模运算Math.abs(groupID.hashCode()) % numPartitions，从而将负载分散到不同的 __consumer_offsets 分区上。

Kafka性能优化

生产者默认的情况下在本地有一个缓冲区，默认的容量是为32MB，
一个batch存放n多条不同的消息，默认该batch容量16kb。

关于缓冲区的配置：

1. batch.size—抓取批量size 一次推送给kafka服务端消息数量，1.当我们的batch.size满了之后，自动会将该消息投递到mq中，那么如果消息过少呢，会不会不推送消息到服务端？可以加上该配置linger.ms 不管batch.size 是否容量有满，都会每隔该一定时间将该消息拉取给mq服务器端存放。

2. buffer-memory----缓存区容量 ， 生产者投递消息先存放在本地缓冲区中，将消息组装成n多个不同的Batch，在通过send线程将缓冲区的数据批量的形式发送给kafka服务器端存放，生产者本地内存缓冲区如果设置太小了，在高并发情况下有可能会发生内存溢出，导致生产者无法继续写入消息到缓冲区卡死，过大又会浪费内存，应该根据压力测试情况，合理设置内存缓冲区大小

3. num.replica.fetchers 拉取线程数 配置多可以提高follower的I/O并发度，单位时间内leader持有更多请求，相应负载会增大，需要根据机器硬件资源做权衡

4. replica.fetch.min.bytes=1 拉取最小字节数 默认配置为1字节，否则读取消息不及时

5. replica.fetch.max.bytes= 5 * 1024 * 1024 拉取最大字节数 默认为1MB，这个值太小，5MB为宜，根据业务情况调整

6. replica.fetch.wait.max.ms follow 最大等待时间

日志保留策略配置

生产者投递消息到kafka的mq中，消费者获取到消息之后不会立即被删除，
会有一个日志保留策略。

1. 减少日志保留时间，建议三天或则更多时间。log.retention.hours=72
2. 分段文件配置1GB， 默认是500mb 有利于快速回收磁盘空间，重启kafka加载也会加快(如果文件过小，则文件数量比较多，kafka启动时是单线程扫描目录(log.dir)下所有数据文件)，文件较多时性能会稍微降低。log.segment.bytes=1073741824
3. 当我们把数据写入到文件系统之后，数据其实在操作系统的page cache里面，并没有刷到磁盘上去。如果此时操作系统挂了，其实数据就丢了。
   1).每当producer写入10000条消息时，刷数据到磁盘 配置为：log.flush.interval.messages=10000
   2.)每间隔1秒钟时间，刷数据到磁盘。log.flush.interval.ms=1000

参考蚂蚁课堂