ISR机制保障数据一致性

一、概述

Kafka 采用主从(Leader-Follower)复制模型来保障数据的可靠性与一致性。分区副本之间通过 ISR(In-Sync Replicas)机制协调复制进度,并以 HW(High Watermark,高水位)作为消费者可见性的判定基准。

二、核心概念

全称 含义 说明
Assigned Replicas(AR) 分区配置的所有副本集合(包括 Leader 和所有 Follower)。由 replication.factor 决定。
In-Sync Replicas(ISR) 同步副本集合。指那些与 Leader 保持实时同步、延迟在允许范围内的副本。Leader 始终在 ISR 中。
Out-of-Sync Replicas(OSR) 非同步副本集合。指因网络延迟、GC 停顿或负载过高导致同步滞后,被暂时剔除出 ISR 的副本。
High Watermark(HW) 高水位线,ISR 集合中所有副本最后提交偏移量的最小值。 HW = min(ISR 内所有副本的 LEO)
Log End Offset(LEO) 日志末端偏移量,表示副本日志中下一条待写入消息的偏移量; Leader 与 Follower 各自维护

三、ISR 保障数据一致性的核心原理

ISR 机制通过六个环节的协同,保障分区数据的一致性与可用性:ISR 维护 → 消息写入与复制 → 提交判定 → 消费可见性 → 同步保障 → 故障恢复。各环节环环相扣,共同构成 Kafka 数据可靠性的基础。

3.1 Leader 维护 ISR

Leader 负责维护 ISR。当 Follower 的复制进度追上 Leader(其 LEO 与 Leader 对齐)时,Leader 将其加入 ISR;当 Follower 长时间无法追上 Leader 的进度,或主动退出同步时,Leader 将其从 ISR 中移除,降级为OSR。

3.2 生产者发送消息

生产者将消息发送至 Leader,Leader 将消息追加(append)到本地日志,并向 ISR 中的全部 Follower 同步复制。

3.3 消息提交

当 ISR 中所有 Follower 均完成该消息的复制后,Leader 推进 HW(High Watermark,高水位/最高提交偏移量)。此时消息才被认定为"真正提交",具备对外可见的资格。

3.4 消费者消费消息

消费者只能消费已提交的消息,即偏移量位于 HW 之前的消息;HW 之后的消息虽然已写入 Leader,但尚未确认提交,对消费者不可见。

3.5 Follower 同步数据

Follower 周期性主动从 Leader 拉取(pull)数据,保持与 Leader 的同步。当 Follower 宕机或长期未完成同步时,会被 Leader 从 ISR 中移除。

3.6 Leader 选举

当 Leader 所在 Broker 失效时,会从 ISR 中选举出新的 Leader。选举规则为:优先选择 ISR 中数据最新(LEO 最大)的 Follower 作为新 Leader。

边界说明:若开启 unclean.leader.election.enable=true,当 ISR 为空时允许选择 OSR 中的副本作为新 Leader,此时可能产生数据丢失。

四、消息ACK机制

4.1 Producer消息发送流程

markdown 复制代码
Producer → ① 发送消息 → Leader 追加到本地日志(LEO+1)
                          ↓
                   ② Follower 拉取复制(LEO+1)
                          ↓
                   ③ Leader 根据 ISR 各副本 LEO 计算 HW
                          ↓
                   ④ 达到 ack 条件 → 向 Producer 返回 ack

4.2 ack机制

acks 取值 含义 Leader 何时返回 ack 可靠性
acks=0 不等确认 消息写入客户端缓冲区即返回 最低,可能直接丢
acks=1 等 leader 确认 消息写入 leader 本地日志(LEO 推进)即返回 中等,leader 宕机可能丢
acks=all 等所有 ISR 确认 所有 ISR 副本复制完成、HW 推进后才返回 最高

核心逻辑: acks=all 下,ack 时机 = HW 推进时机。 Leader 只有在确认"ISR 内所有副本都有了这条消息"之后,才推进 HW 并回复 ack。

相关推荐
Flynn Liang19 小时前
物联网时序数据乱序问题全链路治理:从设备到存储的五层实战(附 Flink/Kafka/IoTDB 配置级代码)
flink·kafka·iot·iotdb·emqx·乱序·时序数据
starzy19902 天前
Kafka响应发送:字节是怎么真正写回客户端的
大数据·kafka
阳光不锈@2 天前
三大主流消息队列架构设计思想剖析:从 RabbitMQ 到 RocketMQ 的改造实践
kafka·rabbitmq·rocketmq·rabbit改造rocket·去除rabbitmq·rabbitmq改造
ZealSinger2 天前
Boot4升后Kafka retry属性怎么改
kafka·retry·boot4·升级踩坑
starzy19902 天前
KafkaProducer 源码深度剖析:处理粘包问题的完美方案
大数据·kafka
MrWind灬2 天前
我给自己写了个 Kafka 桌面客户端:MrWindKafkaClient
kafka·pyqt
starzy19903 天前
KafkaProducer 源码深度剖析:与 Broker 建立连接
大数据·kafka
我不会起名字3223 天前
Kafka 重复消费:自动提交位点与手动提交的 3 个错位
kafka·消息队列·幂等·排查
ly76894 天前
Kafka 消费者重试与死信:Spring for Apache Kafka 的边界设计
spring·kafka·apache·并发消费·消费者重试·死信主题·位移提交
我不会起名字3225 天前
Kafka 顺序消息为什么乱了:分区数变化与重试的 3 类原因
kafka·消息队列·顺序·排查