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

背景

我们有一个 Kafka 消费者组，消费的是 order-event topic，该 topic 有 24 个分区，消费组 8 个实例。最近在流量高峰期间，出现了多次 Rebalance 风暴，导致消息处理延迟甚至丢失。

现象

1. Rebalance 频繁：每 5–10 分钟就发生一次 Rebalance，且每次 Rebalance 会重新分配分区，导致消息处理延迟。
2. 消息丢失：由于 Rebalance 导致消费者未能及时处理消息，部分消息被跳过。
3. CPU 资源波动：每次 Rebalance 后，消费者实例的 CPU 使用率出现明显波动。

已尝试的排查与结果

• 检查消费者配置：发现 max.poll.interval.ms 设置为 30000，session.timeout.ms 为 10000，但 Rebalance 仍然频繁。
• 调整 max.poll.records：尝试增加 max.poll.records 以减少 poll 频率，但未显著改善。
• 启用 Cooperative 协议：启用了 Kafka 2.4+ 的 Cooperative 协议，但 Rebalance 仍不稳定。
• 监控工具：使用 Prometheus + Grafana 监控消费者组状态，发现 consumer.lag 在 Rebalance 期间出现明显波动。

期望得到的答案形态

1. 检测手段：如何通过 Kafka 的 metrics 或第三方工具检测 Rebalance 风暴的发生？
2. 告警机制：如何设置合理的告警规则，例如基于 consumer.lag、rebalance.count 等指标。
3. 自愈方案：是否有无需修改业务代码的自愈方案，例如自动重启消费者实例、动态调整消费者数量等。
4. 最佳实践：是否有其他团队在生产环境中成功解决类似问题的案例或最佳实践？