从0开始带你成为Kafka消息中间件高手---第三讲

从0开始带你成为Kafka消息中间件高手---第三讲

实际上来说,每次leader接收到一条消息,都会更新自己的LEO,也就是log end offset,把最后一位offset + 1,这个大家都能理解吧?接着各个follower会从leader请求同步数据,这是持续进行的

offset = 0 ~ offset = 4,LEO = 5,代表了最后一条数据后面的offset,下一次将要写入的数据的offset,LEO,你一定要明白他的名词

然后follower同步到数据之后,就会更新自己的LEO

并不是leader主动推送数据给follower,他实际上是follower主动向leader尝试获取数据,不断的发送请求到leader来fetch最新的数据

然后对于接收到的某一条数据,所有follower的LEO都更新之后,leader才会把自己的HW(High Water Mark)高水位offset + 1,这个高水位offset表示的就是最新的一条所有follower都同步完成的消息

partition中最开始的一条数据的offset是base offset

LEO和HW分别是干什么的呢?

LEO很重要的一个功能,是负责用来更新HW的,就是如果leader和follower的LEO同步了,此时HW就可以更新

所有对于消费者来说,他只能看到base offset到HW offset之间的数据因为只有这之间的数据才表明是所有follower都同步完成的,这些数据叫做"已提交"的,也就是committed,是可以被消费到的

HW offset到LEO之间的数据,是"未提交的",这时候消费者是看不到的

HW offset表示的是当前已经提交的数据offset,LEO表示的是下一个要写入的数据的offset

首先leader接收到数据字后就会更新自己的LEO值

接着follower会不断的向leader发送fetch请求同步数据,然后每次一条数据同步到follower之后,他的LEO就会更新,同时leader发送数据给follower的时候,在leader端会维护所有follower的LEO值

follower发送fetch请求给leader的时候会带上自己的LEO值,然后leader每次收到一个fetch请求就会更新自己维护的每个follower的LEO值

所以这里大家要知道的是,leader上是会保存所有follower的LEO值的,这个是非常关键和核心的一点

每次leader发送数据给follower的时候,都会发送自己的HW值,然后follower获取到leader HW之后,就会跟自己的LEO比较一下,取里面小的那个值作为自己的HW值,换句话说,如果follower的LEO比leader HW大了,那么follower的HW就是leader HW

但是如果follower的LEO比leader HW小,说明自己明显落后于leader,那么follower的HW就是自己的LEO值

然后leader上的HW就很明显了,那就是主要是他在接收follower的fetch请求的时候,就会在更新自己维护的所有follower的LEO之后,判断一下当前自己的LEO是否跟所有follower都保持一致,那么就会自动更新自己的HW值

这个leader的HW值就是partition的HW值,代表了从这个partition的哪个offset之前可以被消费数据

假设leader收到第一条数据,此时leader LEO = 1,HW = 0,因为他发现其他follower的LEO也是0,所以HW必须是0

接着follower来发送fetch请求给leader同步数据,带过去follower的LEO = 0,所以leader上维护的follower LEO = 0,更新了一下,此时发现follower的LEO还是0,所以leader的HW继续是0

接着leader发送一条数据给follower,这里带上了leader的HW = 0,因为发现leader的HW = 0,此时follower LEO更新为1,但是follower HW = 0,取leader HW

接着下次follower再次发送fetch请求给leader的时候,就会带上自己的LEO = 1,leader更新自己维护的follower LEO = 1,此时发现follower跟自己的LEO同步了,那么leader的HW更新为1

接着leader发送给follower的数据里包含了HW = 1,此时follower发现leader HW = 1,自己的LEO = 1,此时follower的HW有更新为1

5个数据:全部都要往前推进更新,需要2次请求,第一次请求是仅仅是更新两边的LEO,第二次请求是更新另外leader管理的follower LEO,以及两个HW

相关推荐
Database_Cool_9 小时前
单机 MySQL 迁移到分布式数据库方便吗?阿里云 PolarDB-X 100% MySQL 协议兼容零改造平滑迁移
数据库·分布式·mysql
肥胖小羊18 小时前
解决企业微信 AccessToken 刷新并发冲突的分布式锁机制实践
分布式·企业微信
AI人工智能+电脑小能手19 小时前
【大白话说Java面试题 第192题】【08_Kafka篇】第8题:死信队列是什么?延时队列是什么?
java·kafka·消息队列·死信队列·延时队列
AI人工智能+电脑小能手2 天前
【大白话说Java面试题 第190题】【08_Kafka篇】第6题:消息队列有什么作用?
java·kafka·消息队列·系统设计·分布式架构
风中凌乱2 天前
kafka新版本集群的安装与部署
分布式·kafka
SLD_Allen2 天前
大规模分布式AI训练基础设施
人工智能·分布式·模型训练
abcy0712132 天前
kafka消息丢失与消息重复消费
kafka
富士康质检员张全蛋2 天前
Kafka的操作-消费的详情
分布式·kafka
昕光xg2 天前
Istio笔记04-基于Jaeger的分布式链路追踪
笔记·分布式·istio
Benjamin℡2 天前
Zookeeper(一)搭建单体和集群服务以及Zookeeper客户端
分布式·zookeeper·云原生