kafka原理解析之-消息可靠性保障_kafka recovery-point-offset-checkpoint文件作用-CSDN博客

本文链接：https://blog.csdn.net/zwq00451/article/details/111085872

本文讨论的是假设存在完美无缺的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

当ISR集合发生增减或者ISR集合中任一副本LEO发生变化时，都会影响整个分区的HW。
在这里插入图片描述

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

__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会在磁盘记录一个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的优点：

基于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)