Kafka 4.1 发布：Queues for Kafka 进入 preview，升级只对一类 4.0 集群有额外要求
Apache Kafka 4.1.0 已发布，随后的 4.1.1、4.1.2 为 bugfix 版本。这一版的主要看点集中在三处：Queues for Kafka（KIP-932）进入 preview、Kafka Streams 的 rebalance 协议改进（KIP-1071）、原生 JWT-bearer 认证（KIP-1139）。
- 发布公告：
- 4.1 概览：
一个前提：Kafka 4.0 起已移除 ZooKeeper，仅支持 KRaft 元数据模式，4.1 的升级路径也建立在这条线上。
Queues for Kafka（KIP-932）：Share Groups 把消费模型摊开
KIP-932 在 4.1 进入 preview，尚未生产就绪，但可以开始评估和测试。
它要突破的是传统消费模型的边界：一个分区在同一时刻只能被一个 consumer 独占，并且按顺序消费。Queues for Kafka 把这一点扩展成 share group 式的协作消费——同一 share group 内的多个 consumer 可以分摊同一条队列上的消息，而不是一个分区只能被一个 consumer 独占。对天然不需要严格分区顺序、更看重并行处理吞吐的队列型负载来说，这是消费模型层面上的变化，而不是参数调优。
朝生产就绪的方向，Kafka Queues（Share Groups）目前带出的能力包括：
- RENEW 确认类型，用于延长处理时间
- share coordinator 自适应批处理
- 按数量对已 fetch 的记录数做软限制 / 严格限制
- 更完整的 lag 指标
lag 指标这一项值得单独留意：协作消费下消息不再绑定到某个分区归属，监控侧原先按分区算 lag 的口径需要重新对一遍。因为是 preview，这部分适合在非生产环境验证语义、客户端行为和指标采集，不建议直接上生产。
Kafka Streams：rebalance 协议改进（KIP-1071）
KIP-1071 改的是 Kafka Streams 的 rebalance 协议本身，目标是更高效的 Streams rebalance。收益体现在 rebalance 过程里，不涉及 API 变更。实例数多、扩缩容频繁的 Streams 应用，感受会更直接。
原生 JWT-bearer 认证（KIP-1139）
KIP-1139 把 JWT-bearer 认证做成了原生支持：不再需要额外插件，就能用 OAuth/OIDC 签发的 JWT 做 SASL 认证。已经在用统一身份体系、又不想为 Kafka 单独维护一套认证插件的团队，少了一块部署和升级时要跟着动的依赖。
升级路径与例外
对核心 Kafka、Kafka Connect 和客户端库来说，4.1 是安全的渐进式升级，标准部署没有重大破坏性变更；从 4.0 以及较新的 3.x 升级相对平顺。ZooKeeper 那条路径在 4.0 已经移除，4.1 不需要再为它做规划。
唯一需要额外注意的是：4.0 集群如果启用了 Queues for Kafka 的 early access，升级不能照常规流程走。同一个功能在 4.1 里以 preview 形态重新落地，两边的行为不保证一致，升级前建议先在测试集群完整走一遍。