27 | 关于高水位和Leader Epoch的讨论

胡夕



该思维导图由 AI 生成，仅供参考

你好，我是胡夕。今天我要和你分享的主题是：Kafka 中的高水位和 Leader Epoch 机制。
你可能听说过高水位（High Watermark），但不一定耳闻过 Leader Epoch。前者是 Kafka 中非常重要的概念，而后者是社区在 0.11 版本中新推出的，主要是为了弥补高水位机制的一些缺陷。鉴于高水位机制在 Kafka 中举足轻重，而且深受各路面试官的喜爱，今天我们就来重点说说高水位。当然，我们也会花一部分时间来讨论 Leader Epoch 以及它的角色定位。
什么是高水位？首先，我们要明确一下基本的定义：什么是高水位？或者说什么是水位？水位一词多用于流式处理领域，比如，Spark Streaming 或 Flink 框架中都有水位的概念。教科书中关于水位的经典定义通常是这样的：
在时刻 T，任意创建时间（Event Time）为 T’，且 T’≤T 的所有事件都已经到达或被观测到，那么 T 就被定义为水位。
“Streaming System”一书则是这样表述水位的：
水位是一个单调增加且表征最早未完成工作（oldest work not yet completed）的时间戳。
为了帮助你更好地理解水位，我借助这本书里的一张图来说明一下。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

Kafka中的高水位和Leader Epoch机制是Kafka中非常重要的概念。高水位定义了消息的可见性和帮助完成副本同步，而Leader Epoch机制则是为了弥补高水位机制的一些缺陷而在0.11版本中新推出的。高水位通过消息位移来表征，与时间无关，而Leader Epoch则由Epoch和起始位移组成，用于规避因高水位更新错配导致的数据丢失和不一致问题。文章详细解释了高水位的作用和更新机制，以及Leader副本和Follower副本的处理逻辑。同时，还介绍了Leader Epoch机制的角色定位和如何防止数据丢失的实际例子。通过本文的总结，读者可以快速了解Kafka中高水位和Leader Epoch机制的技术特点，对于深入理解Kafka的工作原理和副本机制具有重要参考价值。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Kafka 核心技术与实战》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(101)

最新
精选

朱东旭
胡老师您好，在您讲的leader epoch机制案例中，在我看来最关键的操作是broker重启后先向leader确认leo,而不是直接基于自己的高水位截断数据，来防止数据不一致。。可是有无leader epoch都可以做这个操作呀，我看不出leader epoch必要性在哪。。
作者回复: epoch还有其他的作用，比如执行基本的fencing逻辑等
2019-11-02
5
16
李先生
胡哥，有两个问题： 1:为什么broker重启要进行日志截断，触发日志截断的前提是什么？目的是什么？ 2:acks=all,是代表同步到所有isr中broker的pagecache中还是磁盘？min.insync.replicas是配合acks=all来使用的，是一个保证消息可靠性的配置，比如设置为2，是代表在isr中至少两个broker上写入消息，这个写入是写入pagecache中还是磁盘中？如果都是写入pagecache中，kafka是有异步线程来定时从pagecache中拉消息写入磁盘吗？
作者回复: 1. broker崩溃前可能写入了部分不完整的消息。这部分数据显然不能算做成功提交，因此在重启回来后要执行截断操作，将底层日志调整回到合法的状态上。 2. 你可以认为都是pagecache。pagecache落盘完全由OS来完成，不由Kafka控制。
2020-04-14
3
10
td901105
老师您好,我怎么感觉只需要在副本拉取Leader的LOG就不会产生日志截断的问题了,感觉不需要Leader Epoch?
作者回复: 日志截断主要是因为follower必须要与leader保持一致，而一旦某个“落后”的副本成为leader，其他“领先”的follower必须与其保持一致，必须truncate掉自己多余的消息。至于如何在这个过程中保持副本间的一致，社区之前使用高水位机制，但发现有一些固有的缺陷，进而开发了leader epoch。如果你能提出更简单的算法，欢迎写下来：）
2020-01-19
6
9
faunjoe
多个broker 中的leader epoch 他们是版本号是怎么保持累加的
作者回复: Kafka缓存了LeaderEpochCache来保证
2020-05-10

