一:kafka拓扑图
二:Kafka 精准一次性语义
-
数据不丢失(可靠性): 分3部分分析- 生产者,kafka集群,消费者
不丢失可能需要重试,重试可能会导致重复,使用幂等(唯一id)解决可能的重复生产问题
ack应答机制
<mark style="box-sizing: border-box; background: rgb(255, 255, 0); color: rgb(0, 0, 0); text-indent: 0px;">幂等,事务</mark>
-
数据不重复(准确性): 分3部分分析- 生产者,kafka集群,消费者
消费者先处理消息再提交offset,可能会导致重复消费(消费者提交offset和处理消息,这两个操作需要实现事务,保证消费不丢失不重复的精确消费一次语义)
自动提交(enable.auto.commit=true),这种方式也被称为【at most once】，fetch到消息后就可以更新offset，无论是否消费成功;
手动提交(enable.auto.commit=true),这种方式称为【at least once】。fetch到消息后，等消费完成再调用方法【consumer.commitSync()】，手动更新offset；如果消费失败，则offset也不会更新，此条消息会被重复消费一次
手动提交+消费者分布式存储消费的offset做校验,实现:可以获取到消息后与本地存储的offset做校验,避免重复消费
<mark style="box-sizing: border-box; background: rgb(255, 255, 0); color: rgb(0, 0, 0); text-indent: 0px;">消费逻辑:获取消息->校验->消费消息->手动ack应答&保存消息键 ::: 以此保证消费不丢失不重复</mark>
高可用性: follow副本仅同步Leader数据,不对外提供服务,除非重新选举成了Leader
一致性: 若某条消息对client可见，那么即使Leader挂了，在新Leader上数据依然可见。
-
ISR(同步副本集):
如果follower与leader之间超过10s内没有发送请求，或者说没有收到请求数据，此时该follower就会被认为“不同步副本”。而持续请求的副本就是“同步副本”
Leader选举
批量和缓冲的参数设置问题
-
一个 Kafka的Message由一个固定长度的 header和一个变长的消息体 body组成
message长度，值为1+4+N，一个字节的magic(文件格式 )，四个字节的CRC32位值(用于判断 body消息体是否正常 )，最终是N个字节的消息数据
消息格式演进 v0 v1 v2 ; v0 最少26b v1 最少34b v2 改动大,单条更大,消息集压缩,平均下来会小很多 kafka的数据是落盘的,Partition中是数据存活时间超过参数值（log.retention.{ms,minutes,hours},默认是7天）的时候会进行删除
kafka 高吞吐: 操作系统页缓存+(0拷贝技术)+ 磁盘顺序访问+ 批处理
kafka如何实现高吞吐,低延时的设计目标:
- 大量使用操作系统页缓存,内存操作速度快切命中率高
- kafka不直接参与物理IO操作,而是由操作系统完成
- 采用追加写入方式,摒弃了缓慢的磁盘随机读写操作
- 使用sendfile为代表的0拷贝技术加强网络间的数据传输效率
三:副本更新机制
HW:高水位 consumer无法消费分区下leader副本中位移值大于分区HW的任何消息。这里需要特别注意分区HW就是leader副本的HW值。
副本分为leader副本和follower副本，而每个副本又都有HW和LEO
-
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
<mark style="box-sizing: border-box; background: rgb(255, 255, 0); color: rgb(0, 0, 0); text-indent: 0px;">注意: 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))</mark>
-
Kafka使用HW值来决定副本备份的进度，而HW值的更新通常需要额外一轮FETCH RPC才能完成，故而这种设计是有问题的。它们可能引起的问题包括：
备份数据丢失
备份数据不一致
上述两个问题的<mark style="box-sizing: border-box; background: rgb(255, 255, 0); color: rgb(0, 0, 0); text-indent: 0px;">根本原因</mark>在于HW值被用于衡量副本备份的成功与否以及在出现failture时作为日志截断的依据，但<mark style="box-sizing: border-box; background: rgb(255, 255, 0); color: rgb(0, 0, 0); text-indent: 0px;">HW值的更新是异步延迟</mark>的，特别是需要额外的FETCH请求处理流程才能更新，故这中间发生的任何崩溃都可能导致HW值的过期
-
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 选举
Leader节点的切换基于 Zookeepe的Watcher机制,其他 ISR 中的 follower节点会竞争的在 zk 中创建一个文件目录 (只会有一个 follower节点创建成功 )，创建成功的 follower节点成为 leader节点
Kafka提供了一个 in -sync replicas(ISR)来确保 Kafka的Leader Leader选举
