Kafka 源码解析 - Kafka High Availability

Apache Kafka 的高可用性设计主要体现在以下几个方面：

1. 分区与副本（Partition and Replication）：

   • Kafka 的 Topic 被划分为多个 Partition，每个 Partition 存储一部分消息。
   • 每个 Partition 都会有多个副本（Replicas），其中一个副本被选举为 Leader，其他的副本则是 Followers。
   • 当 Leader 副本所在的 Broker 宕机时，Kafka 会自动从 Followers 中选举出一个新的 Leader，这样就可以保证即使部分节点故障，服务仍然可用。

2. ISR（In-Sync Replicas Set）：

   • ISR 是一组与 Leader 副本保持同步的副本集合。只有 ISR 中的副本才有资格被选举为新的 Leader。
   • 通过控制 ISR 的大小，Kafka 可以平衡数据安全性和写入性能。Leader 副本会等待 ISR 中的所有副本都完成数据同步，以此来保证数据的一致性。

3. 副本同步策略：

   • Kafka 提供了异步复制（默认）和同步复制（可配置）两种策略。
   • 异步复制时，Producer 发送消息到 Leader 副本，只要 Leader 成功写入消息并响应，就算作消息发送成功，Leader 会异步地把消息复制给 Followers。
   • 同步复制要求所有ISR中的副本都完成写入才能认为消息发送成功，这种方式牺牲了一定的写入性能以换取更强的一致性。

4. Producer 设置：

   • Producer 可以通过 acks 参数控制消息确认级别，从而影响消息的持久性和高可用性。
   • 当 acks=all 时，Kafka 会等待所有ISR中的副本都确认接收到消息后才向Producer返回确认信号，这意味着消息在这类配置下具有最高的持久性。

5. Controller 角色：

   • 在 Kafka 集群中有一个特殊的 Broker 被称为 Controller，它负责管理整个集群的分区和副本状态。
   • 当 Broker 宕机或网络隔离导致 Leader 副本失效时，Controller 会发现这种变化并触发重新选举新的 Leader 副本。

6. Zookeeper（早期版本）/KRaft（新版本）：

   • 在 Kafka 早期版本中，Zookeeper 负责维护 Broker 和 Topic 的元数据信息，以及进行 Controller 的选举。
   • 在较新的 Kafka 版本中引入了 KRaft 协议，允许 Kafka 自行管理集群元数据和领导权转移，从而减少对外部协调服务的依赖，提高了系统的自主性和高可用性。

通过上述设计，Kafka 在高可用性方面表现出色，能有效应对分布式系统中常见的节点故障情况，确保消息在大多数情况下不会丢失，同时尽可能保持服务的连续性。