Kafka 实战 - Kafka-Kraft模式

Apache Kafka 从版本 2.8 开始引入了基于 Raft 协议的全新元数据管理模式——Kafka-Kraft（简称 KRaft）模式。KRaft 模式旨在替代传统的依赖 ZooKeeper 的元数据管理模式，提供更为简洁、高效且高可用的 Kafka 集群管理方案。以下是在 Kafka 实战中使用 KRaft 模式的相关要点：

1. KRaft 模式架构

• Controller 选举：Kafka Broker 中的某个节点通过 Raft 协议选举为 Controller，负责集群的元数据管理和变更协调。Controller 是动态的，当当前 Controller 故障时，集群会自动选举新的 Controller。

• 元数据存储：Kafka Broker 节点本地存储完整的集群元数据（包括 Topic、分区、副本、消费组等信息），不再依赖外部 ZooKeeper 存储。元数据变更通过 Raft 协议达成共识并持久化到本地。

• Broker 自组织：Kafka Broker 节点通过 Raft 协议自我管理和协调，包括 Broker 注册、Topic 创建、分区副本分配、副本状态同步等操作。

2. 部署与配置

• 启动参数：在 Broker 启动参数中指定 --override mode=raft，启用 KRaft 模式。还需设置 controller.quorum.voters 参数，列出参与 Controller 选举的 Broker 节点列表及其投票权重。

• 数据存储：为 KRaft 模式下的 Kafka 集群配置专用的数据存储目录，用于存放元数据和 Raft 日志。

• 网络通信：确保 Broker 间的网络通信畅通，因为 KRaft 模式下的 Broker 需要频繁进行 Raft 协议的交互。

3. 优势与挑战

优势：

• 简化架构：无需额外部署和维护 ZooKeeper 集群，降低运维复杂性。
• 性能提升：由于元数据存储在本地且通信路径缩短，元数据操作的性能有所提升。
• 容错增强：通过 Raft 协议保证元数据变更的强一致性，即使在部分 Broker 故障的情况下也能保证服务可用性。

挑战：

• 初始部署：首次从 ZooKeeper 模式迁移到 KRaft 模式可能需要进行数据迁移和配置调整。
• 故障恢复：在 KRaft 模式下，Controller 故障可能导致短暂的服务中断，需要关注 Controller 的选举和恢复速度。
• 监控与运维：需要熟悉 KRaft 特有的监控指标和运维工具，以适应新的管理模式。

4. 迁移与运维

• 迁移策略：Kafka 提供了从 ZooKeeper 模式平滑迁移到 KRaft 模式的工具和步骤，迁移过程中应确保数据完整性和服务连续性。

• 监控调整：针对 KRaft 模式特有的监控指标（如 Controller 状态、Raft 日志同步状态等）进行监控系统的调整与配置。

• 故障处理：熟悉 KRaft 模式下的故障排查和恢复流程，如 Controller 选举问题、元数据不一致等。

5. 最佳实践

• Broker 数量：KRaft 模式下，通常建议至少部署 3 个 Broker 节点以保证 Controller 选举的稳定性和数据安全性。

• 网络隔离：为 KRaft 模式下的 Broker 网络通信设置专用的内网环境，减少网络延迟和干扰。

• 备份与恢复：定期备份 KRaft 模式下 Broker 节点的元数据存储，以便在灾难恢复时快速重建集群。

总之，Kafka-Kraft 模式为 Kafka 集群提供了一种更为简洁、高效的元数据管理方案，简化了架构、提升了性能，并增强了容错性。在实战中，应充分考虑其部署、配置、迁移、监控与运维的特点，结合业务需求制定合适的策略，确保 Kafka 集群在 KRaft 模式下的稳定、高效运行。随着 Kafka 版本的演进，KRaft 模式逐渐成熟并得到官方推荐，成为现代 Kafka 集群部署的首选模式之一。