kafka原理解析之-消息可靠性保障

本文讨论的是假设存在完美无缺的producer和consumer， 从broker角度保障数据可靠的机制。

一、名词介绍

• ISR(In-sync Replication):所有与leader副本保持一定程度同步的副本（包括Leader）,是kafka动态维护的一组同步副本，每当leader挂掉时，在ISR集合中选举出一个follower作为leader提供服务，当ISR中的副本被认为坏掉的时候，会被踢出ISR，当重新跟上leader的消息数据时，重新进入ISR。ISR中的节点必须满足：
  a、节点必须可以维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连接。
  b、如果节点是个 follower ，它必须能及时的同步 leader 的写操作，并且延时不能太久。

• OSR(Out-sync Replication):与leader副本同步滞后过多的副本（不包括leader）。

• LEO(LogEndOffset):分区的最新的数据的offset，下一条将要被加入到日志的消息的位移。当数据写入leader后，LEO就立即执行该最新数据。相当于最新数据标识位。注意，这个offset未必在硬盘中，可能目前只在内存中还没有被flush到硬盘。

• LSO(logStartOffset):日志段集合中第一个日志段（segment）的基础位移，也就是这个日志对象的基础位移

• HW(HighWatermark ):只有写入的数据被同步到所有的ISR中的副本后，数据才认为已提交，HW更新到该位置，HW之前的数据才可以被消费者访问，保证没有同步完成的数据不会被消费者访问到。相当于所有副本同步数据标识位。

• AR(Assigned Repllicas):分区中的所有副本,ISR+OSR

二、LEO、HW、ISR之间的关系

当ISR集合发生增减 或者ISR集合中任一副本LEO发生变化时，都会影响整个分区的HW。

如上图所示：leader的LEO为9，follower的LEO为7，而follower2的LEO为6，若判定这三个副本都处于ISR集合中，那么分区的HW为6；若follower3被判定失效被剥离出ISR集合，那么此时分区HW为leader和follower中LEO的最小值，即为7.

三、log目录下各个checkpoint文件作用说明：

• __consumer_offsets： 用于存储offset的分区是由kafka服务器默认自动创建的
• cleaner-offset-checkpoint： 存了每个log的最后清理offset.
• log-start-offset-checkpoint： 日志可以返回给Client的最开始边界,对应LSO.
• recovery-point-offset-checkpoint：负责记录已经被刷写入磁盘的offset,recoveryPoint以下的数据都是已经刷到磁盘上的了。
• replication-offset-checkpoint：用来存储每个replication的HW，表示已经被commited的message，HW以下的数据都是各个replication间同步的，一致的.

五、Partition recovery：

每个Partition会在磁盘记录一个RecoveryPoint（记录在recovery-point-offset-checkpoint中）, 记录已经flush到磁盘的最大offset。

1、recovery过程

• broker fail 重启时,会进行loadLogs。 首先会读取该Partition的RecoveryPoint,找到包RecoveryPoint的segment及以后的segment, 这些segment就是可能没有完全flush到磁盘segments。然后调用segment的recover（如有其它topic副本则读取，若无，有可能丢失数据）,重新读取各个segment的msg,并重建索引。

2、segment的优点：

• 以segment为单位管理Partition数据,方便数据生命周期的管理,删除过期数据简单
• 在程序崩溃重启时,加快recovery速度,只需恢复未完全flush到磁盘的segment
  分多个Segment,每个index文件很小,查找速度更快。

六、Partition同步：

• Partition的多个replica中一个为Leader,其余为follower
• Producer只与Leader交互,把数据写入到Leader中
• Followers从Leader中拉取数据进行数据同步
• Consumer只从Leader拉取数据

七、Leader选举：

• 基于Controller的Leader Election
  整个集群中选举出一个Broker作为Controller
  Controller为所有Topic的所有Partition指定Leader及Follower
• 优点
  极大缓解Herd Effect问题
  减轻Zookeeper负载
  Controller与Leader及Follower间通过RPC通信，高效且实时
• 缺点
  引入Controller增加了复杂度
  需要考虑Controller的Failover

总结：1、kafka利用zookeeper去选举出controller；2、kafka通过controller选指定出leader和follower，而无需通过zookeeper了。

八、数据可靠性

1、producer角度
当Producer向Leader发送数据时,可以通过acks参数设置数据可靠性的级别:

• 0: 不等待broker返回确认消息.
• 1: leader保存成功返回,此种情况如果Leader fail,会丢失数据
• -1(all): 所有备份(ISR)都保存成功返回, 仅设置acks=-1也不能保证数据不丢失,当Isr列表中只有Leader时,同样有可能造成数据丢失。要保证数据不丢除了设置acks=-1, 还要保 证ISR的大小大于等于2

request.required.acks:设置为-1 等待所有ISR列表中的Replica接收到消息后才算写成功;
min.insync.replicas: 设置为大于等于2,保证ISR中至少有两个Replica

Producer要在吞吐率和数据可靠性之间做一个权衡

2、consumer角度（数据一致性）

若某条消息对Consumer可见,那么即使Leader宕机了,在新Leader上数据依然可以被读到

• HighWaterMark简称HW: Partition的高水位，取一个partition对应的ISR中最小的LEO作为HW，消费者最多只能消费到HW所在的位置，另外每个replica都有highWatermark，leader和follower各自负责更新自己的highWatermark状态，highWatermark <= leader. LogEndOffset
• 对于Leader新写入的msg，Consumer不能立刻消费，Leader会等待该消息被所有ISR中的replica同步后,更新HW,此时该消息才能被Consumer消费，即Consumer最多只能消费到HW位置，这样就保证了如果Leader Broker失效,该消息仍然可以从新选举的Leader中获取。对于来自内部Broker的读取请求,没有HW的限制。同时,Follower也会维护一份自己的HW,Folloer.HW = min(Leader.HW, Follower.offset)