DevOps知识中心
DevOps知识中心

Kafka 复制配置：保障数据持久性与可用性

通过全面的复制配置，释放 Kafka 强大的数据持久性和高可用性潜力。本指南深入解读了 Kafka 的复制因子、同步副本（ISR）和领导者选举，提供了有关它们在容错能力中作用的实用见解。学习如何在 Broker 和 Topic 级别配置复制，理解生产者 `acks` 的交互机制，并实施机架感知复制等最佳实践。掌握所需知识，以构建弹性的 Kafka 集群，确保数据安全并能在 Broker 故障时持续运行。

33 浏览量

Kafka 复制配置：确保数据持久性和可用性和可用性

在分布式系统领域，数据的持久性（durability）和高可用性（high availability）至关重要。Kafka，作为领先的分布式事件流平台，通过其强大的复制机制实现了这些关键属性。理解并正确配置 Kafka 复制对于构建能够承受 Broker 故障并维持连续运行的弹性可靠的数据管道至关重要。

本文将深入探讨 Kafka 的复制策略，解释数据如何在多个 Broker 之间复制和维护的核心概念。我们将探索同步副本（In-Sync Replicas, ISRs）的作用、领导者选举的机制，以及这些元素如何共同促成容错能力。此外，我们还将提供在 Broker 级别和 Topic 级别配置复制的实用指南，以及确保数据安全和可访问性的最佳实践。

通过本指南的学习，您将全面了解 Kafka 复制，从而能够在面对意外故障时，配置您的集群以实现最佳的数据持久性和高可用性。

了解 Kafka 复制基础知识

Kafka 的架构依赖于分区（partitions）的概念来实现可扩展性和并行性。为了确保这些分区中的数据不会丢失，即使 Broker 发生故障也能保持可访问性，Kafka 采用了复制机制。每个分区都有多个副本（或称 replicas），分散在集群中的不同 Broker 上。

副本和分区

对于每个分区，存在两种类型的副本：

  • 领导者副本（Leader Replica）：每个分区只有一个副本被指定为领导者。领导者处理该分区的全部读写请求。生产者（Producers）总是写入领导者，消费者（Consumers）通常也从领导者读取。
  • 跟随者副本（Follower Replicas）：分区的所有其他副本都是跟随者。跟随者被动地从它们各自的分区领导者那里复制数据。它们的主要作用是充当备份，随时准备在领导者发生故障时接管。

复制因子

复制因子（Replication Factor） 定义了 Kafka 集群中一个分区拥有的副本数量。例如，复制因子设置为 3 意味着每个分区将有一个领导者和两个跟随者副本。更高的复制因子会增加持久性和可用性，但也会占用更多的磁盘空间和网络带宽。

同步副本（ISRs）

同步副本（In-Sync Replicas, ISRs） 是 Kafka 持久性保证的关键概念。ISR 是一个副本（可以是领导者或跟随者），它完全追赶上了领导者的进度，并被认为是“同步”的。Kafka 为每个分区维护一个 ISR 列表。这个列表至关重要，因为它关系到：

  • 持久性：当生产者发送消息并将确认设置（acks）设置为 all (或 -1) 时，它会等待所有 ISRs 都提交该消息后，才认为写入成功。这确保了消息持久地写入了多个 Broker。
  • 可用性：如果领导者 Broker 发生故障，则会从可用的 ISRs 中选举一个新的领导者。由于所有 ISRs 都拥有最新的数据，从这个集合中选举新领导者可以保证数据不丢失。

如果跟随者副本运行缓慢、停止获取数据或崩溃，它们可能会脱离同步状态。Kafka 会对此进行监控，如果一个跟随者滞后领导者太远（由 replica.lag.time.max.ms 控制），它就会被从 ISR 列表中移除。一旦它追赶上来，就可以重新加入 ISR 集合。

领导者选举：确保持续可用性

当分区当前的领导者副本变得不可用时（例如，由于 Broker 崩溃或网络问题），Kafka 会自动启动领导者选举过程。主要目标是从剩余的 ISRs 中选出一个新的领导者，以确保该分区保持可用于读写操作。

选举过程如下：

  1. 检测：集群控制器（Controller，它是 Kafka Broker 之一，被选举为控制器）检测到领导者故障。
  2. 选择：控制器从该分区剩余的 ISRs 中选择一个成为新的领导者。由于所有 ISRs 都保证具有相同且最新的数据，此过程可维护数据一致性。
  3. 更新：控制器通知集群中所有 Broker 有关新领导者的信息。

不洁净的领导者选举（Unclean Leader Election）

