海安零距离 海安论坛 海安新闻 海安

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 2325|回复: 0

图解 Kafka 水印备份机制

[复制链接]

6234

主题

6234

帖子

1万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
18716
发表于 2019-12-27 14:35 | 显示全部楼层 |阅读模式
高可用是许多分布式体系中必备的特征之一,Kafka 日志的高可用是通过基于 leader-follower 的多副本同步实现的,每个分区下有多个副本,此中只有一个是 leader 副本,提供发送和消费消息,别的都是 follower 副本,不绝地发送 fetch 哀求给 leader 副本以同步消息,如果 leader 在整个集群运行过程中不发生故障,follower 副本不会起到任何作用,标题就在于任何体系都不能保证其稳定运行,当 leader 副当地点的 broker 崩溃之后,此中一个 follower 副本就会成为该分区下新的 leader 副本,那么标题来了,在选为新的 leader 副本时,会导致消息丢失大概离散吗?Kafka 是怎样办理 leader 副本变动时消息不会出错?以及 leader 与 follower 副本之间的数据同步是怎样举行的?带着这几个标题,我们接着往下看,一起揭开 Kafka 水印备份的神秘面纱。
水印相干概念

在教学水印备份之前,我们必须要先搞清楚几个关键的术语以及它们的含义,下面我用一张图来表示 Kafka 分区副本的位移信息:

如上图所示,绿色部门表现已完全备份的消息,对消费者可见,紫色部门表现未完全备份的消息,对消费者不可见。
LEO(last end offset):日志末了位移,记载了该副本对象底层日志文件中下一条消息的位移值,副本写入消息的时间,会自动更新 LEO 值。
HW(high watermark):从名字可以知道,该值叫高水印值,HW 肯定不会大于 LEO 值,小于 HW 值的消息被以为是“已提交”或“已备份”的消息,并对消费者可见。
leader 会生存两个范例的 LEO 值,一个是自己的 LEO,另一个是 remote LEO 值,remote LEO 值就是 follower 副本的 LEO 值,意味着 follower 副本的 LEO 值会生存两份,一份生存到 leader 副本中,一份生存到自己这里。
remote LEO 值有什么用呢?
它是决定 HW 值巨细的关键,当 HW 要更新时,就会对比 LEO 值(也包罗 leader LEO),取最小的谁人做最新的 HW 值。
以下介绍 LEO 和 HW 值的更新机制:
LEO 更新机制:

  • leader 副本自身的 LEO 值更新:在 Producer 消息发送过来时,即 leader 副本当前最新存储的消息位移位置 +1;
  • follower 副本自身的 LEO 值更新:从 leader 副本中 fetch 到消息并写到当地日志文件时,即 follower 副本当前同步 leader 副本最新的消息位移位置 +1;
  • leader 副本中的 remote LEO 值更新T媚课 follower 副本发送 fetch 哀求都会包含 follower 当前 LEO 值,leader 拿到该值就会实验更新 remote LEO 值。
leader HW 更新机制:
leader HW 更新分为故障时更新与正常时更新:
故障时更新:

  • 副本被选为 leader 副本时:当某个 follower 副本被选为分区的 leader 副本时,kafka 就会实验更新 HW 值;
  • 副本被踢出 ISR 时:如果某个副本追不上 leader 副本进度,大概地点 broker 崩溃了,导致被踢出 ISR,leader 也会查抄 HW 值是否必要更新,毕竟 HW 值更新只跟处于 ISR 的副本 LEO 有关系。
正常时更新:

  • producer 向 leader 副本写入消息时:在消息写入时会更新 leader LEO 值,因此必要再查抄是否必要更新 HW 值;
  • leader 处置惩罚 follower FETCH 哀求时:follower 的 fetch 哀求会携带 LEO 值,leader 会根据这个值更新对应的 remote LEO 值,同时也必要查抄是否必要更新 HW 值。
follower HW 更新机制:

  • follower 更新 HW 发生在其更新 LEO 之后,每次 follower Fetch 响应体都会包含 leader 的 HW 值,然后比力当前 LEO 值,取最小的作为新的 HW 值。
