9.Kafka复制

最新推荐文章于 2023-06-10 18:30:00 发布

原创最新推荐文章于 2023-06-10 18:30:00 发布 · 1.4k 阅读

0 ·

CC 4.0 BY-SA版权

kafka 专栏收录该内容

20 篇文章

订阅专栏

本文深入探讨了Kafka中的复制机制，包括副本的管理和分配、数据的同步与异步复制方式，以及面对不同故障场景时的应对策略。此外，文章还讨论了Kafka复制机制的设计考量，以达到高可用性和数据持久性的目标。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Kafka复制高级设计

在Kafka中添加复制的目的是为了更强的耐久性和更高的可用性。我们希望保证任何成功发布的消息不会丢失，并且可以被消费，即使有服务器故障。这种故障可能由机器错误，程序错误或更常见的软件升级引起。我们有以下高级目标：

可配置的持久性保证：例如，具有关键数据的应用程序可以选择更强的持久性，增加写入延迟，另一个产生大量软状态数据的应用程序可以选择更弱的持久性，但更好的写入响应时间。
自动复制管理：我们希望简化对代理服务器的副本分配，并能够增量式增长集群。

这里主要有两个问题需要解决：

如何将分区的副本均匀分配给代理服务器？
对于给定的分区，如何将每条消息传播到所有副本？

副本展示位置

初始展示位置

（仅创建主题，根据当前活动代理（手动创建主题命令）进行决策;重新平衡命令（基于新群集拓扑的重新计算分配，每个分区都移动）并进行移动）
我们首先使用管理api创建初始套经纪人：

 
          create cluster with brokers broker-
          0
          , broker-
          1
          , broker2

然后，我们使用另一个管理api创建一个新主题：

 
          create topic topicX with 
          100 
          partitions

之后，以下信息将在zookeeper中注册：

经纪人名单;
主题列表和每个主题的分区列表。

为了更好的负载均衡，我们要过度分区一个主题。通常，将有比服务器更多的分区。对于每个主题，我们希望在所有代理之间平均分配分区。我们对代理和分区列表的列表进行排序。如果有n个代理，我们将第i个分区分配给第（i mod n）个代理。此分区的第一个副本将驻留在此分配的代理上，并被称为此分区的首选副本。我们要放置其他副本，使得如果代理关闭，它的负载被均匀地分布到所有幸存的代理，而不是一个单一的。为了实现这一点，假设有分配给代理i的m个分区。分区k的第j个副本将被分配给broker（i + j + k）mod n。下图说明了代理broker-0到broker-4上分区p0到p14的副本分配。在此示例中，如果代理0关闭，则可以从所有剩余的4个代理提供分区p0，p1和p2。我们将关于ach分区的副本分配的信息存储在Zookeeper中。

在线增量添加代理

我们希望能够使用像下面这样的管理命令来递增地增加代理集。

 
          alter cluster add brokers broker-
          3
          , broker-
          4

当添加新代理时，我们将自动将一些分区从现有代理移动到新代理。Out目标是最小化数据移动量，同时在每个代理上保持平衡负载。我们使用独立的协调器进程来进行重新平衡，算法如下。

离线经纪人

我们还希望通过使用像下面这样的管理命令使现有的代理集离线来支持缩减集群。

 
          alter cluster remove brokers broker-
          1

这将为当前托管在broker-1上的分区启动重新分配过程。一旦完成，代理1将离线。此命令还将删除代理1的状态更改路径

数据复制

我们希望允许客户端选择异步或同步复制。在前一种情况下，一旦到达1个副本，就会确认要发布的消息。在后一种情况下，我们将尽最大努力确保消息仅在到达多个副本后才被确认。当客户端尝试将消息发布到主题的分区时，我们需要将消息传播到所有副本。我们必须决定：

如何传播消息;
在我们向客户端确认之前有多少个副本接收到该消息;
当副本崩溃时会发生什么？
当失败的副本再次回来时会发生什么。

