图文了解 Kafka 的副本复制机制

让分布式系统的操做变得简单，在某种程度上是一种艺术，一般这种实现都是从大量的实践中总结获得的。Apache Kafka 的受欢迎程度在很大程度上归功于其设计和操做简单性。随着社区添加更多功能，开发者们会回过头来从新思考简化复杂行为的方法。

Apache Kafka 中一个更细微的功能是它的复制协议（replication protocol）。对于单个集群上不一样大小的工做负载，调整 Kafka replication 以让它适用不一样状况在今天来看是有点棘手的。使这点特别困难的挑战之一是如何防止副本从同步副本列表（也称为ISR）加入和退出。从用户的角度来看，这意味着若是生产者（producer ）发送一批“足够大”的消息，那么这可能会致使 Kafka brokers 发出多个警报。这些警报代表某些主题“未被复制”（under replicated），这意味着数据未被复制到足够多的 brokers 上，从而增长数据丢失的可能性。所以，Kafka cluster 密切监控“未复制的”分区总数很是重要。在这篇文章中，我将讨论致使这种行为的根本缘由以及咱们如何解决这个问题。

一分钟了解 Kafka 复制机制

Kafka 主题中的每一个分区都有一个预写日志（write-ahead log），咱们写入 Kafka 的消息就存储在这里面。这里面的每条消息都有一个惟一的偏移量，用于标识它在当前分区日志中的位置。以下图所示：

Kafka 中的每一个主题分区都被复制了 n 次，其中的 n 是主题的复制因子（replication factor）。这容许 Kafka 在集群服务器发生故障时自动切换到这些副本，以便在出现故障时消息仍然可用。Kafka 的复制是以分区为粒度的，分区的预写日志被复制到 n 个服务器。 在 n 个副本中，一个副本做为 leader，其余副本成为 followers。顾名思义，producer 只能往 leader 分区上写数据（读也只能从 leader 分区上进行），followers 只按顺序从 leader 上复制日志。

日志复制算法（log replication algorithm）必须提供的基本保证是，若是它告诉客户端消息已被提交，而当前 leader 出现故障，新选出的 leader 也必须具备该消息。在出现故障时，Kafka 会从挂掉 leader 的 ISR 里面选择一个 follower 做为这个分区新的 leader ；换句话说，是由于这个 follower 是跟上 leader 写进度的。

每一个分区的 leader 会维护一个 in-sync replica（同步副本列表，又称 ISR）。当 producer 往 broker 发送消息，消息先写入到对应 leader 分区上，而后复制到这个分区的全部副本中。只有将消息成功复制到全部同步副本（ISR）后，这条消息才算被提交。因为消息复制延迟受到最慢同步副本的限制，所以快速检测慢副本并将其从 ISR 中删除很是重要。 Kafka 复制协议的细节会有些细微差异，本博客并不打算对该主题进行详尽的讨论。感兴趣的同窗能够到这里详细了解 Kafka 复制的工做原理。

副本在什么状况下才算跟上 leader

一个副本若是它没有跟上 leader 的日志进度，那么它可能会被标记为不一样步的副本。我经过一个例子来解释跟上（caught up）的含义。假设咱们有一个名为 foo 的主题，而且只有一个分区，同时复制因子为 3。假设此分区的副本分别在 brokers 1，2和3上，而且咱们已经在主题 foo 上提交了3条消息。brokers 1上的副本是 leader，副本2和3是 followers，全部副本都是 ISR 的一部分。假设 replica.lag.max.messages 设置为4，这意味着只要 follower 落后 leader 的消息不超过3条，它就不会从 ISR 中删除。咱们把 replica.lag.time.max.ms 设置为500毫秒，这意味着只要 follower 每隔500毫秒或更早地向 leader 发送一个 fetch 请求，它们就不会被标记为死亡而且不会从 ISR 中删除。

 

如今假设 producer 往 leader 上发送下一条消息，与此同时，broker 3 上发生了 GC 停顿，如今每一个 broker 上的分区状况以下所示：

