1

有人可以在以下场景中解释 Kafka 中的同步复制因子维护：

设想：

  1. 考虑一下，最初我们的复制因子为 3。
  2. 在 Kafka 中，如果领导者出现故障，其中一个同步副本将成为新的领导者。

因此，对于新的领导者（同步副本之一），Kafka 是否再次保持复制因子为 3。

4

1 回答 1

1

希望在 Kafka 符号上更加清晰：没有“同步复制因子”。每个主题都有一个“复制因子”和一个单独的“同步副本”列表（也称为ISR）。在一个健康的集群中，复制因子和同步副本的数量匹配，但是一旦一个代理崩溃，这些数字可能会偏离，因为您将拥有不同步的副本。

“所以，对于新的领导者（同步副本之一），Kafka 是否再次保持复制因子为 3。”

是（也不是）。Kafka 将坚持复制因子 3。但是，它希望崩溃的代理再次可用。在此期间，您的主题将有

  • 一个新的领导者（正如你在第二个要点中已经提到的）
  • 复制因子为 3
  • 只有两个同步副本

因此，尽管您的复制因子为3，但您的主题将有一个不同步的副本。

在代理重新启动之前，它现在取决于 KafkaProducer 配置acks以及min.insync.replicas生产者是否仍然可以成功地将数据写入主题。的描述min.insync.replicas提供了更多细节：

“当生产者将确认设置为“全部”（或“-1”）时，min.insync.replicas 指定必须确认写入才能被视为成功的最小副本数。

Kafka 关于平衡领导的文档提供了分区领导发生的一些背景：

每当代理停止或崩溃时，该代理分区的领导权就会转移到其他副本。当代理重新启动时，它只会成为其所有分区的追随者，这意味着它不会用于客户端读取和写入。

为了避免这种不平衡，Kafka 有一个首选副本的概念。如果一个分区的副本列表是 1,5,9，则节点 1 比节点 5 或 9 更优先作为领导者，因为它在副本列表中更早。默认情况下，Kafka 集群将尝试将领导权恢复到已恢复的副本。此行为配置为：

auto.leader.rebalance.enable=true

于 2020-11-19T08:23:19.257 回答