【Kafka】ISR 高水位问题（一）Leader 跟 Follower 的 HW 和 LEO 如何更新？ Leader

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第9天，点击查看活动详情

概念：

LEO(log end offset): 指代下次写入到此 Partition 的下一条数据的 offset, 是 partition 最大 offset+1
HW(High Water Mark)：Leader partition 同步到其所有 follower 的 offset

按图解析：

LEO 作用：

负责推算 Leader partition的 HW。
更新 HW：当所有的 follower partition 的 LEO 推送给 Leader partition 时候，Leader partition 根据 min{LEO1...LEOn} 即可得到 Leader 的 HW

HW 作用：

更新 follower 的 HW：当 follower 请求 leader 数据同步时候，leader 会返回自己的 HW, 然后 follower 会更新 min{Leader(HW),LEO}
划分已提交和未提交数据：HW=3，表示前3条数据是已经同步到其他所有的 follower 里面去了，所以也将其叫做 committed（已提交数据），消费者是消费不到 HW 之后的 uncommmitted 数据的
消费：Consumer 只能看到 base offset 到 HW offset 之间的数据，这部分数据是 committed，可以被消费。

# 默认10000 即 10秒
replica.lag.time.max.ms
   

# 允许 follower 副本落后 leader 副本的消息数量，超过这个数量后，follower 会被踢出 ISR
replica.lag.max.messages

Leader 操作：

Follower 操作：

举个栗子：

# 副本有 4 个，1 个 leader 和 3 个 follower
replication-factor = 4

# 最小同步数为3，3个副本写入数据就认为写入成功
min.insync.replicas = 3

会有两个主要问题：

此问题发生概率极低。

问题重现流程主要是：

# 副本有 2 个，1 个 leader 和 1 个 follower
replication-factor = 2

# 最小同步数为1，1个副本写入数据就认为写入成功
min.insync.replicas = 1

问题重现详细流程：

假设一开始：Leader 的 LEO = 1, HW = 0，Follower 的 LEO = 0, HW = 0
数据同步：Follower 发送 fetch 请求，Follower 写入数据，Leader 的 LEO = 1, HW = 0，Follower 的 LEO = 1, HW = 0
数据同步：Follower 发送 fetch 请求，Leader 的 LEO = 1, HW = 0，Follower 的 LEO = 1, HW = 0，这时候 Follower 的 HW = 1 还没更新
这时，Follower 宕机后重启，Follower 的 LEO 会根据 HW 自动调整为 0，并把那条数据从日志文件中删除
这时，Leader 宕机了，Follower 被选举为 Leader ，之后根据 Leader 来同步数据

问题重现流程主要是：

# 副本有 2 个，1 个 leader 和 1 个 follower
replication-factor = 2

# 最小同步数为1，1个副本写入数据就认为写入成功
min.insync.replicas = 1

问题重现详细流程：

假设一开始：Leader 的 LEO = 2, HW = 1，Follower 的 LEO = 1, HW = 1
数据同步：Follower 发送 fetch 请求，Follower 写入数据，Leader 的 LEO = 2, HW = 1，Follower 的 LEO = 1, HW = 1，还没同步完成
这时，Leader 宕机了后重启，Follower 被选举为新Leader
这时，生产者发了一条新数据给新Leader ，Leader 的 LEO = 2, HW = 2，Follower 的 LEO = 2, HW = 2，虽然两者 HW = 2，但数据不同。

【Kafka】ISR 高水位问题（一）