Kafka 消费者组 Rebalance 风暴：如何在不改业务代码的前提下实现『检测 → 告警 → 自愈』闭环？

【背景】 Kafka 消费者组 Rebalance 是一个常见但棘手的问题。它可能导致消费者大量离线、消息积压、服务异常，甚至影响整个系统的稳定性。

【常见分歧】

1. 检测：有人主张实时监控 Kafka 消费者组状态，如消费进度、分区分配、消费延迟等；有人则认为依赖系统日志或监控指标。
2. 告警：有人倾向于在 Rebalance 超过阈值时触发告警，有人则认为应结合业务负载和消费速率，避免误报。
3. 自愈：有人主张通过自动化脚本或工具快速重平衡消费者组，有人则认为应手动介入，避免风险。

【我的倾向与理由】 我倾向于一个轻量级、低侵入式的方案：

• 检测：使用 Kafka 自带的 ConsumerGroupCommand 工具，定期检查消费者组的状态，如分区分配、消费进度等。
• 告警：基于消费延迟和分区分配不均设置阈值，当超过阈值时，通过 Prometheus 或 Grafana 触发告警。
• 自愈：通过脚本自动触发 ConsumerGroupCommand 的 rebalance 功能，或在告警触发后，通过 API 通知运维人员介入。

【想听大家在什么场景下怎么选】

• 你们在实际生产中是如何检测、告警和自愈 Kafka 消费者组 Rebalance 的？
• 有没有在不改业务代码的前提下实现闭环的成功案例？
• 对于不同的业务场景（如高并发、低延迟、数据一致性），你们的策略有什么不同？