Kafka 4.0 正式发布：彻底告别 ZooKeeper，全面拥抱 KRaft 时代

Kafka 4.0.0: 一个时代的终结，新时代的开启

Apache Kafka 4.0.0 于 2025 年 3 月 18 日 正式发布，这不仅仅是一次常规的版本更新，它标志着 Kafka 架构的一次根本性变革，是社区多年努力的成果。

1. 彻底告别 ZooKeeper：全面拥抱 KRaft (Kafka Raft)

这是 Kafka 4.0 最核心、最具影响力的变化。

• 历史背景与痛点：

  • 自诞生以来，Kafka 严重依赖 Apache ZooKeeper 来管理集群的元数据（如 Brokers、Topics、Partitions 的信息）、进行 Controller 节点的选举以及处理配置信息。
  • 虽然 ZooKeeper 是一个成熟的分布式协调服务，但它给 Kafka 带来了额外的复杂性：
    • 运维负担： 需要独立部署、监控、维护和调优一个 ZooKeeper 集群。
    • 架构复杂性： 引入了额外的系统依赖和潜在的故障点。
    • 可伸缩性瓶颈： ZooKeeper 集群的伸缩性和性能有时会成为大型 Kafka 集群的瓶颈，特别是在元数据频繁变更（如大量分区创建/删除）的场景下。
    • 恢复时间： Controller 故障切换依赖于 ZooKeeper，有时恢复时间较长。

• KRaft 模式的崛起：

  • 为了解决这些痛点，Kafka 社区开发了 KRaft (基于 Raft 共识协议的 Kafka 元数据管理模式)，KIP (Kafka Improvement Proposal) 编号为 KIP-500。
  • KRaft 将元数据管理和 Controller 选举的逻辑内置于 Kafka Broker 自身。一部分 Broker 节点会担任 “Controller” 角色（类似于 Raft 协议中的 Leader 和 Follower），它们通过内部的 Raft 协议来管理和同步集群元数据。
  • 元数据现在存储在一个内部的 Kafka 主题 (__cluster_metadata) 中，利用 Kafka 自身高可用的日志存储机制。

• Kafka 4.0 的决定性一步：

  • 之前的 Kafka 3.x 版本是过渡期，允许用户选择使用 ZooKeeper 模式或 KRaft 模式，并提供了从 ZK 迁移到 KRaft 的工具。
  • Kafka 4.0 是第一个完全移除 ZooKeeper 支持的版本。它默认并且唯一支持 KRaft 模式运行。这意味着新部署的 4.0 集群必须使用 KRaft，并且从旧版本升级也必须先完成到 KRaft 的迁移。
  • Kafka 3.9.0 成为了最后一个支持 ZooKeeper 模式的主要版本线。

• KRaft 带来的好处：

  • 简化架构： 无需独立的 ZooKeeper 集群，降低了部署和管理的复杂性。
  • 提高可伸缩性： KRaft 可以支持更多的分区（理论上数百万级别），突破了 ZooKeeper 的元数据管理瓶颈。
  • 更快的 Controller 故障切换： 基于 Raft 的选举通常比依赖 ZooKeeper 更快，缩短了集群在 Controller 故障期间的不可用时间。
  • 统一运维： 只需关注 Kafka 集群本身。
  • 云原生友好： 更容易在容器化和云环境中部署和管理。

2. KIP-932: Queues for Kafka - 引入共享组 (Early Access)

Kafka 传统上以其发布/订阅（Pub/Sub）模型和强大的流处理能力著称。然而，在某些场景下，用户需要更接近传统消息队列（如 RabbitMQ, ActiveMQ）的点对点（Point-to-Point）消费语义。KIP-932 就是为了更好地满足这类需求。

• 传统消费者组的限制：

  • 在一个消费者组 (Consumer Group) 内，一个主题分区 (Topic Partition) 在同一时刻只能被该组中的一个消费者实例消费。
  • 这意味着，如果想提高单个分区的处理速度，增加消费者数量是无效的（除非增加分区数）。如果消费者实例的数量超过了分区的数量，多余的消费者会处于空闲状态。