7
thomas
倘若此时副本 B 所在的 Broker 宕机，当它重启回来后，副本 B 会执行日志截断操作，将 LEO 值调整为之前的高水位值，也就是 1。 -------------------------------------------------------------> 老师，请问为什么要将LE0的值设置为HW的值。LEO的值是消息写入磁盘后才被更新的，也就是数据已经落地。重启后继续用LEO的值会有什么问题吗
作者回复: 必须要调整到水位值，因为即使消息被写入到磁盘上了，不代表这条消息就提交成功了。未成功提交的消息即使写入了磁盘也要做截断
2020-04-26
2
7
Johnson
老师您好，有个疑问，leader epoch怎么做到像hw里的数据可见性的，比如hw可以保证消费端只能消费hw之前提交的消息，leader epoch如何保证这点，谢谢！
作者回复: leader epoch做不到这点。leader epoch只是保证在执行日志截断时不会出现因leader/follower副本接连宕机导致的不一致性。除此之外的功能依然由HW提供
2020-04-13
2
7
😈😈😈😈😈
这个是我理解的HW和LEO更新的机制步骤，有错误的话请大神指明下，非常感谢更新对象更新时机 Broker1上Follower副本 Follwer会从Leader副本不停的拉取数据，但是Leader副本现在的没有数据。所以Leader副本和Follower副本的高水位值和LEO值都是0 Broker0上的Leader副本生产者向Leader副本中写入一条数据，此时LEO值是1,HW值是0。也就是说位移为0的位置上已经有数据了 Broker1上Follower副本由于Leader副本有了数据，所以Follower可以获取到数据写入到自己的日志中，且标记LEO值为1，此时在Followe位移值为0的位置上也有了数据，所以此时Follower的HW=0，LEO=1 Broker1上Follower副本获取到数据之后，再次向Leader副本拉数据，这次请求拉取的数据是位移值1上的数据 Broker0上的远程副本 Leader收到Follower的拉取请求后，发现Follower要拉取的数据是在位移值为1的位置上的数据，此时会更新远程副本的LEO值为1。所以所有的远程副本的LEO等于各自对应的Follower副本的LEO值 Brober0上的Leader副本 Broker0上的远程副本的LEO已经更新为1了。所以开始更新Leader副本的HW值。HW=max{HW,min(LEO1,LEO2,LEO3......LEON)},更新HW值为1，之后会发送Follower副本请求的数据（如果有数据的话，没有数据的话只发送HW值）并一起发送HW值 Broker1上Follower副本 Follwer副本收到Leader返回的数据和HW值（如果Leader返回了数据那么LEO就是2，没有数据的话LEO还是1），用HW值和自己的LEO值比较选择较小作为自己的HW值并更新HW值为1（如果俩个值相等的话HW=LEO）一次副本间的同步过程完成
作者回复: 挺好的，没有什么意见：）
2019-10-22
2
7
Geek_0819
胡老师有个疑问：生产者同步发送消息时指定同步到所有副本，生产者是等待所有副本的LEO都写入成功才返回吗？如果是这样Follower副本从Leader上拉取LEO是有时间间隔的，这样生产者都在这里等待很久吗？还是其他方式的交互？
作者回复: 配置acks=-1的生产者会等待ISR中所有副本都同步了该消息才会认为消息成功提交。确实，有些情况下生产者会等待一段时间，这通常是线上环境中producer延迟的主要诱因。至于多久则因具体场景而定了~
2020-01-21
4
6
常超
请问老师，与 Leader 副本保持同步的两个判断条件，是OR还是AND的关系？
作者回复: AND
2019-08-07
3
6
我来也
1.该远程 Follower 副本在 ISR 中。如果 Kafka 只判断第 1 个条件的话，就可能出现某些副本具备了“进入 ISR”的资格，但却尚未进入到 ISR 中的情况。 ———————— 这里是不是把条件的编号写反了？
作者回复: 没写反啊？就是想说只靠第一个条件不充分
2019-08-03
4
4

收起评论