图解水印备份过程

在相识了 Kafka 水印备份机制的相干概念之后,下面我用图来帮各人更好地明白 Kafka 的水印备份过程,假设某个分区有两个副本,min.insync.replica=1:

Step 1:leader 和 follower 副本处于初始化值,follower 副本发送 fetch 哀求,由于 leader 副本没有数据,因此不会举行同步操纵;
Step 2:生产者发送了消息 m1 到分区 leader 副本,写入该条消息后 leader 更新 LEO = 1;
Step 3:follower 发送 fetch 哀求,携带当前最新的 offset = 0,leader 处置惩罚 fetch 哀求时,更新 remote LEO = 0,对比 LEO 值最小为 0,所以 HW = 0,leader 副本响应消息数据及 leader HW = 0 给 follower,follower 写入消息后,更新 LEO 值,同时对比 leader HW 值,取最小的作为新的 HW 值,此时 follower HW = 0,这也意味着,follower HW 是不会超过 leader HW 值的。
Step 4:follower 发送第二轮 fetch 哀求,携带当前最新的 offset = 1,leader 处置惩罚 fetch 哀求时,更新 remote LEO = 1,对比 LEO 值最小为 1,所以 HW = 1,此时 leader 没有新的消息数据,所以直接返回 leader HW = 1 给 follower,follower 对比当前最新的 LEO 值 与 leader HW 值,取最小的作为新的 HW 值,此时 follower HW = 1。
基于水印备份机制的一些缺陷

从以上步调可看出,leader 中生存的 remote LEO 值的更新总是必要额外一轮 fetch RPC 哀求才华完成,这意味着在 leader 切换过程中,会存在数据丢失以及数据不同等的标题,下面我用图来说明存在的标题:

  • 数据丢失

前面也说过,leader 中的 HW 值是在 follower 下一轮 fetch RPC 哀求中完成更新的,如上图所示,有副本 A 和 B,此中 B 为 leader 副本,A 为 follower 副本,在 A 举行第二段 fetch 哀求,并吸取到响应之后,此时 B 已经将 HW 更新为 2,如果这是 A 还没处置惩罚完响应就崩溃了,即 follower 没有及时更新 HW 值,A 重启时,会自动将 LEO 值调解到之前的 HW 值,即会举行日志截断,接着会向 B 发送 fetch 哀求,但很不幸的是此时 B 也发生宕机了,Kafka 会将 A 选举为新的分区 Leader。当 B 重启后,会从 向 A 发送 fetch 哀求,收到 fetch 响应后,拿到 HW 值,并更新当地 HW 值,此时 HW 被调解为 1(之前是 2),这时 B 会做日志截断,因此,offsets = 1 的消息被永世地删除了。
大概你会问,follower 副本为什么要举行日志截断?
这是由于消息会先记载到 leader,follower 再从 leader 中拉取消息举行同步,这就导致 leader LEO 会比 follower 的要大(ollower之间的offset也不尽雷同,固然终极会同等,但过程中会有差异),假设此时出现 leader 切换,有大概选举了一个 LEO 较小的 follower 成为新的 leader,这时该副本的 LEO 就会成为新的尺度,这就会导致 follower LEO 值有大概会比 leader LEO 值要大的情况,因此 follower 在举行同步之前,必要从 leader 获取 LastOffset 的值(该值反面会有解释),如果 LastOffset 小于 当前 LEO,则必要举行日志截断,然后再从 leader 拉取数据实现同步。
大概你还会问,日志截断会不会造成数据丢失?
前面也说过,HW 值以上的消息是没有“已提交”或“已备份”的,因此消息也是对消费者不可见,即这些消息不对用户作答应,也便是说从 HW 值截断日志,并不会导致数据丢失(答应用户范围内)。

  • 数据不同等/离散

以上情况,必要满意以下此中一个条件才会发生:

  • 宕机之前,B 已不在 ISR 列表中,unclean.leader.election.enable=true,即答应非 ISR 中副本成为 leader;
  • B 消息写入到 pagecache,但尚未 flush 到磁盘。