• KIP-932 的核心：共享组 (Share Group)

  • KIP-932 引入了一个新的概念——共享组 (Share Group)。它允许同一个共享组内的多个消费者实例并发地从同一个分区拉取和处理消息。
  • 当消息被一个共享组内的消费者成功处理并确认后，该消息就不会再被同一个共享组内的其他消费者获取。这实现了消息在组内成员间的负载均衡和独占处理，非常类似于传统消息队列的工作方式。
  • 你可以将共享组看作是在现有消费者组概念之上（或者说旁边）的一种新的消费协作方式。一个主题可以同时被传统的消费者组和新的共享组消费。

• 解决的问题与用例：

  • 突破分区限制的消费者扩展： 即使只有一个分区，也可以启动多个消费者实例加入同一个共享组来并行处理消息，提高吞吐量。
  • 简化从传统 MQ 迁移： 对于习惯了队列模型的应用，可以更容易地将 Kafka 用作消息队列，而无需过度关注分区和消费者的精确映射。
  • 处理“毒丸消息” (Poison Pill)： 虽然 KIP-932 本身不直接解决毒丸消息，但共享消费模型可能为实现更复杂的错误处理（如将有害消息移至死信队列而不阻塞整个分区）提供基础。

• 当前状态：早期访问 (Early Access - EA)

  • 在 Kafka 4.0.0 中，KIP-932 是早期访问功能。这意味着：
    • API 和内部实现可能在未来版本中发生变化，不保证向后兼容。
    • 可能存在一些已知或未知的限制和问题。
    • 官方不建议在生产环境中大规模使用，除非你完全理解其风险并做好了应对变化的准备。
    • 社区鼓励用户试用并提供反馈，以帮助其成熟。

• 实现方式： 它不是在 Kafka 中增加了一个全新的存储结构，而是通过 Broker 和 Client 的协作，在消费逻辑层面实现了消息在共享组成员间的分发和确认。

3. 其他重要更新概览

• KIP-848 (新一代消费者重平衡协议) 达到通用可用 (GA)： 这个 KIP 旨在显著改进消费者组的重平衡过程，使其更快、更增量化，大大减少了因消费者加入或离开导致的 “Stop-the-World” 式停顿时间，提高了消费应用的可用性。在 4.0 中达到 GA 意味着它已经过充分测试，稳定可用。
• 提升 Java 版本要求：
  • Kafka Broker、Controller、Connect、Tools 等服务端组件现在需要 Java 17 运行。
  • Kafka Clients 和 Kafka Streams 库现在需要 Java 11 或更高版本。
• 移除废弃的功能和 API： 清理了许多长期标记为废弃的 API、配置参数、指标和脚本，包括 MirrorMaker 1（推荐使用 MirrorMaker 2）。
• KRaft 模式增强： 持续对 KRaft 模式进行稳定性和功能性改进。
• 可观测性改进： 引入了新的 KIP (如 KIP-1076, KIP-1091) 来增强监控和诊断能力。

4. 升级注意事项

• 无法直接从 ZooKeeper 模式升级： 如果你正在运行基于 ZooKeeper 的 Kafka 集群（任何 3.x 或更早版本），不能直接升级到 4.0。
• 必须先迁移到 KRaft： 你需要先升级到一个支持 ZK-KRaft 迁移的“桥接版本”（例如 3.5, 3.6, 3.7, 3.9），按照官方文档完成到 KRaft 模式的迁移，然后才能升级到 Kafka 4.0。

总结

Kafka 4.0 是一次具有里程碑意义的发布。它通过全面拥抱 KRaft，彻底摆脱了对 ZooKeeper 的依赖，极大地简化了架构、提升了可伸缩性和运维效率。

同时，通过引入 KIP-932 的早期访问版本，Kafka 开始探索支持更传统的队列语义，拓宽了其应用场景。

伴随着 KIP-848 的 GA 和其他多项改进，Kafka 4.0 为用户提供了一个更现代化、更强大、更易于管理的分布式流处理平台。然而，用户在升级和采用新功能（尤其是 EA 功能）时需要仔细规划和评估。