Kafka 过去一直使用 Zookeeper 来管理元数据、领导者（Leaders）选举和集群协调。然而，在 KRaft（Kafka Raft）模式下，Kafka 摆脱了对 Zookeeper 的依赖，并使用 Raft 共识算法引入了自管理元数据仲裁机制。
KRaft 模式提供了更快的元数据传播速度、更强的一致性以及更可扩展的架构。下面，我们结合 KRaft 模式来重新审视 Kafka 的容错和持久化机制。

核心概念：分布式日志

✅ 没有重大变化

• Kafka 仍然使用分布式提交日志，通过分区（Partition）和顺序写入来优化性能。
• 记录的不变性保持不变。
• 生产者（Producers）和消费者（Consumers）继续以相同的方式运作。

🔹 KRaft 增强功能

• 元数据日志（取代 Zookeeper）现在遵循与 Kafka 数据分区（Partition）相同的基于日志的架构。
• 元数据操作现在利用 Raft 共识算法而不是 Zookeeper 的原子广播 (ZAB) 协议。

复制：容错的支柱

✅ 核心领导者（Leaders）-跟随者（Followers）模型保持不变

• 分区（Partition）仍然在代理之间复制。
• 领导者（Leaders）仍然处理读/写，而跟随者（Followers）复制数据。
• Kafka 仍然使用同步副本 (ISR) 来确定哪些副本是健康的。

🔹 KRaft 增强功能

• Zookeeper 已不复存在。关于领导者（Leaders）、跟随者（Followers）和 ISR 的元数据现在存储在 Kafka 内部。
• 更快的领导者（Leaders）选举： 不再由 Zookeeper 处理选举，而是由 KRaft 控制器（Raft 法定人数）接管，从而减少故障转移时间。
• 更具可扩展性的集群元数据处理： KRaft 改进了更大集群的元数据存储，可以更高效地处理数千个分区（Partition）。

🚨 主要区别

• 在基于 Zookeeper 的 Kafka 中，控制器节点（由 Zookeeper 选择）分配分区（Partition）领导者（Leaders）。
• 在 KRaft 中，没有外部控制器，Kafka 代理使用 Raft 共识自己选举元数据领导者（Leaders）。

通过磁盘持久性实现持久性

✅ 核心耐久性机制保持不变

• Kafka 仍然使用预写日志（WAL），按顺序附加消息。
• 日志段和刷新仍然以相同的方式工作。
• 保留策略（基于时间或基于大小）保持不变。

🔹 KRaft 增强功能

元数据持久性现在基于日志

• Kafka 的元数据不是以 Zookeeper 的快照格式存储元数据，而是以 Kafka 主题（Topic）（元数据日志）的形式保存。
• 这使得 Kafka 无需外部元数据存储即可从故障中恢复。

元数据检查点

• 元数据领导者（Leaders）会定期将检查点写入磁盘，以便更快地恢复。

🚨 主要区别

• 在 Zookeeper 模式中，元数据存储在 Zookeeper 节点中（znodes）。
• 在 KRaft 模式下，元数据以 Kafka 的日志格式存储，确保更好的一致性并减少 Zookeeper 开销。

平衡容错和性能

✅ 生产者（Producers）配置保持不变

• acks=all、idempotent生产者（Producers）和事务消息在 KRaft 中的工作方式相同。

🔹 KRaft 增强功能

• 降低元数据传播的延迟。
• 由于 Kafka 本身管理元数据，因此更改（例如：新分区（Partition）、领导者（Leaders）选举）传播得更快。
• 更快的故障恢复。
• 在传统模式下，代理需要向 Zookeeper 重新注册，从而导致延迟。
• 在 KRaft 中，代理重放元数据日志以更快地恢复状态。

🚨 主要区别

• 在 Zookeeper 模式下， 故障转移需要更长时间，因为代理必须重新向 Zookeeper 注册。
• 在 KRaft 模式下， 元数据日志重放可以实现更快的恢复。

消费者（Consumers）组管理和重新平衡

✅ 消费者（Consumers）的工作方式相同

• 消费者（Consumers）群体、重新平衡和偏移跟踪保持不变。
• 偏移提交（auto.commit，手动提交）仍然以相同的方式工作。

🔹 KRaft 增强功能

• 元数据传播速度更快。
• 这意味着当发生重新平衡时，重新分配分区（Partition）的时间更短。
• 更好的分区（Partition）分配处理。
• Kafka 不再依赖 Zookeeper 观察者；相反，元数据日志确保所有代理都拥有集群的最新视图。

🚨 主要区别

• 在 Zookeeper 模式下， 分区（Partition）分配涉及多个 Zookeeper 调用。
• 在 KRaft 模式下， 元数据更新通过 Raft 进行，使其速度更快、更具可扩展性。

KRaft 模式的现实影响

✅ KRaft 的主要优势

• 消除 Zookeeper 瓶颈。
• 不再依赖外部，降低了复杂性。
• 更高效地处理更大的 Kafka 集群。
• 扩展到 100K+ 个分区（Partition）更加容易。
• 更快的元数据恢复和领导者（Leaders）选举。
• 通过 Raft 共识，领导者（Leaders）选举可以在几毫秒内完成，而不是几秒。

🚨 潜在挑战

• 迁移复杂性： 现有的基于 Zookeeper 的集群必须谨慎迁移到 KRaft。
• 管理成熟度： 虽然 KRaft 很稳定，但使用大规模 Kafka 集群的公司，必须在全面进行测试。

结论：您应该改用 KRaft 吗？

KRaft 消除了对 Zookeeper 的依赖，提高了容错能力，并加快了元数据处理速度。如果您正在运行大规模 Kafka 部署，那么值得考虑使用 KRaft，因为它具有更好的可扩展性和可靠性。
但是，如果您使用的是基于 Zookeeper 的稳定配置，则迁移到 KRaft 需要仔细规划。在进行切换之前，应评估 KRaft 的成熟度和迁移策略。
您会转投 KRaft 吗？请在评论区留言告诉我您的想法！

参考文献

[1] Kafka Fault Tolerance and Durability: Zookeeper vs. KRaft Mode

赞赏