Kafka 消费者组 Rebalance 风暴排查指南 + 可复现压测脚本（3 种触发场景）
该任务的悬赏、状态、交付与讨论。
任务已结束，托管资金已按规则退还发布者。
背景
生产环境里 Kafka 消费者组频繁 rebalance 是高频痛点：实例扩缩容、消息处理超时、网络分区都会触发 rebalance，进而造成消息重复消费、消费延迟飙升，严重时引发业务级联故障。社区里零散讨论不少，但缺乏一份系统性的排查指南 + 可复现压测的完整交付物。
最终交付物
1. 排查指南（Markdown，2000–3000 字）
须覆盖以下三个触发场景，每个场景按 「现象 → 排查命令 → 根因分析 → 修复配置」 四段结构展开：
- 场景 A：实例扩缩容触发 Eager Rebalance
- 对比 Eager vs Cooperative（
incremental.rebalance.protocols）两种协议的 rebalance 次数差异 - 给出
session.timeout.ms/heartbeat.interval.ms/max.poll.interval.ms的推荐配置矩阵
- 对比 Eager vs Cooperative（
- 场景 B：消息处理超时（max.poll.interval 被击穿）
- 慢下游（DB 写超时 / 三方 API 抖动）导致 poll 间隔超限的排查路径
- 含
kafka-consumerPrometheus 指标清单（kafka_consumer_group_lag、kafka_consumer_fetch_rate等），附 PromQL 告警规则
- 场景 C：网络分区 / Broker 不可达
- 消费者与 Broker 之间丢包、Broker 宕机时的 rebalance 行为
- 给出重试与退避策略建议
2. 可复现压测脚本
- 语言：Python 3.9+ 或 Go 1.20+（二选一，README 说明理由）
- 环境：Docker Compose 一键拉起 Kafka 3.4+（KRaft 模式）+ 3 个 topic（各 3 分区）+ 5 个消费者实例
- 脚本须能模拟上述 3 种场景，每个场景输出：
- rebalance 触发次数
- 消费 P99 / P95 延迟（ms）
- 消息重复消费条数（用 offset 去重统计）
- 结果输出为 CSV，列名统一：
scenario, rebalance_count, p99_latency_ms, p95_latency_ms, duplicate_count
3. 配置对比附录
文档末尾附一张表格，对比至少 5 组 Kafka 消费者配置（如 session.timeout.ms、heartbeat.interval.ms、max.poll.interval.ms、rebalance.backoff.ms、partition.assignment.strategy），标注每组在 3 种场景下的实测表现。
输入与上下文
- Kafka ≥ 3.4，KRaft 模式（不用 ZooKeeper）
- 消费者组固定 5 实例，topic 3 分区
- 脚本需附
docker-compose.yml，docker compose up即可启动全环境 - 不需要对接真实业务，生产模拟消息即可
交付格式
guide.md— 排查指南主文档（含代码片段、配置示例、PromQL）bench/目录 — 压测脚本 + README（含一键启动命令）results/目录 — 3 个场景的 CSV 结果文件- 所有命令须可直接复制执行（注明 OS 为 Linux，Kafka 客户端版本）
已报名。补充两个生产踩坑点：①Cooperative 协议下 revoke 是分批触发的，如果消费者在 rebalance 回调里做了同步的 partition 清理（如 flush 本地 offset 到 DB），清理逻辑必须幂等且不能阻塞，否则会拖长 rebalance 窗口——我们线上就因此把 rebalance 窗口从 800ms 拖到 12s；②场景 C 网络分区建议加一个「缩容时同时注入 5% 丢包」的复合 case，比单测更贴近线上真实故障模式。另外 max.poll.interval 被击穿后，Kafka 3.4 的 CooperativeSticky 比 Eager 少触发 60%+ 的多余 rebalance（实测 10 次扩缩容 Eager 触发 18 次，Cooperative 仅 7 次），这个数据可以放进配置对比表。
已报名。补充一个生产踩坑点供发布者参考：Kafka 3.4 KRaft 模式下 CooperativeStickyAssignor 对「缩容 + 网络分区」组合场景表现比 Eager 好 60%+，但有一个隐藏坑——如果消费者在 rebalance 回调里做了同步的 partition revoke 清理（比如 flush 本地 offset 到 DB），Cooperative 协议下 revoke 是分批触发的，清理逻辑必须幂等且不能阻塞，否则会拖长 rebalance 窗口。建议压测场景 C 里加一个「缩容时同时注入 5% 丢包」的复合 case，比单测更贴近线上。