2026-06-15 ~ 2026-06-21
本周无公告
Andrew Schofield 发起 KIP-1359 讨论，旨在提升重置消费者组偏移量命令行工具的易用性。讨论重点在于 RPC 设计选择、包名修正及 API 字段一致性，作者已根据反馈决定引入新 RPC 并修正代码细节。
@Chia-Ping Tsai: 询问 RPC 处理方式是复用现有还是引入新的，并建议在 KIP 页面补充讨论链接。
@黃竣陽: 指出包名应修正为 org.apache.kafka.clients.admin，并建议 DescribeGroupsOptions 增加 includeAuthorizedOperations 字段以保持一致性。
@Andrew Schofield: 决定采用新的 RPC 作为最干净的解决方案，已修正包名和字段问题，并提出了关于导出选项的替代方案供社区讨论。
作者已采纳社区建议并更新了 KIP（包括引入新 RPC 和修正代码细节），下一步将继续讨论以确定导出功能的最佳实现路径。
讨论主要围绕 KIP-1313 引入 RequestHeader v3 后，新客户端向旧 Broker 发送 ApiVersionsRequest 时可能引发的二进制兼容性问题展开。经过权衡，双方确认无法通过修补旧版本来解决该问题，因此决定 ApiVersionsRequest 需继续使用 v2 请求头并将 ClientInstanceId 移至请求体中。此外，讨论还确定了引入新的元数据版本（MV）以及升级 KRaft RPC 的方案。
@Jun Rao: 指出 ApiVersionsRequest v6 依赖 RequestHeader v3 会导致旧 Broker 解析失败从而断开连接，阻碍版本协商；要求在 KIP 中明确未来请求头变更的应对策略及 ClientId 的验证逻辑。
@Andrew Schofield: 确认了兼容性风险，提出将 ClientInstanceId 放入 ApiVersionsRequest 请求体但保留 v2 请求头的解决方案；反对修补旧 Broker 的方案，因为这会破坏次版本兼容性（如 4.5 客户端无法连接 3.x Broker）。
初步结论是 ApiVersionsRequest 将维持使用 v2 请求头以解决兼容性问题，同时引入新的元数据版本（MV）并升级 KRaft RPC。下一步行动是更新 KIP 文档，详细说明兼容性计划、定义 ClientInstanceId 为 0 时的 INVALID_REQUEST 错误处理，以及完善关于 ClientId 一致性的验证规则。
讨论主要探讨了 Zookeeper 到 KRaft 迁移自动化的可行性，特别是针对 Kubernetes 环境。社区成员确认自动化完全可行且已有零停机实践，但指出当前官方文档缺乏面向程序化的状态信号，需额外开发协调机制。讨论还分享了关于健康检查门槛、节点协调以及现有 Operator 解决方案的经验。
@Anton Agestam: 自动化迁移完全可行且可零停机运行，但现有文档主要面向人工操作（如查看日志），缺乏程序化判断迁移状态的信号，需额外开发健康检查门槛和节点协调机制。
@Paolo Patierno: Strimzi 集群操作员已完全自动化了该迁移逻辑，用户只需通过注解即可控制流程，但这依赖于 Strimzi 环境。
@Varun Ghai: 分享了 Instaclustr 关于迁移过程的文档和博客资源，涵盖了人工与自动化的对比及性能收益。
社区确认迁移自动化已在生产环境中实现（如 Aiven 和 Strimzi），并提供了相关文档资源，建议参考现有方案解决程序化信号缺失的问题。
讨论主要围绕 IQv2 在支持 Headers 的状态存储中的返回类型展开。Matthias 提议使用 `Record` 模型以与 PAPI 保持一致，Jess 进而建议引入 `ReadOnlyRecord` 接口以避免暴露写入方法。目前 KIP 文档已根据反馈更新了设计细节和措辞。
@Matthias J. Sax: 建议 IQv2 放弃 KV 模型转而使用 `Record` 模型，以实现 API 的标准化并避免内部类型（如 `ValueTimestampHeaders`）的复杂性。
@Jess Jin: 提出返回新的 `ReadOnlyRecord` 接口（由 `Record` 实现），以避免在只读查询结果中暴露用于处理的构建器方法。
@Alieh Saeedi: 指出 Motivation 部分关于“丢弃 headers”的措辞不准确，建议修改为“不暴露 headers”，并询问了 `AggregationWithHeaders` 的映射细节。
初步结论是采用 `ReadOnlyRecord` 作为查询结果类型，Jess 已更新 KIP Wiki 以包含该设计变更并修正了相关措辞。
讨论主要围绕 KIP-1279 集群镜像提案的审查反馈展开，Federico 已针对大部分细节问题进行了修复和文档补充。双方重点深入探讨了停止镜像时事务状态可能出现的不一致问题（AS30），确认了其对消费者的影响及潜在解决方案。
@Andrew Schofield: 关注事务性数据镜像的安全性，特别是停止镜像时写入 ABORT 标记可能引发的状态不一致，以及 Fetch 响应协议的健壮性。
@Federico Valeri: 分析发现 AS30 问题会导致 `__transaction_state` 与分区日志状态不一致，但这属于 KAFKA-20716 中记录的通用事务状态分歧问题。
@Federico Valeri: 指出虽然存在状态分歧，但 READ_COMMITTED 消费者因能正确读取 ABORT 标记而不受影响，实际影响有限。
双方确认了 AS30 问题的本质属于更广泛的事务状态分歧问题，只要确保 Fetch 响应能正确构建中止事务列表，消费者端即可保持正确行为。后续可能需要通过解决 KAFKA-20716 来彻底消除此类不一致。
本次讨论围绕 PR #856 展开，旨在将 42/generated 目录从 static/ 移动到 content/。审核者认可了代码变更，但要求补充更新 README 文档和相关脚本，贡献者随后完成了所有修改。最终，该 PR 已被成功合并。
@mimaison: 认可 PR 的更新内容，但指出需要同步更新 README 中的三个章节（Setup Static Assets、Supported Features、Helper Script）以及 replace-version-links.sh 脚本。
@muralibasani: 确认已按要求完成所有四处更新，包括删除旧的复制行、更新路径示例、添加新规则及更新脚本注释。
PR #856 已由 mimaison 合并，所有请求的文档和脚本修改均已落实。
讨论主要围绕 KIP-1357 中 Streams 组 broker 端自定义分配器的 API 设计细节展开，重点涉及接口稳定性、数据结构简化及配置方式。Matthias 和 Lucas 提出了标记 API 为 Evolving、移除 warmup tasks 以及统一配置项的建议，Gabriella 确认采纳并更新了 KIP 提案。
@Matthias J. Sax: 建议将所有新增公共 API 标记为 @Evolving 以允许后续迭代修改；应从 MemberAssignment 中移除 warmup tasks 以简化接口；倾向于使用接口而非 records，并支持单一配置项方案。
@Gabriella Fu: 确认自定义分配器加载机制与 consumer 端一致；已根据反馈更新 KIP：合并配置项、改用接口定义类型、移除 warmup tasks 并添加 @Evolving 注解。
@Lucas Brutschy: 建议配置方式应模仿 KIP-848，使用单一配置列表同时包含内置名称和类名，比双配置方案更简洁。
KIP 作者已根据讨论共识完成了提案更新，包括采用单一配置项、将数据类型从 records 改为 interfaces、移除 warmup tasks 以及标注 API 为 Evolving，目前等待社区进一步审查。
讨论主要针对 KIP-1327 关于防止分区扩展时热数据丢失的方案细节。社区成员肯定了核心策略方向，并针对现有消费者组的兼容性处理、RPC 变更文档格式提出了具体改进建议。作者已采纳反馈并更新了 KIP 文档。
@Chia-Ping Tsai: 支持 latest（现有分区）与 by_duration（新分区）结合的策略，认为能解决绝大多数投诉问题。
@Chia-Ping Tsai: 建议对于无法利用新配置的现有组，通过打印警告信息引导用户重建组，而非允许修改组创建时间。
@Chia-Ping Tsai: 要求以表格形式列出 RPC 变更，并补充描述策略适用的目标场景。
作者已根据审阅意见更新了 KIP，目前正等待社区进一步审阅。
Ivan Yurchenko 发起 KIP-1355 讨论，旨在为客户端和 Broker 增加机架内流量可观测性指标，作为 KIP-1123 的后续补充。Andrew Schofield 支持该想法，但建议将术语从“in-rack”改为“rack-aligned”，以避免指标名称中出现重复前缀。
@Ivan Yurchenko: 提议增加新指标以观测机架内流量，完善 KIP-1123 的功能。
@Andrew Schofield: 建议使用“rack-aligned”替代“in-rack”，以优化指标命名并避免如“InIn”等冗余名称。
目前尚无最终结论，社区正在就指标命名的具体措辞进行讨论。
讨论主要围绕 KIP-1340 中 GlobalKTable 连接操作的 API 设计，重点在于如何命名新的函数接口以避免与现有接口混淆。参与者倾向于通过重载现有 `join` 方法而非引入新方法名来保持 API 的一致性。最终，Lucy Liu 更新了 KIP，采用了 `ValueJoinerWithMultipleKeys` 作为新接口名称，并废弃了原有提案。
@Alieh Saeedi: 倾向于重载方案以保持 API 一致性，但指出 `ValueJoinerWithKeys`（复数）与现有接口名仅差一个字符，容易造成混淆。
@Matthias J. Sax: 建议使用 `ValueJoinerWithMultipleKeys` 作为新接口名称，以解决命名冲突问题。
@Lucy Liu: 已根据讨论更新 KIP，采用重载方案和新命名，废弃了旧的重载并拒绝了 `joinByMappedKey` 方案。
已达成初步共识并更新 KIP，采用 `ValueJoinerWithMultipleKeys` 接口重载现有方法，等待社区进一步反馈。
本周新建 44 个 Issue
本周 JIRA 主要集中在 Kafka Streams 的事务支持增强与状态管理修复，以及分层存储和 Share Group 的稳定性改进。同时，社区还推进了 KRaft API 重构、Connect 新功能开发以及后量子密码学等安全与可观测性相关的更新。