因为 broker 3 在 ISR中，所以在将 broker 3从 ISR 中移除或 broker 3 上的分区跟上 leader 的日志结束偏移以前，最新消息都是不认为被提交的。注意，因为 border 3 落后 leader 的消息比 replica.lag.max.messages = 4 要小，所以不符合从 ISR 中删除的条件。这意味着 broker 3 上的分区须要从 leader 上同步 offset 为 3 的消息，若是它作到了，那么这个副本就是跟上 leader 的。假设 broker 3 在 100ms 内 GC 完成了，而且跟上了 leader 的日志结束偏移，那么最新的状况以下图：

 

什么状况下会致使一个副本与 leader 失去同步

一个副本与 leader 失去同步的缘由有不少，主要包括：

• 慢副本（Slow replica）：follower replica 在一段时间内一直没法遇上 leader 的写进度。形成这种状况的最多见缘由之一是 follower replica 上的 I/O瓶颈，致使它持久化日志的时间比它从 leader 消费消息的时间要长；

• 卡住副本（Stuck replica）：follower replica 在很长一段时间内中止从 leader 获取消息。这多是觉得 GC 停顿，或者副本出现故障；

• 刚启动副本（Bootstrapping replica）：当用户给某个主题增长副本因子时，新的 follower replicas 是不一样步的，直到它跟上 leader 的日志。

当副本落后于 leader 分区时，这个副本被认为是不一样步或滞后的。在 Kafka 0.8.2 中，副本的滞后于 leader 是根据 replica.lag.max.messages 或 replica.lag.time.max.ms 来衡量的； 前者用于检测慢副本（Slow replica），然后者用于检测卡住副本（Stuck replica）。

如何确认某个副本处于滞后状态

经过 replica.lag.time.max.ms 来检测卡住副本（Stuck replica）在全部状况下都能很好地工做。它跟踪 follower 副本没有向 leader 发送获取请求的时间，经过这个能够推断 follower 是否正常。另外一方面，使用消息数量检测不一样步慢副本（Slow replica）的模型只有在为单个主题或具备同类流量模式的多个主题设置这些参数时才能很好地工做，但咱们发现它不能扩展到生产集群中全部主题。在我以前的示例的基础上，若是主题 foo 以 2 msg/sec 的速率写入数

据，其中 leader 收到的单个批次一般永远不会超过3条消息，那么咱们知道这个主题的 replica.lag.max.messages 参数能够设置为 4。为何？ 由于咱们以最大速度往 leader 写数据而且在 follower 副本复制这些消息以前，follower 的日志落后于 leader 不超过3条消息。同时，若是主题 foo 的 follower 副本始终落后于 leader 超过3条消息，则咱们但愿 leader 删除慢速 follower 副本以防止消息写入延迟增长。

这本质上是 replica.lag.max.messages 的目标 - 可以检测始终与 leader 不一样步的副本。假设如今这个主题的流量因为峰值而增长，生产者最终往 foo 发送了一批包含4条消息，等于 replica.lag.max.messages = 4 的配置值。此时，两个 follower 副本将被视为与 leader 不一样步，并被移除 ISR。

 

可是，因为两个 follower 副本都处于活动状态，所以它们将在下一个 fetch 请求中遇上 leader 的日志结束偏移量并被添加回 ISR。若是生产者继续向 leader 发送大量的消息，则将重复上述相同的过程。这证实了 follower 副本进出 ISR 时触发没必要要的错误警报的状况。

 

 

replica.lag.max.messages 参数的核心问题是，用户必须猜想如何配置这个值，由于咱们不知道 Kafka 的传入流量到底会到多少，特别是在网络峰值的状况下。

一个参数搞定一切

咱们意识到，检测卡住或慢速副本真正重要的事情，是副本与 leader 不一样步的时间。咱们删除了经过猜想来设置的 replica.lag.max.messages 参数。如今，咱们只须要在服务器上配置 replica.lag.time.max.ms 参数便可；这个参数的含义为副本与 leader 不一样步的时间。

检测卡住副本（Stuck replica）的方式与之前相同 - 若是副本未能在 replica.lag.time.max.ms 时间内发送 fetch 请求，则会将其视为已死的副本并从 ISR 中删除；

检测慢副本的机制已经改变 - 若是副本落后于 leader 的时间超过 replica.lag.time.max.ms，则认为它太慢而且从 ISR 中删除。

所以，即便在峰值流量下，生产者往 leader 发送大量的消息，除非副本始终和 leader 保持 replica.lag.time.max.ms 时间的落后，不然它不会随机进出 ISR。