分区有两个副本,此中 A 为 Leader 副本,B 为 follower 副本,A 已经写入两条消息,且 HW 更新到 2,B 只写了 1条消息,HW 为 1,此时 A 和 B 同时宕机,B 先重启,B 成为了 leader 副本,这时生产者发送了一条消息,生存到 B 中,由于此时分区只有 B,B 在写入消息时把 HW 更新到 2,就在这时间 A 重新启动,发现 leader HW 为 2,跟自己的 HW 一样,因此没有执行日志截断,这就造成了 A 的 offset=1 的日志与 B 的 offset=1 的日志不一样的征象。
leader epoch

为相识决 HW 更新时机是异步耽误的,而 HW 又是决定日志是否备份成功的标志,从而造成数据丢失和数据不同等的征象,Kafka 引入了 leader epoch 机制,在每个副本日志目录下都创建一个 leader-epoch-checkpoint 文件,用于生存 leader 的 epoch 信息,如下,leader epoch 长如许:

它的格式为 (epoch offset),epoch指的是 leader 版本,它是一个单调递增的一个正整数值,每次 leader 变动,epoch 版本都会 +1,offset 是每一代 leader 写入的第一条消息的位移值,比如:
  1. (0, 0)(1, 300)
复制代码
以上第二个版本是从位移300开始写入消息,意味着第一个版本写入了 0-299 的消息。
leader epoch 具体的工作机制如下:
1)当副本成为 leader 时:
这时,如果此时生产者有新消息发送过来,会起首新的 leader epoch 以及 LEO 添加到 leader-epoch-checkpoint 文件中。
2)当副本变成 follower 时:

  • 发送 LeaderEpochRequest 哀求给 leader 副本,该哀求包罗了 follower 中最新的 epoch 版本;
  • leader 返回给 follower 的相应中包含了一个 LastOffset,如果 follower last epoch = leader last epoch,则 LastOffset = leader LEO,否则取大于 follower last epoch 中最小的 leader epoch 的 start offset 值,举个例子:假设 follower last epoch = 1,此时 leader 有 (1, 20) (2, 80) (3, 120),则 LastOffset = 80;
  • follower 拿到 LastOffset 之后,会对比当前 LEO 值是否大于 LastOffset,如果当前 LEO 大于 LastOffset,则从 LastOffset 截断日志;
  • follower 开始发送 fetch 哀求给 leader 保持消息同步。
基于 leader epoch 的工作机制,我们接下来看看它是怎样办理水印备份缺陷的:
(1)办理数据丢失:

如上图所示,A 重启之后,发送 LeaderEpochRequest 哀求给 B,由于 B 还没追加消息,此时 epoch = request epoch = 0,因此返回 LastOffset = leader LEO = 2 给 A,A 拿到 LastOffset 之后,发现便是当前 LEO 值,故不用举行日志截断。就在这时 B 宕机了,A 成为 leader,在 B 启动返来后,会重复 A 的动作,同样不必要举行日志截断,数据没有丢失。
(2)办理数据不同等/离散

如上图所示,A 和 B 同时宕机后,B 先重启返来成为分区 leader,这时间生产者发送了一条消息过来,leader epoch 更新到 1,此时 A 启动返来后,发送 LeaderEpochRequest(follower epoch = 0) 给 B,B 判定 follower epoch 不便是 最新的 epoch,于是找到大于 follower epoch 最小的 epoch = 1,即 LastOffset = epoch start offset = 1,A 拿到 LastOffset 后,判定小于当前 LEO 值,于是从 LastOffset 位置举行日志截断,接着开始发送 fetch 哀求给 B 开始同步消息,制止了消息不同等/离散的标题。
更多出色文章请关注作者维护的公众号「后端进阶」,这是一个专注后端相干技术的公众号。
关注公众号并复兴「后端」免费领取后端相干电子册本。
接待分享,转载请生存出处。


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver|手机版|小黑屋|深圳论坛-深圳人的网上家园  

GMT+8, 2020-7-13 19:49 , Processed in 0.112565 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表