复制

复制是 Kafka 的核心特性之一。它是一种机制，使 Kafka 能够在不可避免的单个节点故障情况下依然保证服务的可用性和数据的持久性。Kafka 中有主题（topics），每个主题由多个分区（partitions）组成，而这些分区的副本则分布在不同的代理（broker）上。通常情况下，每个代理在同一时间会托管数百甚至数千个分区。

在设计分布式系统时，创建数据存储或数据结构的副本可以提高系统的可用性。然而，这也带来了保持副本之间同步的挑战。此外，在读取请求量非常高的场景中，引入副本也是必要的，因为单一副本无法及时响应所有读取请求。

副本类型

在 Kafka 中，存在两种类型的副本：

• 领导者副本：所有来自消费者和生产者的请求都通过分区的领导者副本进行处理。每个分区只有一个代理被指定为领导者副本。

• 跟随者副本：除领导者以外的所有副本都称为跟随者副本。它们不参与处理消费者或生产者的请求，其唯一任务是从领导者副本复制消息，并保持与领导者最新消息的一致。当领导者副本发生故障时，其中一个跟随者副本将被提升为新的领导者。

跟随者副本会向领导者副本发送获取请求，以获取最新的消息，这一过程类似于其他客户端与领导者之间的交互。领导者副本通过分析跟随者副本发送的获取请求中的偏移量来判断该跟随者落后了多少。这个偏移量表示跟随者希望消费的下一条消息。如果某个副本在最近 10 秒内没有发起请求，或者虽然在最近 10 秒内发起了请求但未能赶上最新的消息，则该跟随者副本被视为 不同步 副本。这意味着当当前领导者发生故障时，该副本不会参与新领导者的选举。这是合理的，因为不同步的副本缺少最新的消息，不应被选为新领导者。一个跟随者副本在被认为不同步之前可以处于非活跃状态或落后的时间长度，由 replica.lag.time.max.ms 配置参数控制。调整此参数会影响客户端行为以及在领导者选举期间的数据保留策略。相反，那些持续从领导者副本获取最新消息的跟随者副本被认为是 同步 副本。只有这些副本才有资格参与领导者选举。

此外，还存在“首选领导者”的概念。这是在创建主题时选定的、应作为领导者副本的代理。设置首选领导者的原因在于，创建主题时，算法会尝试将分区的领导者均匀分配到可用的代理之间。如果集群中所有分区的领导者副本恰好都是首选领导者，那么负载将在各代理之间实现均衡分布。如果启用了配置项 auto.leader.rebalance.enable，Kafka 将触发一次选举，使首选领导者成为实际的领导者副本（如果尚未如此）。但前提是，首选领导者必须是一个同步副本。