共计 2195 个字符,预计需要花费 6 分钟才能阅读完成。
上一篇有很大一部分也提到了正本同步机制,但有些细节点没提到,这里再转载一篇文章来聊聊正本同步机制。
正本同步机制
咱们晓得,kafka 每个 topic 的 partition 会有 N 个正本,kafka 通过多正本机制实现故障主动转移,当 kafka 集群中一个 broker 生效状况下,会在 N 个正本中从新选出一个 broker 作为 leader 提供服务,从而做到高可用。N 个正本中,其中一个为 leader,其余的都为 follower,leader 解决 partition 的所有读写申请,follower 会定期地复制 leader 上的数据。
Kafka 提供了数据复制算法,如果 leader 产生故障或挂掉,Kafka 确保从同步正本列表中选举一个正本为 leader,新 leader 被选举并被承受客户端的音讯写入。leader 负责保护 ISR(In-Sync Replicas 的缩写,示意正本同步队列)中所有音讯。当 producer 发送一条音讯到 broker 后,leader 写入音讯,并复制到所有 follower。音讯提交之后才被胜利复制到所有的同步正本。音讯复制提早受最慢的 follower 限度,kafka 会检测慢正本,如果 follower“落后”太多或者失败,leader 将会把他从 ISR 中删除。
正本同步队列 ISR
所谓同步,必须满足两个条件:
- 正本节点必须能与 zookeeper 放弃会话(心跳机制)
- 副本能复制 leader 上的所有写操作,并且不能落后太多(卡主或滞后的正本管制由 replica.lag.time.max.ms 配置)
默认状况下,Kafka topic 的 replica 数量为 1,即每个 partition 都有一个惟一的 leader,为了确保音讯的可靠性,通常利用中将其值(由 broker 的参数 offsets.topic.replication.factor 指定)大小设定为 1。所有的正本(replicas)统称为 AR (Assigned Replicas)。ISR 是 AR 的一个子集,由 leader 保护 ISR 列表,follower 从 Leader 同步数据有一些提早,任意一个超过阈值都会把 follower 踢出 ISR,存入 OSR(Outof-Sync Replicas)列表,新退出的 follower 也会先寄存到 OSR 中。AR = ISR + OSR
HW(HighWatermark)俗称 高水位,取一个 partition 对应的 ISR 中最小的 LEO 作为 HW,consumer 最多只能生产到 HW 所在的地位。另外每个 replica 都有 HW,leader 和 follower 各自负责更新本人的 HW 的状态。对于 leader 新写入的音讯,consumer 不能立刻生产,leader 会期待该音讯被所有 ISR 中的 replicas 都同步后,才更新 HW,此时音讯能力被 consumer 生产,这样就保障了如果 Leader 所在的 broker 生效,该音讯仍可从新选举的 leader 中获取。对于来自外部的 broker 的读取申请,没有 HW 的限度。
下图具体阐明了当 producer 生产音讯到 broker 后,ISR 及 HW 和 LEO(log end offset)的流转过程:
由此可见,Kafka 的复制机制既不是齐全的同步复制,也不是单纯的异步复制。事实上,同步机制要求所有能工作的 follower 都复制完,这条音讯才会被 commit,这种复制形式极大的影响了吞吐率。而异步复制形式下,follower 异步的从 leader 复制数据,数据只有被 Leader 写入 log 就被工作曾经 commit,这种状况下如果 follower 没有全复制完,落后与 Leader,忽然 leader 宕机,则会丢数据。而 Kafka 这种应用 ISR 的形式则很好的平衡了确保数据不失落以及吞吐率。
Kafka 的 ISR 治理最终都会反馈到 Zookeeper 节点上,具体位置为:
/brokers/topics/[topic]/partitions/[partition]/state。目前有两个中央会对这个 Zookeeper 节点进行保护:
- Controller 保护:Kafka 集群中的其中一个 Broker 会被选举为 Controller,次要负责 Partition 治理和正本状态治理,也会执行相似于重调配 partition 之类的治理工作。在合乎某些特定条件下,Controller 下的 LeaderSelector 会选举新的 leader, ISR 和新的 leader_epoch 及 controller_epoch 写入 Zookeeper 的相干节点中。同时发动 LeaderAndIsrRequest 告诉所有的 replicas。
- leader 来保护:leader 有独自的线程定期检查 ISR 中 follower 是否脱离 ISR,如果发现 ISR 变动,则会将新的 ISR 的信息返回到 Zookeeper 的相干节点中。
正本不同的异常情况:
- 慢正本:在肯定周期时间内,follower 不能追赶上 leader。最常见的起因之一是 IO 瓶颈导致 follower 追加复制音讯速度鳗鱼从 leader 拉取速度
- 正本卡住:在肯定周期时间内,follower 进行从 leader 拉取申请。follower replica 卡住了是因为 GC 暂停或 follower 生效或死亡。
- 新启动正本:当用户给 topic 减少正本因子时,新的 follower 不再同步正本列表中,直到他们齐全追赶上 leader 日志。