Kafka 核心技术与实战
胡夕
Apache Kafka Committer,老虎证券技术总监
52815 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 47 讲
开篇词 (1讲)
结束语 (1讲)
Kafka 核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

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

从Leader拉取消息
处理Follower副本拉取消息
处理生产者请求
实例
作用
概念
高水位更新错配
消息同步周期
单分区、两个副本的主题
Follower副本
Leader副本
副本同步
消息可见性
Kafka中的水位
时刻T的水位
Leader Epoch机制的效果
高水位机制的重要性
Leader Epoch
数据丢失问题
实例
更新机制
作用
定义
开放讨论
总结
副本同步机制
高水位机制
Kafka的高水位机制和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
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部