我们在第2.1节中介绍现有的复制策略。然后我们分别在2.2节和2.3节描述我们的同步和异步复制。

同步复制

我们的同步复制遵循典型的主要备份方法。每个分区具有n个副本，并且可以容忍n-1个副本故障。其中一个副本被选为领导者，其余的副本是追随者。领导者维护一组同步副本（ISR）：一组完全赶上领导者的副本。对于每个分区，我们在Zookeeper中存储当前的leader和当前的ISR。

每个副本将消息存储在本地日志中，并在日志中维护几个重要的偏移位置（如图1所示）。日志末尾偏移（LEO）表示日志的尾部。高水印（HW）是最后提交的消息的偏移。每个日志会定期同步到磁盘。刷新偏移之前的数据被保证保留在磁盘上。正如我们将看到的，刷新偏移可以在HW之前或之后。

写

要将消息发布到分区，客户端首先从Zookeeper找到分区的leader，并将消息发送到leader。领导者将消息写入其本地日志。每个追随者经常使用单个套接字通道从领导者拉出新消息。这样，追随者接收与写在领导者中的相同的顺序的所有消息。跟随器将每个接收到的消息写入其自己的日志，并将确认发送回领导者。一旦领导从ISR中的所有副本接收到确认，则该消息被提交。领导者提前HW并向客户端发送确认。为了更好的性能，每个跟随器在消息写入存储器之后发送确认。因此，对于每个提交的消息，我们保证消息存储在内存中的多个副本中。然而，但是不能保证任何副本都将提交消息持久化到磁盘。鉴于相关的故障相对较少，这种方法使我们在响应时间和耐久性之间有一个很好的平衡。在未来，我们可能会考虑增加提供更有力保证的选项。领导者还定期向所有追随者广播HW。广播可以捎带在来自跟随者的获取请求的返回值上。有时，每个副本将其HW检查到其磁盘。领导者还定期向所有追随者广播HW。广播可以捎带在来自跟随者的获取请求的返回值上。有时，每个副本将其HW检查到其磁盘。领导者还定期向所有追随者广播HW。广播可以捎带在来自跟随者的获取请求的返回值上。有时，每个副本将其HW检查到其磁盘。

阅读

为简单起见，读取总是由领导提供。只有到HW的消息才会暴露给读取器。

故障场景

跟随器故障

在配置的超时时间之后，领导者将从其ISR中丢弃失败的跟随者，并且写入将在ISR中的剩余副本上继续。如果失败的跟随者回来，它首先将其日志截断到最后一个检查点的HW。然后它开始赶上所有的消息，在其HW之后的领导。当跟随者完全赶上时，领导者将其添加回当前的ISR。

领导失败

有3例领导失败，应该考虑 -

领导者在将消息写入其本地日志之前崩溃。在这种情况下，客户端将超时并重新发送消息到新的领导。
领导者在将消息写入其本地日志之后，但在将响应发送回客户端之前崩溃
1. 原子性必须得到保证：所有副本都写消息，或者没有
2. 客户端将重试发送消息。在这种情况下，系统应该理想地确保消息不被写入两次。也许，其中一个副本已经将消息写入其本地日志，承诺它，它被选为新的领导者。
发送响应后，引导程序崩溃。在这种情况下，将选择新的领导者并开始接收请求。

当发生这种情况时，我们需要执行以下步骤来选择新的领导者。

ISR中的每个存活的副本在Zookeeper中注册它自己。
首先注册的副本成为新的领导者。新领导者选择其LEO作为新硬件。
每个副本在Zookeeper中注册一个监听器，以便它被通知任何领导更改。每当一个副本被通知一个新的领导：
1. 如果副本不是新的领导者（它必须是追随者），它会将其日志截断到其HW，然后开始赶上新领导者。
领导等待，直到ISR中的所有幸存的副本已经赶上或配置的时间已经过去。领导者将当前的ISR写入Zookeeper，并为读取和写入打开自身。

（注意，在ISR为空时的初始启动期间，任何副本都可以成为领导者。