Kafka 提供了一个配置参数 unclean.leader.election.enable，它规定了当没有 ISRs 可用时（例如，所有 ISRs 同时崩溃）领导者选举的行为方式。

  • 如果 unclean.leader.election.enable 设置为 false（默认且推荐的设置），则如果 ISRs 不可用，Kafka 将不会选举新的领导者。这优先考虑数据持久性而非可用性，因为选举一个非 ISR 的跟随者可能导致数据丢失。
  • 如果 unclean.leader.election.enable 设置为 true，Kafka 将从任何可用的副本中选举新的领导者，即使它不是 ISR 并且可能尚未复制所有已提交的消息。这优先考虑可用性而非严格的数据持久性，冒着数据丢失的风险，但确保分区保持可操作。

警告：启用 unclean.leader.election.enable 应极其谨慎，通常只在可用性绝对关键且可以接受少量数据丢失风险的场景中（例如，非关键、临时性数据）。对于大多数生产系统，它应保持 false。

配置 Kafka 复制

复制设置可以在 Broker 级别（作为新 Topic 的默认值）和 Topic 级别（用于覆盖默认值或修改现有 Topic）进行配置。

Broker 级别配置

这些设置在每个 Kafka Broker 的 server.properties 文件中定义，并作为创建时没有显式复制设置的新 Topic 的默认值。

  • default.replication.factor：设置新 Topic 的默认复制因子。对于生产环境，3 是常见的值，允许 n-1 (3-1=2) 个 Broker 故障而不会导致数据丢失或停机。
    properties default.replication.factor=3

  • min.insync.replicas：这个关键设置定义了当 acks 设置为 all (或 -1) 时，生产者成功写入消息所需的最小 ISR 数量。如果 ISRs 的数量低于此值，生产者将收到错误（例如 NotEnoughReplicasException）。这确保了强大的持久性保证。
    properties min.insync.replicas=2
    > 提示：min.insync.replicas 通常应设置为 (replication.factor / 2) + 1 或 replication.factor - 1。对于 replication.factor=3，min.insync.replicas=2 是一个很好的平衡点，可以容忍一个 Broker 故障。

  • num.replica.fetchers：跟随者 Broker 用于从领导者获取消息的线程数。增加此值可以提高托管大量跟随者副本的 Broker 的复制吞吐量。
    properties num.replica.fetchers=1

Topic 级别配置

您可以在创建新 Topic 或修改现有 Topic 时覆盖 Broker 默认值并应用特定的复制设置。

使用特定复制设置创建 Topic

使用 kafka-topics.sh 命令行工具：

kafka-topics.sh --create --bootstrap-server localhost:9092 \n                --topic my_replicated_topic \n                --partitions 3 \n                --replication-factor 3 \n                --config min.insync.replicas=2

在此示例中，my_replicated_topic 将有 3 个分区，每个分区复制 3 次，并且要求至少有 2 个 ISRs 才能成功写入（使用 acks=all）。

修改现有 Topic 的复制设置

您可以修改一些 Topic 级别的复制设置。请注意，您可以使用此命令增加现有 Topic 的 replication-factor，但不能直接减少。减少需要手动重新分配分区。

增加 my_existing_topic 的复制因子（例如，从 2 增加到 3）：

kafka-topics.sh --alter --bootstrap-server localhost:9092 \n                --topic my_existing_topic \n                --replication-factor 3

为现有 Topic 设置 min.insync.replicas：

kafka-topics.sh --alter --bootstrap-server localhost:9092 \n                --topic my_existing_topic \n                --config min.insync.replicas=2

注意：增加复制因子会触发一个自动过程，Kafka 会将现有数据复制到新的副本中。特别是对于大型 Topic，这可能会占用大量 I/O 资源。

生产者保证和确认 (acks)

Kafka 生产者中的 acks（确认）设置决定了发送消息的持久性保证。它与 min.insync.replicas 协同工作。

  • acks=0：生产者将消息发送给 Broker 后，不等待任何确认。这提供了最低的持久性（可能丢失消息），但吞吐量最高。
  • acks=1：生产者等待领导者副本收到消息并确认。如果领导者在跟随者复制消息之前失败，可能会发生数据丢失。
  • acks=all (或 acks=-1)：生产者等待领导者收到消息，并且等待所有 ISRs 也收到并提交消息。这提供了最强的持久性保证。如果配置了 min.insync.replicas，生产者还将等待达到该数量的 ISRs 提交消息后才确认成功。这是关键数据的推荐设置。

示例生产者配置 (Java)：

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("acks", "all"); // 确保最高的持久性

Producer<String, String> producer = new KafkaProducer<>(props);
// ... send messages

