Kafka 入门到起飞 - 什么是 HW 和 LEO？何时更新HW和LEO呢？

已于 2023-08-17 19:30:13 修改
阅读量1.9k 收藏 1
点赞数
分类专栏： kafka 文章标签： kafka HW LEO 高水位
于 2023-08-16 22:46:05 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/FightingITPanda/article/details/132327987
版权

上文我们已经学到，

  • 一个Topic（主题）会有多个Partition（分区）
  • 为了保证高可用，每个分区有多个Replication（副本）
  • 副本分为Leader 和 Follower 两个角色，Leader副本对外提供读写服务，Follower 从Leader同步数据
  • 当Leader副本挂掉，从ISR中选举一个Follower副本成为新的Leader对外继续提供服务
  • 那么就要保证分区各副本间数据一致性

图1：
在这里插入图片描述

见上图，先来熟悉一下

  • 已提交，Leader副本已经被ISR中所有Follower 都同步的消息
  • 未提交，Leader已经写入，还没有被Follower同步的消息
  • 对Consumer（消费者）而言，已提交的消息都可以拿到
  • Leader 和 Follower副本上都有HW 和 LEO
  • Leader副本除了自己的LEO，还存Follower的LEO（Remote LEO）

HW （High WaterMarker） 高水位

图2：
在这里插入图片描述
高水位可以理解为一个横切面，存储的也是Offset(位移)值，
拉齐分区ISR所有副本已经写入的消息，保证HW前的消息你有我有全都有啊，水桶原理

这里要注意，所有副本指的是ISR列表中的同步副本，OSR中同步慢的副本不管
为啥只管ISR列表，不管OSR列表中的副本呢？
这也就是为啥要搞HW 和 LEO 的原因，搞HW就是为了当Leader宕机了，会从ISR列表中选举一个Follower成为新的Leader继续对外提供服务，来实现高可用，而HW能保证任意一个Follower都包含对消费者可见的所有数据，实现数据的可靠性
而OSR是同步过慢的副本，选举也不选它，所以记录HW值也没必要管OSR列表

LEO （Log End Offset） 日志末端位移

就是下一个消息要写入的Offset（位移），
如上图1，当前副本最后一条消息的位移是13，下一个消息写入14位置，该副本的LEO值就是14

Follower 副本何时更新LEO呢？

以图2 中为例：
Leader 的LEO = 14
Follower1 的 LEO = 12
Follower2 的 LEO = 8

在这里插入图片描述

  • 对于Leader副本来说，每次写入消息，都会更新LEO的值
  • Follower 副本不停地向Leader副本发送Fetch请求，一旦获取数据后就写入log(日志)文件中进行备份，同时更新LEO值
  • 其实Follower跟Leader一样，写入数据后就更新自己的LEO值

那么Leader 端的Follower的LEO 什么时候更新呢？

  • 当Leader接收到Follower发起的Fetch请求
  • 先从Log文件中读取数据
  • 先更新Leader中存储的Follower的LEO
  • 再将数据返回给Follower
  • 这里会不会存在Leader更新了Follower的LEO，但是Follower实际并没有收到返回的消息，而造成Follower 所在broker 和 Leader所在broker存的LEO值不一致呢？

Follower 何时更新HW呢？

以图2 中为例：
Leader 、Follower1 、 Follower2 的 HW = 7

在这里插入图片描述

  • Follower写入数据后，会更新自己的LEO值，然后就尝试更新自己的HW值
  • Follower的HW值是怎么算的呢？
    • 是根据自己当前LEO值与Leader返回的HW值比较，去较小值作为HW更新
    • 这很好理解，Leader中记录的HW是所有副本HW最小的值，也就是同步最慢的那个副本的LEO，每个副本都需要知道这个事，自己不是最小那就记别人的值

Leader 何时更新HW呢？

  • Leader中存储的HW就是整个分区的HW，直接影响消息对消费者的可见性
  • Leader更新HW有4中情况
    • Leader接收生产者发送过来的消息，写入文件后，检查是否需要更新HW
    • Follower副本选举成为新的Leader是，Kafka会尝试去更新分区HW
    • Broker崩溃，导致副本被踢出ISR，Kafka会检查分区HW是否有被更新的必要
    • Leader处理Follower的Fetch请求是，先从Log读取数据，然后尝试跟新HW值
  • 正常情况下就是2种： leader处理producer请求，leader处理follower的fetch请求
Leader 的HW值是怎么算的呢？
  • 先选出所有满足条件的副本，ISR同步副本
  • 比较它们的LEO（包括leader的LEO）
  • 选择最小的LEO值作为HW

感觉有点迷糊？ 我们再来一篇举个栗子，掰BoBo说陷一下子，跟住奥~

** 都说kafka最厉害的地方是他的设计思想，果然有很多精妙之处啊**

