kafka学习总结 2020-12-16

一:kafka拓扑图

v2-0aff32c61db94ed711940f5ec4c0175d_720w.jpg

v2-e9cfea7a6bc987cb5615c746a8d44ff3_720w.jpg

二:Kafka 精准一次性语义

1. 数据不丢失(可靠性): 分3部分分析- 生产者,kafka集群,消费者

   1. 不丢失可能需要重试,重试可能会导致重复,使用幂等(唯一id)解决可能的重复生产问题

   2. ack应答机制

   3. 幂等,事务

2. 数据不重复(准确性): 分3部分分析- 生产者,kafka集群,消费者

   1. 消费者先处理消息再提交offset,可能会导致重复消费(消费者提交offset和处理消息,这两个操作需要实现事务,保证消费不丢失不重复的精确消费一次语义)

   2. 自动提交(enable.auto.commit=true),这种方式也被称为【at most once】，fetch到消息后就可以更新offset，无论是否消费成功;

   3. 手动提交(enable.auto.commit=true),这种方式称为【at least once】。fetch到消息后，等消费完成再调用方法【consumer.commitSync()】，手动更新offset；如果消费失败，则offset也不会更新，此条消息会被重复消费一次

   4. 手动提交+消费者分布式存储消费的offset做校验,实现:可以获取到消息后与本地存储的offset做校验,避免重复消费

   5. 消费逻辑:获取消息->校验->消费消息->手动ack应答&保存消息键 ::: 以此保证消费不丢失不重复

3. 高可用性: follow副本仅同步Leader数据,不对外提供服务,除非重新选举成了Leader

4. 一致性: 若某条消息对client可见，那么即使Leader挂了，在新Leader上数据依然可见。

5. ISR(同步副本集):

   如果follower与leader之间超过10s内没有发送请求，或者说没有收到请求数据，此时该follower就会被认为“不同步副本”。而持续请求的副本就是“同步副本”

6. Leader选举

7. 批量和缓冲的参数设置问题

8. 一个 Kafka的Message由一个固定长度的 header和一个变长的消息体 body组成

   message长度，值为1+4+N，一个字节的magic(文件格式 )，四个字节的CRC32位值(用于判断 body消息体是否正常 )，最终是N个字节的消息数据
   消息格式演进 v0 v1 v2 ; v0 最少26b v1 最少34b v2 改动大,单条更大,消息集压缩,平均下来会小很多

9. kafka的数据是落盘的,Partition中是数据存活时间超过参数值（log.retention.{ms,minutes,hours},默认是7天）的时候会进行删除

10. kafka 高吞吐: 操作系统页缓存+(0拷贝技术)+ 磁盘顺序访问+ 批处理

11. kafka如何实现高吞吐,低延时的设计目标:

• 大量使用操作系统页缓存,内存操作速度快切命中率高
• kafka不直接参与物理IO操作,而是由操作系统完成
• 采用追加写入方式,摒弃了缓慢的磁盘随机读写操作
• 使用sendfile为代表的0拷贝技术加强网络间的数据传输效率

三:副本更新机制

1. HW:高水位 consumer无法消费分区下leader副本中位移值大于分区HW的任何消息。这里需要特别注意分区HW就是leader副本的HW值。

2. 副本分为leader副本和follower副本，而每个副本又都有HW和LEO

3. LEO：即日志末端位移(log end offset)

   • 0.11之前副本备份机制主要依赖水位(或水印)的概念，而0.11采用了leader epoch来标识备份进度

   • 存在问题的原因:HW值被用于衡量副本备份的成功与否以及在出现failture时作为日志截断的依据，但HW值的更新是异步延迟的，特别是需要额外的FETCH请求处理流程才能更新，故这中间发生的任何崩溃都可能导致HW值的过期

   • Kafka有两套follower副本LEO(明白这个是搞懂后面内容的关键，因此请多花一点时间来思考)：1. 一套LEO保存在follower副本所在broker的副本管理机中；2. 另一套LEO保存在leader副本所在broker的副本管理机中——换句话说，leader副本机器上保存了所有的follower副本的LEO。

   为什么要保存两套？这是因为Kafka使用前者帮助follower副本更新其HW值；而利用后者帮助leader副本更新其HW使用

   注意:Broker重启回来后也会执行日志截断，将LEO更新为HW

   注意: follow 每次发送fetch请求到Leader 参数为 follow LEO 响应为:Leader HW 和Leader 待备份数据,参数follow LEO 用于更新Leader 中的follow副本LEO 触发Leader 更新Leader HW(Leader HW=min(Leader LEO,follow LEO)),响应Leader HW 用于比较follow LEO 更新follow HW(follow HW=min(Leader HW,follow LEO))

4. Kafka使用HW值来决定副本备份的进度，而HW值的更新通常需要额外一轮FETCH RPC才能完成，故而这种设计是有问题的。它们可能引起的问题包括：

   • 备份数据丢失

   • 备份数据不一致

5. 上述两个问题的根本原因在于HW值被用于衡量副本备份的成功与否以及在出现failture时作为日志截断的依据，但HW值的更新是异步延迟的，特别是需要额外的FETCH请求处理流程才能更新，故这中间发生的任何崩溃都可能导致HW值的过期

6. Kafka 0.11.0.0.版本解决方案 leader epoch :实际上是一对值：（epoch，offset）。epoch表示leader的版本号，从0开始，当leader变更过1次时epoch就会+1，而offset则对应于该epoch版本的leader写入第一条消息的位移

   [1] https://www.cnblogs.com/huxi2b/p/7453543.html

   ---

   Follower节点会定时的从leader节点上获取增量数据

   follower必须能够及时的将leader上的 writing复制过来，不能 “落后太多 ”

   ---

四:Leader 选举

1. Leader节点的切换基于 Zookeepe的Watcher机制,其他 ISR 中的 follower节点会竞争的在 zk 中创建一个文件目录 (只会有一个 follower节点创建成功 )，创建成功的 follower节点成为 leader节点

2. Kafka提供了一个 in -sync replicas(ISR)来确保 Kafka的Leader Leader选举

---