Kafka 架构从 ZooKeeper 切换到 KRaft 后的变更

1. 领导选举机制：

   • ZooKeeper：在 ZooKeeper 模式下，ZooKeeper 负责协调选举 Kafka 的 Leader Broker。Kafka 有一个 Broker 担任 Controller，监听 ZooKeeper 中 Broker 的存活状态。在分区 Broker 宕机后进行 Leader 选举，Kafka 控制器是什么？作用？ & Kafka 控制器是如何监听 Broker 变化的？ & Kafka 副本的分区 Leader 是如何选取的？(ZK)。至于 Kafka Controller 的选举参见 Kafka 控制器是怎么选举的？。
   • KRaft：在 KRaft 模式下，Kafka 使用 Raft 协议来进行领导选举。Raft 协议在 Kafka Broker 内部实现，不再依赖外部的 ZooKeeper。每个 Broker 都参与 Raft 选举，以选出一个 Leader Broker 负责所有分区 Leader 的选举等事宜。至于 Kafka Leader Broker 的选举参见 Kafka Leader Broker 是怎么选举的？。

2. 元数据存储：

   • ZooKeeper：在 ZooKeeper 模式下，Kafka 的元数据（如 Topic、Partition、Leader 信息等）存储在 ZooKeeper 中。Kafka 控制器会也会进行元数据的缓存，并且定时广播给其他 Broker。
   • KRaft：在 KRaft 模式下，元数据直接存储在 Kafka 的本地日志中。每个 Broker 都维护着一部分元数据，并通过 Raft 协议来保证元数据的一致性。Kafka 副本中元数据一致性如何保证？(KRaft)

3. 高可用性：

   • ZooKeeper：ZooKeeper 提供了高可用性，即使单个 ZooKeeper 节点失效，集群仍然可以继续工作。
   • KRaft：KRaft 通过 Raft 协议提供了更强的高可用性保障。即使多个 Broker 失效，只要大多数 Broker 可用，Raft 协议就能保证集群的可用性。

4. 运维复杂性：

   • ZooKeeper：运维 Kafka 需要同时维护 ZooKeeper 集群，这增加了系统的复杂性。
   • KRaft：KRaft 模式下，运维人员只需要关注 Kafka 集群本身，简化了运维工作。

5. 配置差异：

   • ZooKeeper：需要配置 ZooKeeper 的地址以及其他与 ZooKeeper 相关的参数。
   • KRaft：需要配置与 Raft 协议相关的参数，如 Raft 副本的数量、选举超时时间等。

6. 性能影响：

   • ZooKeeper：ZooKeeper 可能成为性能瓶颈，尤其是在大规模集群中。
   • KRaft：KRaft 模式下，元数据操作直接在 Kafka 内部进行，理论上可以减少对 ZooKeeper 的依赖，提高性能。

7. 安全性：

   • ZooKeeper：需要确保 ZooKeeper 的安全，因为 ZooKeeper 控制着 Kafka 的元数据。
   • KRaft：KRaft 模式下，安全性主要集中在 Kafka 集群本身的访问控制和加密通信上。

8. 监控和日志：

   • ZooKeeper：需要监控 ZooKeeper 的状态和日志，以确保其正常运行。
   • KRaft：需要监控 Kafka Broker 的 Raft 状态和日志，以确保元数据的一致性和集群的健康状态。

9. 兼容性：

   • ZooKeeper：现有的 Kafka 应用和工具通常已经适配了 ZooKeeper 模式。
   • KRaft：迁移至 KRaft 模式可能需要调整现有的工具和监控系统，以适应新的架构。