通过复制确保容错能力

Kafka 复制旨在容忍 Broker 故障，而不会导致数据丢失或服务中断。集群可以承受的同时 Broker 故障数量直接取决于您的 replication.factor 和 min.insync.replicas 设置。

  • 一个 replication.factor=N 的集群，假设 min.insync.replicas 设置得当，最多可以容忍 N-1 个 Broker 故障而不会丢失数据。
  • 如果 replication.factor=3 且 min.insync.replicas=2，您可以丢失一个 Broker（无论是领导者还是跟随者），并仍保持全部功能和持久性。如果第二个 Broker 发生故障，ISRs 数量将降至 1（如果它是最后一个跟随者，则为 0），导致使用 acks=all 的生产者阻塞或失败，从而优先保护数据安全。

最佳实践：机架感知复制（Rack-Aware Replication）

为了获得更高的容错能力，特别是在云环境中，请考虑将 Kafka Broker 及其副本分布在不同的物理机架或可用区中。Kafka 支持机架感知复制，控制器会尝试将分区的领导者和跟随者副本分布在不同的机架上，以最大限度地减少单个物理故障域中丢失多个副本的可能性。

要启用此功能，请在每个 Broker 的 server.properties 中设置 broker.rack 属性：

# 在 broker 1 的 server.properties 中
broker.id=1
broker.rack=rack-a

# 在 broker 2 的 server.properties 中
broker.id=2
broker.rack=rack-b

# 在 broker 3 的 server.properties 中
broker.id=3
broker.rack=rack-a

然后，Kafka 将努力将副本放置在不同的机架上。

监控复制状态

定期监控 Kafka 集群的复制状态对于主动识别潜在问题至关重要，以防它们影响持久性或可用性。需要关注的关键指标包括：

  • UnderReplicatedPartitions（欠复制分区）：ISRs 数量少于其复制因子的分区数量。非零值表示存在潜在问题。
  • OfflinePartitionsCount（离线分区计数）：没有活动领导者的分区数量。这表示严重的故障和数据不可用。
  • LeaderAndIsr/PartitionCount：每个分区的领导者和 ISRs 的总数。

您可以使用 kafka-topics.sh 命令检查 Topic 的复制状态：

kafka-topics.sh --describe --bootstrap-server localhost:9092 --topic my_replicated_topic

输出示例：

Topic: my_replicated_topic  PartitionCount: 3   ReplicationFactor: 3    Configs: min.insync.replicas=2
    Topic: my_replicated_topic  Partition: 0    Leader: 0   Replicas: 0,1,2 Isr: 0,1,2
    Topic: my_replicated_topic  Partition: 1    Leader: 1   Replicas: 1,2,0 Isr: 1,2,0
    Topic: my_replicated_topic  Partition: 2    Leader: 2   Replicas: 2,0,1 Isr: 2,0,1

在此输出中：
* Leader：当前是该分区领导者的 Broker ID。
* Replicas：托管该分区副本的所有 Broker ID 列表。
* Isr：当前处于同步副本集（In-Sync Replica set）中的 Broker ID 列表。

如果任何 Broker ID 出现在 Replicas 中但未出现在 Isr 中，则表示该副本已脱离同步状态。

最佳实践和故障排除提示

  • 明智地选择 replication.factor：通常生产环境为 3，不太关键的数据为 2，开发环境为 1。更高的数字会增加持久性，但也会增加资源消耗。
  • 配置 min.insync.replicas：始终设置此项以确保满足持久性保证，尤其是在使用 acks=all 时。
  • 分散副本：使用 broker.rack 确保副本分散在不同的物理故障域中。
  • 主动监控：使用 Kafka 的 JMX 指标或 Prometheus/Grafana 等工具来监控 UnderReplicatedPartitions。
  • 避免不洁净的领导者选举：在生产环境中将 unclean.leader.election.enable 保持设置为 false，以实现强大的持久性保证。
  • 处理 Broker 重启：重启 Broker 时，应逐个进行，以允许跟随者重新同步并维持 min.insync.replicas。

结论

Kafka 复制是其数据持久性和高可用性的基石。通过仔细配置 replication.factor、min.insync.replicas，并理解生产者 acks 如何与这些设置相互作用，您可以设计出一个能够弹性应对故障，并为您的流数据提供强大保证的 Kafka 集群。

利用机架感知复制和强大的监控等特性，您可以确保您的关键数据管道保持运行，并且您的数据保持安全，即使在最严苛的生产环境中也是如此。配置良好的复制策略不仅仅是一个选项；它是任何可靠 Kafka 部署的必然要求。