FightingITPanda
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
- 为什么使用消息队列？ - 消息队列有什么优点和缺点？ - Kafka、ActiveMQ、RabbitMQ、RocketMQ
02-14
- 为什么使用消息队列？ - 消息队列有什么优点和缺点？ - Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？
Apache Kafka 入门 - Kafka-manager的基本配置和运行-附件资源
03-05
Apache Kafka 入门 - Kafka-manager的基本配置和运行-附件资源
深入理解 Kafka 的 offset、 leo、hw、epoch 概念
天道酬勤
02-28 2013
Kafka 作为一个分布式的消息中间件，在高性能、高并发、高可用上有杰出的表现，在数据一致性上更是做出了诸多努力
Kafka 之 HW 与 LEO
程序猿进阶
04-23 3759
HW（High Watermark）：俗称高水位，它标识了一个特定的消息偏移量（offset），消费者只能拉取到这个 offset 之前的消息。分区 ISR 集合中的每个副本都会维护自身的 LEO（Log End Offset）：俗称日志末端位移，而 ISR 集合中最小的 LEO 即为分区的 HW，对消费者而言只能消费 HW 之前的消息。 LEO：该副本底层 log文件下一条要写入的消息的位移，例如 LEO=10则当前文件已经写了了10条消息，位移是[0,10)。HW：所有分区已提交的的位移，一般HW&
HW 和 LEO是如何运行的？
最新发布
qq_35459686的博客
04-10 770
由上图可以知道 由于有节点落后，导致HW一直无法更新，并且kafka针对HW也有规定， 只有HW标识前的数据才能被读取， 也就是说HW=1 作为消费者来说只能看到0 和 1 的数据。相信大家在上一篇文章已经知道啦，HW 就是高水位的意思，也就是收到消息反馈的标识， LEO 末尾数据标识， 也就是代表着下一个需要发送的数据，或者消费者下一个需要消费的数据。上述图中， 由于小欣同学出差导致了落后了， 这时候影响了HW的运行，导致了整体数据的堵塞，那么该怎么办呢？紧接着，快递员小苏开始将这些广告邮件开始派送了~
Kafka ，LEO和HW更新时机
u010321010的博客
09-14 386
我们假设有一个topic，单分区，副本因子是2，即一个leader副本和一个follower副本。我们看下当producer发送一条消息时，broker端的副本到底会发生什么事情以及分区HW是如何被更新的。 下图是初始状态，我们稍微解释一下：初始时leader和follower的HW和LEO都是0(严格来说源代码会初始化LEO为-1，不过这不影响之后的讨论)。leader中的remote LEO指的就是leader端保存的follower LEO，也被初始化成0。此时，producer没有发送任何消息给le
kafka中LEO和HW
小泽
07-08 377
a
Kafka中HW和LEO和副本的关系
whiteBearClimb的博客
12-21 598
HW ：High Water 最高水位 LEO：Log End Offset 数据日志文件结束偏移量 先看图吧： 假设AB两个副本都是Topic的，B是Leader，A是follower，A数据同步明显滞后，这个时候用户能读取的数据，最多能消费到最高水位HW = 6 的位置，但是这两副本（Leader和Follower）它们的LEO是不一样的，A是6，B是8，但是它们的HW却一样。 我们可以把它看作是木桶短板效应，用户能用多少水，要看最高水位能装到多少，最高水位限制于LEO最后数据日志文件偏移量。 与副本
Kafka中的HW、LEO等分别代表什么意思?
zy1992As的博客
02-21 232
在Apache Kafka中，HW(High Watermark)和 LEO(Log End Offset)是与分区的复制和消息传递相关的两个关键概念。
Kafka-LEO和HW概念及更新流程
weixin_43865381的博客
01-26 2309
目录LEO&HW基本概念LEO&HW更新流程LEOHW更新流程示例分析 引言 记录下和kafka相关的LEO和HW的内容，文中很多理解参考文末书籍还有某前辈。 回到顶部LEO&HW基本概念 Base Offset：是起始位移，该副本中第一条消息的offset，如下图，这里的起始位移是0，如果一个日志文件写满1G后（默认1G后会log rolling），这个起始位移就不是0开始了。 HW（high watermark）：副本的高水印值，re...
kafka-schema-registry-client-6.2.2.jar
04-25
mvn install:install-file -DgroupId=io.confluent -DartifactId=kafka-schema-registry-client -Dversion=6.2.2 -Dfile=/root/kafka-schema-registry-client-6.2.2.jar -Dpackaging=jar 官网下载地址 packages....
kafkapython教程-Kafka快速入门（十二）-Python客户端.pdf
06-11
kafkapython教程_Kafka快速⼊门（⼗⼆）——Python客户端 Kafka快速⼊门(⼗⼆)——Python客户端 ⼀、confluent-kafka 1、confluent-kafka简介 confluent-kafka是Python模块，是对librdkafka的轻量级封装，⽀持Kafka ...
kafka中AR、ISR、OSR以及HW、LEO的区别
qq_53578500的博客
08-14 1682
Kafka 为分区引入了多副本 （Replica） 机制， 通过增加副本数量可以提升容灾能力。同一分区的不同副本中保存的是相同的消息（在同一时刻，副本之间并非完全一样）
【消息队列】Kafka高水位和Leader Epoch原理
日拱一卒，不期速成！
04-22 928
Kafka 高水位 和Leader Epoch原理
Kafka中HW和LEO增长的原理是什么?流程是怎样的?
mengzhongtian的博客
12-08 822
我们知道kafka中hw可以用来管理消费者能访问到的最新的数据的位置, 并且当kafka leader节点挂掉后, follower节点会把hw以后的数据都清理掉, 从hw位置开始从新选举出来的leader节点同步数据, 那么HW增长的原理是怎样的呢? 带着这个疑问, 看完以下内容就能明白! 1. LEO (log end offset)是干啥的? 每个副本(leader/ follower)都有一个leo, 表示的是这个副本最新的数据最大的偏移量, 不包含当前数据 leo存储在...
Kafka篇——Kafka集群Controller、Rebalance和HW的详细介绍，保姆级教程！
我热爱学习，也乐于分享。无论是科技前沿的洞见，还是生活中的小技巧，我都会在这里与你分享。我相信，知识就是力量，而分享则能让这份力量得到更好的传递。
01-17 1654
一、概念在Kafka中，Controller是Kafka集群中的一个角色，负责管理集群的元数据、分区分配、副本管理等功能。Controller的主要职责包括：1. 元数据管理：Controller负责维护Kafka集群的元数据，包括broker的存活状态、分区的分配情况、副本的分配情况等。它通过与Zookeeper进行交互，监控集群中broker的状态变化，并更新集群的元数据。
Kafka HW&LEO概念入门
鸭梨的博客
01-27 709
HW HW （High Watermark）俗称高水位，它标识了一个特定的消息偏移量（offset），消费者只能拉取到这个offset之前的消息。 LEO LEO （Log End Offset），标识当前日志文件中下一条待写入的消息的offset。上图中offset为9的位置即为当前日志文件的 LEO，LEO 的大小相当于当前日志分区中最后一条消息的offset值加1.分区 ISR 集合中的每个副本都会维护自身的 LEO ，而 ISR 集合中最小的 LEO 即为分区的 HW，对消费者而言只能消费 HW
Kafka 系统的 CAP 保证（HW，Leader-Epoch）
PAIN的博客
08-09 435
为了解决 HW 更新时机是异步延迟的，Kafka 引入了 leader epoch 机制；在每个副本日志目录下都创建一个 leader-epoch-checkpoint 文件，用于保存 leader 的 epoch 信息，。它的格式为 (epoch offset)，epoch 指的是 leader 版本，它是一个单调递增的一个正整数值，每次 leader变更，epoch 版本都会 +1，offset 是每一代 leader 写入的第一条消息的位移值，比如：(0,0)(1,300)
Kafka 实战 - Kafka中Controller，Rebalance，HW，LEO的概念
qq_33240556的博客
04-10 300
总之，Controller、Rebalance、HW、LEO 是 Kafka 集群管理和消息流控的关键概念，理解它们的工作原理有助于更好地诊断和优化 Kafka 集群的运行状态。：当分区首领 Broker 故障或下线时，Controller 会触发选举过程，从分区的 ISR（In-Sync Replicas，同步副本集）中选出新的首领。的健康状况直接影响整个集群的稳定性。：Controller 监听 Broker 的上线、下线事件，以及 Broker 上副本状态的变化，根据这些信息做出相应的集群管理决策。
什么是Kafka leo（log end offset）和hw（high watermark）
06-08
Kafka 中的 LEO（Log End Offset）和 HW（High Watermark）是两个重要的概念，用于表示 Kafka Partition 中消息的存储情况和消费情况。 1. LEO（Log End Offset）：表示 Kafka Partition 中最后一条消息的偏移量，即消息在 Partition 中的存储位置。当 Producer 向 Partition 中写入消息时，LEO 会不断增加，表示消息的写入位置；当 Consumer 从 Partition 中拉取消息时，LEO 会不断变化，表示消息的读取位置。 2. HW（High Watermark）：表示 Kafka Partition 中已经被 Consumer 消费的消息偏移量，即消息在 Partition 中的消费位置。当 Consumer 从 Partition 中拉取消息时，HW 会不断增加，表示已经消费的消息的偏移量；当 Consumer 向 Kafka Broker 提交位移时，HW 会被更新为提交的位移，表示消费者已经消费了该位移之前的所有消息。 LEO 和 HW 的关系如下： - LEO >= HW：表示 Partition 中还有未被消费的消息，Consumer 可以继续消费这些消息； - LEO < HW：表示 Partition 中已经没有未被消费的消息，Consumer 无法继续消费消息，除非有新的消息写入到 Partition 中。 LEO 和 HW 的作用如下： - LEO 表示消息的存储位置，可以用于监控 Partition 中消息的写入情况； - HW 表示消息的消费位置，可以用于监控 Consumer 消费消息的情况，以及实现消息传输语义的控制。例如，At Least Once 语义中，Consumer 可以将 HW 作为提交位移的参考，避免消息的重复消费。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值