大家好，我是码哥，《Redis 高手心法》作者。
2025 年 3 月，Apache Kafka 迎来了具有划时代意义的 4.0 版本。这一版本不但是技术架构的全面革新，更是功能场景的深度拓展。
码哥第一时间对 4.0 版本分析，为大家深度解读 Kafka 4.0 的核心特性，以下是码哥以为比力紧张的特性：
- KRaft 全面替代 ZooKeeper
- 新一代消费者重平衡协议
- 点对点消息模型与共享组
- 移除旧协议 API 版本，提升系统性能
KRaft 全面替代 ZooKeeper
Apache Kafka 4.0 是一个紧张的里程碑，标记着第一个完全无需 Apache ZooKeeper® 运行的主要版本。
通过默认运行在 KRaft 模式下，Kafka 简化了部署和管理，消除了维护单独 ZooKeeper 集群的复杂性。
这一变革显著低沉了运营开销，增强了可扩展性，并简化了管理任务。
旧架构痛点回首
在 Kafka 3.x 及更早版本中，ZooKeeper（ZK）是元数据管理的核心组件，负责 Broker 注册、Topic 分区分配、控制器推选等关键任务，如图所示。
然而，这种计划存在显著问题：
- 运维复杂度高：需独立维护 ZK 集群，占用额外资源且增加故障点。
- 性能瓶颈明显：元数据操纵依靠 ZK 的原子广播协议（ZAB），大规模集群（如万级分区）下元数据同步延迟可达秒级。
- 扩展性受限：ZK 的写性能随节点数增加而降落，限制 Kafka 集群规模。
KRaft 模式的技术实现
Apache Kafka Raft（KRaft）是在 KIP-500 中引入的共识协议，用于移除 Apache Kafka 对 ZooKeeper 进行元数据管理的依靠。这通过将元数据管理的责任集中在 Kafka 本身，而不是在两个不同的系统（ZooKeeper 和 Kafka）之间分割，从而大大简化了 Kafka 的架构。
KRaft 模式利用 Kafka 中的新法定多数控制器服务，取代了之前的控制器，并利用基于事件的 Raft 共识协议的变体。
Kafka 4.0 默认启用KRaft 模式（Kafka Raft），完全摒弃 ZK 依靠。其核心原理如下：
- 元数据自管理：基于 Raft 共识算法，将元数据存储于内置的__cluster_metadata主题中，由 Controller 节点（通过推选产生）统一管理。
- 日志复制机制：所有 Broker 作为 Raft 协议的 Follower，实时复制 Controller 的元数据日志，确保强一致性。
- 快照与规复：定期生成元数据快照，避免日志无穷增长，故障规复时间从 ZK 时代的分钟级优化至秒级。
我们可以看出 KRaft 替换 ZK，并不是元数据存储重新造轮子，而核心是集群和谐机制的演进。
整个通信和谐机制本质上是事件驱动模型，也就是 Metadata as an Event Log，Leader 通过 KRaft 生产权势巨子的事件，Follower 和 Broker 通过监听 KRaft 来得到这些事件，而且次序处置惩罚事件，达到集群状态和期望的最终一致。
新一代消费者重平衡协议
传统消费者组接纳Eager Rebalance 协议，存在两大瓶颈：
- 全局同步屏障（Stop-the-World）：任何成员变动（如扩容、故障）都会触发全组暂停，导致分钟级延迟。
- 扩展性差：消费者数量受限于分区数，万级消费者组重平衡耗时高达数分钟。
Kafka 4.0 引入增量式重平衡协议（KIP-848），核心改进包括：
- 和谐逻辑转移：由 Broker 端的GroupCoordinator统一调度，消费者仅需上报状态，无需全局同步。
- 增量分配：仅调解受影响的分区，未变动的分区可继续消费。
- 容错优化：局部故障仅触发局部重平衡，避免全组停机。
性能对比与实测数据
指标旧协议（Eager）新协议（Incremental）重平衡延迟（万级组）60 秒<1 秒资源消耗（CPU）高低沉 70%扩展上限千级消费者十万级消费者 Kafka 4.0 引入了一种强大的新消费者组协议，旨在显著进步重新平衡性能。
这种优化显著减少了停机时间和延迟，增强了消费者组的可靠性和相应性，尤其是在大规模部署中。
点对点消息模型与共享组
传统上，Kafka 主要接纳发布-订阅模式，消费者组模式下，分区需与消费者一一绑定，如下图所示。
无法实现多消费者协同处置惩罚同一分区消息，消费者数量不能凌驾分区数量——最多为一对一。
如下图所示，Consumer 5 无法处置惩罚 Topic 消息。
而在某些特定场景下，如点对点的消息传递、任务分配等，传统的队列语义更具优势。
Kafka 4.0 通过引入“队列”功能，共享组（Share Group），答应多消费者同时处置惩罚同一分区消息，实现点对点消费模式。
特性传统消费者组共享组并行消费分区数=消费者数消费者数>分区数消息确认偏移量提交逐条 ACK/NACK投递语义At-Least-OnceExactly-Once（可选） 主要特点：
- 支持传统队列场景：适用于需要保证消息严酷次序且仅由一个消费者处置惩罚的场景。
- 提升资源利用率：共享组机制使得多个消费者可以或许动态地共享分区资源，进步了系统资源的利用率和整体吞吐量。
- 简化架构计划：开发者无需在 Kafka 与其他专门的队列系统之间进行复杂的集成和数据迁移。
共享组（Share Group）机制
Kafka 4.0 通过共享组实现队列语义，关键技术包括：
- 多消费者协同消费：同一分区的消息可由多个消费者并行处置惩罚，突破分区数限制。
- 记录级锁机制：每条消息被消费时加锁（TTL 控制），防止重复处置惩罚。
- ACK/NACK 语义：支持逐条确认（Exactly-Once）或重试（At-Least-Once）。
移除旧协议 API 版本，提升系统性能
Kafka 不停以来都致力于兼容各个版本的协议 API，但随着时间的推移，维护大量旧版本的协议 API 带来了许多不须要的复杂性和成本。
在 Kafka 4.0 中，旧版本的协议 API 被彻底移除，系统基准协议直接提升至 Kafka 2.1 版本。
改进点：
- 简化代码：去除了历史包袱，简化了代码布局，统一KafkaProducer与KafkaConsumer接口，减少冗余设置项，减少了测试难度。
- 进步性能：去除了对旧协议 API 的支持，使得系统性能得到了显著提升。废弃 Kafka 2.1 之前的所有 API（如MessageFormatter v0）
值得注意的是，在 Kafka 4.0 中，Kafka 客户端和 Kafka Streams 需要 Java 11，而 Kafka Brokers,Connect 和工具现在需要 Java 17。
其他改进
Kafka 4.0 的其他新变革：
- 动态设置优化：
- 自动线程调解：num.io.threads根据 CPU 核数动态分配，提升资源利用率。
- 时间窗口偏移量：支持从特定时间点（如 24 小时前）开始消费，替代固定偏移量。
- 安全性增强：OAuth 2.0 集成，支持基于 Token 的鉴权，替代 SASL/PLAIN；审计日志：记录所有元数据操纵，满足金融级合规要求。
总结
Kafka 4.0 通过彻底摆脱 ZooKeeper，全面接纳 KRaft 模式，不但简化了部署和维护工作，还显著提升了系统的性能和稳定性。
同时，新一代消费者重平衡协议和队列功能的引入，为开发者提供了更为机动和高效的消息处置惩罚模式。
这些架构革新使得 Kafka 4.0 成为了一个更加独立、高效和易用的分布式消息系统，为将来的发展奠基了坚实的基础。
最后，宣传下自己的新书《Redis 高手心法》，上市后得到了许多读者的较好口碑评价，而且上过京东榜单！原创不易，渴望大家多多支持，谢谢啦。
本书基于 Redis 7.0 版本，将复杂的概念与现实案例相联合，以简洁、幽默、幽默的方式揭示了Redis的精髓。
从 Redis 的第一人称视角出发，拟人故事化方式和幽默幽默的言语与各路“神仙”对话，配合 158 张图，由浅入深循规蹈矩的讲解 Redis 的数据布局实现原理、开发技巧、运维技术和高阶利用，让人轻松愉快地学习。
点击下方卡片即可购买
往期推荐
38 张图详解 Redis：核心架构、发布订阅机制、9大数据类型底层原理、RDB和AOF 长期化、高可用架构、性能问题排查和调优
高并发系统必看！G1如何让亿级JVM吞吐量提升300%？
性能提升300%！JVM分配优化三板斧，JVM 的内存区域划分、对象内存布局、百万 QPS 优化实践
从 12s 到 200ms，MySQL 两千万订单数据 6 种深度分页优化全分析
你真的懂 Redis 哨兵集群吗？一主二从三哨兵架构如何扛住百万级并发？
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
