| 失效链接处理 |
|
为什么越来越多人使用 Kafka 4.2 ？
相关截图：
 主要内容：
先把 Kafka 讲明白
Kafka 是一套分布式的提交日志。生产者把消息写进主题，消息落到分区里，按到达顺序往后追加。Broker 负责把这些日志存住、转发出去；控制器负责选主、记元数据。从 4.0 开始，元数据只走 KRaft，集群里不再单独养一套 ZooKeeper。
它被用得这么广，靠的是三大特性。吞吐高，日志可以按偏移量回放，消费进度记在消费端自己手里。日志采集、订单事件、指标、流计算，中间那一层经常就是它。
传统消费者组有一条很硬的规矩：同一个分区，同一时刻只交给组里的一个消费者。分区里的顺序因此很稳。订单处理、发短信、调用一个慢接口，这种“一条一条干活”的活，也会被这条规矩卡住。人加得再多，一个分区还是只有一双手。
4.2 这条线强在哪
4.2.0 在 2026 年 2 月 17 日发布，这一版把力气花在了能力上。共享组（Share Group）转正，Kafka Streams 的服务端再均衡也进入了核心能力的正式版。4.2.1 接着修了共享组路径上的死锁，以及 Streams 组离线迁移里的严重问题。4.2.2 是修复版，相对 4.2.1 大约收了 33 个问题，定位很明确：把 4.2 已经交给你的能力，修到能放心开着。
所以“4.2 到底有多强”，要连着看。新本事在 4.2.0，能上生产的版本号停在 4.2.2。
顺手变好的地方也值得一句。命令行工具的参数终于对齐了，--bootstrap-server 这种写法在各工具之间通用。RecordHeader 的并发读安全了。Connect 可以用外部 JSON Schema，消息体里不必每条都塞一份结构。客户端还跟上了 Java 25。
同一个分区，可以一起搬
共享组是 4.2 最有存在感的变化，对应 KIP-932。消费者组按分区分配：这块分区归你，那块归我。共享组改成按记录协作。同一条分区里的消息，可以同时发给组里的多个消费者，每条消息带一把有时限的获取锁。锁的默认时长是 30 秒，期间别人拿不到这条。处理完要给个说法。
四种说法，记起来不费劲：
ACCEPT：处理好了。
RELEASE：这次没处理好，放回去，让别人或下次再试。
REJECT：这条数据本身有问题，别再投递了。
RENEW：还在处理，把锁续上。这是 4.2 新加的，专门给那些比锁时间还长的慢任务。
|
联系锋哥QQ：3320160706
苏公网安备 32061202001004号
