Kafka的replica同步机制：ISR与OSR列表数据相互转换
Kafka的replica同步机制：ISR与OSR列表数据相互转换
Apache Kafka的复制协议是其核心特性之一。在集群中，每个Broker需要处理不同工作负载的情况下，如何自动调优Kafka副本的工作方式是一个挑战。特别是如何避免follower副本进入和退出同步副本列表（ISR）的问题。本文将深入探讨Kafka的replica同步机制，包括ISR与OSR列表的转换，以及如何解决follower副本不同步的问题。
Kafka副本机制
在Kafka中，每个主题的Partition都有一个预写式日志文件。每个Partition由一系列有序的、不可变的消息组成，这些消息被连续追加到Partition中。每个消息都有一个连续的序列号，称为offset，用于唯一标识其在分区日志中的位置。
Kafka为每个topic的partition配置了N个副本，其中N是topic的复制因子。通过多副本机制实现故障自动转移，即使在Broker失效的情况下也能保证服务的可用性。在Kafka中，N个replicas中，其中一个replica为leader，其他都为follower。leader负责处理Partition的所有读写请求，而follower则定期复制leader上的数据。
Kafka的复制算法确保了在leader发生故障时，可以从ISR中选举一个新的leader。leader负责维护和跟踪ISR中所有follower的滞后状态。当生产者发送一条消息到Broker时，leader会将消息写入并复制到所有follower。消息只有在成功复制到所有的同步副本后才会被提交。消息复制的延迟主要受最慢的follower限制，因此快速检测慢副本非常重要。如果follower“落后”太多或失效，leader会将其从ISR中移除。
Partition中Follower追赶Leader的含义
在Kafka中，如果一个partition的follower副本没有“赶上”leader的日志，它可能会被从ISR中移除。下面通过一个具体例子来解释“追赶”的含义：
假设有一个主题名为foo，包含1个partition和3个replicas。这个partition的replication分布在Brokers 1、2和3上，其中Broker 3已经成功提交了消息。在同步副本列表中，Broker 1是leader，Broker 2和Broker 3是follower。假设replica.lag.max.messages设置为4，这意味着只要follower落后leader不超过3条消息，就不会从ISR中移除。replica.lag.time.max设置为500 ms，表示只要follower向leader发送请求的时间间隔不超过500 ms，就不会被标记为死亡或从ISR中移除。
现在，假设生产者发送下一条消息写入leader，与此同时follower Broker 3发生了GC暂停：
直到follower Broker 3从ISR中移除或追赶上leader的log end offset，最新的消息才会被认为是提交的。由于follower Broker 3落后于leader Broker 1的消息数量小于replica.lag.max.messages（即4），Kafka不会将其从ISR中移除。在这种情况下，follower Broker 3需要追赶上直到offset = 6，以完全“赶上” leader Broker 1的log end offset。假设Broker 3在100 ms内从GC暂停中恢复并追赶上leader的日志结束偏移量。在这种状态下，partition的日志会看起来像这样：
导致Follower与Leader不同步的原因
一个副本不同步于Leader可能有以下原因：
- 慢副本：在一定周期时间内，follower不能追赶上leader。最常见的原因之一是I/O瓶颈导致follower追加复制消息的速度慢于从leader拉取的速度。
- 卡住的副本：在一定周期时间内，follower停止从leader拉取请求。这可能是由于GC暂停、follower失效或死亡。
- 新启动的副本：当用户给主题增加副本因子时，新的follower一开始不会在ISR中，直到它们完全赶上了leader的日志。
一个partition的follower落后于leader足够多时，被认为不在ISR中或处于滞后状态。在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会从ISR中移除慢副本，以避免消息写延迟增加。