Apache Kafka 4.0正式发布，首个默认KRaft模式运行，移除单独维护Zookeeper降低复杂性
大家好，这里是小奏,觉得文章不错可以关注公众号小奏技术背景
在2025年3月18日公布发布Apache Kafka 4.0.0版本
Apache Kafka 4.0.0 是 Kafka的一个紧张里程碑，标志取其架构的庞大转变。
标志取第一个完全不使用Apache ZooKeeper的主要版本
默认运行在KRaft模式下，简化了Kafka的部署和管理。
消除了维护单独ZooKeeper集成的复杂性。这一更改显著降低了运营开销，增强了可扩展性，并简化了管理使命
核心改动
改动包罗Kafka Broker, Controller, Producer, Consumer和Admin Client
KIP-848 消费者组性能优化
自Apache Kafka 4.0.0起，下一代消费者再平衡协议（KIP-848）正式发布（Generally Available, GA）。
该协议通过完全增量化的设计，不再依赖全局同步屏障，从而显著缩短了再平衡时间，同时提拔了消费者组的可扩展性并简化了消费者的实现逻辑。
使用新协议的消费者组现称为消费者组（Consumer Groups），而使用旧协议的组称为经典组（Classic Groups）。
需留意，经典组仍可通过旧协议构成消费者组。
改进点旧协议（Classic）新协议（KIP-848）再平衡机制全局同步屏障（所有消费者暂停等待和谐器指令）增量式和谐（消费者异步提交状态）时间开销O(N)（N为消费者数量）O(1)（仅需局部和谐）资源占用高（需维护完整的构成员列表）低（仅维护必要元数据）容错能力弱（单个消费者故障触发全组再平衡）强（故障影响范围局部化）扩展性支持数百消费者支持数万消费者 server默认开启新协议
consumer必须通过设置group.protocol=consumer
详细阐明参数consumer_rebalance_protocol:https://kafka.apache.org/40/documentation.html#consumer_rebalance_protocol
KIP-890 事务服务端防御机制
改进降低了生产者（Producer）发生故障时出现“僵尸事务”（Zombie Transactions）的概率
[*] 僵尸事务：当生产者因崩溃或网络故障无法提交或回滚事务时，事务和谐器（Transaction Coordinator）可能残留未完成的事务状态，占用资源并可能引发数据差别等1。
[*] 旧客户端兼容性：旧版客户端在处理事务验证阶段返回的NETWORK_EXCEPTION 错误时，可能误判为致命错误，导致事务管理器进入不可规复状态1。
[*] 第二阶段的核心改进
[*] 服务端事务验证增强
[*] 在生产者发送 Produce 和 TxnOffsetCommit 请求时，服务端主动与事务和谐器验证事务状态，确保事务处于活跃或可提交状态，避免处理已失效的事务请求1。
[*] 新增错误转换逻辑，将网络异常（如 NETWORK_EXCEPTION）映射为客户端可重试的错误类型，提拔旧客户端兼容性1。
[*]增量式错误处理
[*] 网络超时与毗连中断：若验证请求超时或毗连中断，服务端返回可重试错误，而非直接终止事务。
[*] 并发控制优化：当多个验证请求并发时（如相同事务的 AddPartitionsToTxn 请求），通过错误码引导客户端重试，避免竞争条件1。
[*]僵尸事务检测与清算
[*] 服务端通过心跳超机遇制检测僵尸事务，主动将其标志为终止状态，释放相关资源。
[*] 生产者规复后，通过事务 ID 和纪元（Epoch）验证合法性，防止旧事务干扰新事务
详细阐明参考transaction_protocol:https://kafka.apache.org/40/documentation.html#transaction_protocol
KIP-932 Kafka 队列功能（早期预览版）
通过引入共享群组（Share Group） 的概念，支持基于 Kafka 主题的协作式消费模式。
KIP-932 并未直接在Kafka中新增“队列”这一数据结构，而是通过扩展现有主题的消费机制来满足队列场景的需求。
共享群组的功能类似于其他消息系统中的“持久化共享订阅”（Durable Shared Subscription）
KIP-966：合格领导者副本（预览版）
KIP-966 在 Kafka 4.0 中首次引入合格领导者副本（Eligible Leader Replicas, ELR） 的预览功能。ELR 是 ISR（In-Sync Replicas，同步副本）的子集，保证其数据完整性到达高水位线（High-Watermark）。ELR 可安全用于领导者推举，避免数据丢失
详细阐明可以参考eligible_leader_replicas
KIP-996：预投票机制
KRaft模式下，节点可能因瞬时网络问题（如 GC 暂停）误判领导者失联，触发不必要的推举，导致：
集群波动：频繁领导者切换影响吞吐量
元数据竞争：多个节点同时发起推举引发脑裂风险
[*] 预投票机制原理
[*] 预投票阶段：
节点感知领导者失联后，先向其他节点发送预投票请求（携带自身日志最新偏移量）
吸收节点查抄请求者日志是否充足新（避免落伍副本成为领导者）
[*]正式推举：
[*] 仅当获得多数预投票认可后，节点才发起正式推举
[*] 否则进入冷却期（election.backoff.ms）
KIP-1076：客户端应用指标（KIP-714 扩展）
KIP-714 允许集群管理员通过插件直接从Broker网络客户端指标，但仅覆盖 Kafka 原生客户端（生产者、消费者、Admin）。
KIP-1076 扩展此功能，支持嵌入式客户端（如 Kafka Streams）上报应用级指标，实现端到端性能监控。
KIP-1106：消费者客户端支持基于时长的偏移重置
新增auto.offset.reset.duration 配置，允许消费者在无初始偏移量或偏移量失效时，从指定时间点（如 24 小时前）开始消费，避免全量数据重处理。
KIP-1043：消费者组管理增强
针对KIP-848（新消费者组）和 KIP-932（共享组）引入的组类型，更新 kafka-groups.sh 工具以支持查看所有组类型，修复 Admin API 的兼容性问题。
KIP-1102：客户端主动重引导机制
客户端在元数据超时未更新或收到服务端错误码（如 FENCED_INSTANCE_ID）时，主动触发重引导，办理旧机制中元数据过期导致的壅闭问题。
KIP-896：移除旧版客户端协议API
首次移除了旧的协议 API 版本。
用户在将 Java 客户端（包括 Connect 和 Streams）升级到 4.0 版本之前，应确保broker版本为2.1或更高。
同样，用户在将broker升级到4.0版本之前，应确保其 Java 客户端版本为2.1或更高
KIP-1124：明确客户端升级路径
定义 Kafka 客户端、Streams 和 Connect 到 4.0 的升级步调，逼迫阅读以避免升级风险。
KIP-653：升级至 Log4j2
日志框架迁移到Log4j2，提供 log4j-transform-cli 主动转换旧配置，但部分特性受限（如自定义 Appender）。
KIP-724：弃用消息格式 v0/v1
自 Kafka 3.0 弃用的消息格式v0和v1
在 4.0 中彻底移除，仅支持v2+。
KIP-750 & KIP-1013：Java版本支持变更
[*] Kafka Clients 和 Kafka Streams需JDK11+
[*] broker、Connect和工具需JDK17+
KIP-1030：配置项默认值优化
调解多个配置的默认值（如num.io.threads 根据 CPU 核数动态设置），提拔开箱即用体验。
总结
总的来说改动还挺多，最核心的改动还是默认使用KRaft模式运行。
Kafka Streams和Kafka Connect也有一些改动，具体参考官网吧
参考
[*]https://archive.apache.org/dist/kafka/4.0.0/RELEASE_NOTES.html
[*]https://kafka.apache.org/blog
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]