Kafka 的 replica 同步机制（ISR 与 OSR 列表数据相互转换）

确定它在分区日志中唯一的位置。?

Kafka 每个 topic 的 partition 有 N 个副本，其中 N 是 topic 的复制因子。Kafka 通过多副本机制实现故障自动转移，当 Kafka 集群中一个 Broker 失效情况下仍然保证服务可用。在 Kafka 中发生复制时确保 partition 的预写式日志有序地写到其他节点上。N 个 replicas 中。其中一个 replica 为 leader，其他都为 follower，leader 处理 partition 的所有读写请求，与此同时，follower 会被动定期地去复制 leader 上的数据。?

Kafka 必须提供数据复制算法保证,如果 leader 发生故障或挂掉，一个新 leader 被选举并接收客户端的消息成功写入。Kafka 确保从同步副本列表中选举一个副本为 leader,或者换句话说,follower 追赶 leader 数据。leader 负责维护和跟踪 ISR 中所有 follower 滞后状态。当生产者发送一条消息到 Broker,leader 写入消息并复制到所有 follower。消息提交之后才被成功复制到所有的同步副本。消息复制延迟受最慢的 follower 限制,重要的是快速检测慢副本,如果 follower”落后”太多或者失效,leader 将会把它从 replicas 从 ISR 移除。

二、Partition 中 Follower 追上 Leader 的含义

Kafka 中每个 partition 的 follower 没有“赶上”leader 的日志可能会从同步副本列表中移除。下面用一个例子解释一下“追赶”到底是什么意思。请看一个例子：主题名称为 foo 1 partition 3 replicas。假如 partition 的 replication 分布在 Brokers 1、2 和 3 上，并且 Broker 3 消息已经成功提交。同步副本列表中 1 为 leader、2 和 3 为 follower。假设 replica.lag.max.messages 设置为 4，表明只要 follower 落后 leader 不超过 3，就不会从同步副本列表中移除。replica.lag.time.max 设置为 500 ms，表明只要 follower 向 leader 发送请求时间间隔不超过 500 ms，就不会被标记为死亡,也不会从同步副本列中移除。?

下面看看，生产者发送下一条消息写入 leader，与此同时 follower Broker 3 GC 暂停，如下图所示:?

直到 follower Broker 3 从同步副本列表中移除或追赶上 leader log end offset，最新的消息才会认为提交。注意,因为 follower Broker 3 小于 replica.lag.max.messages= 4 落后于 leader Broker 1，Kafka 不会从同步副本列表中移除。在这种情况下,这意味着 follower Broker 3 需要迎头追赶上知道 offset = 6,如果是,那么它完全“赶上” leader Broker 1 log end offset。让我们假设代理 3 出来的 GC 暂停在 100 ms 和追赶上领袖的日志结束偏移量。在这种状态下，下面 partition 日志会看起来像这样?

三、是什么原因导致分区的 Follower 与 Leader 不同步

一个副本不同步 Leader 有如下几个原因：

• 慢副本：在一定周期时间内 follower 不能追赶上 leader。最常见的原因之一是 I / O 瓶颈导致 follower 追加复制消息速度慢于从 leader 拉取速度。

• 卡住副本：在一定周期时间内 follower 停止从 leader 拉取请求。follower replica 卡住了是由于 GC 暂停或 follower 失效或死亡。

• 新启动副本：当用户给主题增加副本因子时，新的 follower 不在同步副本列表中，直到他们完全赶上了 leader 日志。

一个 partition 的 follower 落后于 leader 足够多时，被认为不在同步副本列表或处于滞后状态。在 Kafka-0.8.2.x 中,副本滞后判断依据是副本落后于 leader 最大消息数量(replica.lag.max.messages)或 replicas 响应 partition leader 的最长等待时间(replica.lag.time.max.ms)。前者是用来检测缓慢的副本,而后者是用来检测失效或死亡的副本

四、如何确定 Follower 是滞后的

这个模型检测不同步卡住副本列表工作下所有情况都适用。它追踪 follower replica 时间内没有向 leader 发送拉取请求,表明它已经死了。另一方面,如果均匀流量模式情况下，为一个主题或多个主题设置这些参数检测模型不同步慢副本列表消息的数量会工作很好,但我们发现生产环境中它不扩展到所有主题各种工作负载。

接着上面的例子,如果主题 foo 获取数据速率 2 msg/sec，leader 单次批量接收一般不会超过 3 条消息,然后你知道主题参数 replica.lag.max.messages 设置为 4。为什么?因为 follower replica 从 leader 复制消息前，已经有大批量消息写 leader，follower replica 落后于 leader 不超过 3 条消息 。另一方面，如果主题 foo 的 follower replica 初始落后于 leader 持续超过 3 消息,leader 会从同步副本列表中移除慢副本，避免消息写延迟增加。

这本质上是 replica.lag.max.messages 的目标。能够检测 follower 与 leader 不一致且从同步副本列表移除。然而,主题在流量高峰期发送了一批消息(4 条消息),等于 replica.lag.max.messages = 4 配置值。在那一瞬间,2 个 follower replica 将被认为是”out-of-sync”并且 leader 会从同步副本列表中移除。?

2 个 follower replica 都是活着,下次拉取请求他们会赶上 leade

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

r log end offset 并重新加入同步副本列表。重复相同的过程，如果生产者继续发送相对一批较大消息到 leader。这种情况演示了当 follower replica 频繁在从同步副本列表移除和重新加入同步副本列表之间来回切换时，不必要触发虚假警报。?