Kafka 消费者组频繁 Rebalance？我用一套可观测脚本把根因揪出来了

说实话，Kafka 消费者组 Rebalance 这事儿，之前只在文档里见过 “尽量避免频繁 Rebalance” 这种废话。真正在生产环境里遇到的时候，才发现这玩意儿排查起来有多蛋疼。

上周三凌晨 2 点，告警狂响，消费延迟直接飙到分钟级。我抓起手机一看 —— 消费者组状态显示 REBALANCING，持续了快 10 分钟没恢复。赶紧爬起来处理，这篇文章就是我排查过程的完整记录。

问题现场

告警：consumer_group.payment 消费延迟 > 5000ms
时间：2026-03-17 02:14:23
持续：约 8 分钟
影响：支付通知积压，用户收不到回调

登录 Kafka 集群一看，消费者组状态确实是 REBALANCING，但死活不结束。常规操作——重启消费者进程——试了，没用。Rebalance 照样跑。

这时候我冷静下来，开始排查根因。

排查过程

第一步：确认是哪种 Rebalance

Kafka Rebalance 其实是保护机制，触发原因分几种：

1. 组成员变化（新消费者加入 / 旧消费者离开）
2. 分区数量变化（Topic 分区扩缩容）
3. 消费者心跳超时
4. 消费者处理时间过长导致会话过期

我先查了一下最近有没有发布订阅配置的变更：

# 查看消费者组状态
kafka-consumer-groups.sh --bootstrap-server kafka:9092 \
  --group payment-consumer \
  --describe

# 查看最近的分区分区分配记录
kafka-topics.sh --bootstrap-server kafka:9092 \
  --topic payment-notify \
  --describe

没看到分区变化，成员也没动。那问题大概率出在心跳或处理超时上。

第二步：抓关键指标脚本

我自己写了一套观测脚本，专门用来快速定位 Rebalance 根因：

#!/bin/bash
# kafka-rebalance-diagnose.sh

GROUP=$1
BROKER=${2:-"kafka:9092"}

echo "=== Kafka Rebalance 诊断报告 ==="
echo "时间: $(date '+%Y-%m-%d %H:%M:%S')"
echo "消费者组: $GROUP"
echo ""

# 1. 消费者组当前状态
echo "【1】消费者组状态"
kafka-consumer-groups.sh --bootstrap-server $BROKER \
  --group $GROUP \
  --describe 2>/dev/null | grep -E "TOPIC|PARTITION|CURRENT-OFFSET|LAG|CONSUMER" || echo "无法获取状态"

echo ""

# 2. 消费者健康度检查
echo "【2】消费者健康度"
for pid in $(pgrep -f "kafka.consumer"); do
  echo "PID $pid:"
  # 线程堆栈
  jstack $pid 2>/dev/null | grep -E "java.lang.Thread|KafkaConsumer.poll" | head -5
done

echo ""

# 3. 最近 5 分钟的 Broker 日志（Rebalance 相关）
echo "【3】Broker Rebalance 日志"
kubectl logs -n kafka kafka-0 --tail=500 2>/dev/null | \
  grep -iE "rebalance|group|consumer" | \
  grep "$(date '+%Y-%m-%d %H:%M' -d '5 minutes ago')" || \
  echo "未找到近期 Rebalance 日志"

echo ""

# 4. 消费者端配置检查
echo "【4】关键配置"
echo "session.timeout.ms: $(grep session.timeout /opt/kafka/config/consumer.properties)"
echo "max.poll.interval.ms: $(grep max.poll.interval /opt/kafka/config/consumer.properties)"
echo "heartbeat.interval.ms: $(grep heartbeat.interval /opt/kafka/config/consumer.properties)"

运行这个脚本之后，我发现问题了：

【4】关键配置
session.timeout.ms: 10000
max.poll.interval.ms: 300000
heartbeat.interval.ms: 3000

配置看起来没问题。但脚本输出了另一个关键信息——处理时间超过 5 分钟的业务逻辑。

第三步：定位处理超时

我看了消费者日志，发现有一条消息的处理时间异常长：

[2026-03-17 02:11:45] 收到消息: payment.callback.1594827
[2026-03-17 02:16:32] 处理完成，耗时: 287秒

从 02:11 到 02:16，一条消息处理了近 5 分钟。这直接导致了 max.poll.interval.ms（300000ms = 5分钟）超时触发，Kafka 认为这个消费者已经"卡死"，触发 Rebalance。

而为什么这条消息处理这么慢？查了一下，是第三方支付渠道回调超时，我们的重试机制里有个同步等待逻辑，设置了 4 分钟的超时。

解决方案

临时方案：增加 max.poll.interval.ms

把处理间隔从 5 分钟改成 10 分钟：

# consumer.properties
max.poll.interval.ms=600000

重启消费者进程，Rebalance 立即恢复。

长期方案：异步化 + 熔断

真正的根因是同步等待第三方接口，这种做法在高并发场景下是灾难。

我的改进方案：

// 改前：同步阻塞
public void onMessage(ConsumeResult result) {
    PaymentResponse resp = paymentClient.callBack(result.getPayload()); // 4分钟超时
    // ...
}

// 改后：异步+MQ
public void onMessage(ConsumeResult result) {
    CompletableFuture.supplyAsync(() -> {
        return paymentClient.callBack(result.getPayload());
    }, executor).thenAccept(resp -> {
        // 处理结果
    }).exceptionally(ex -> {
        // 记录失败，进入重试队列
        retryQueue.offer(result);
        return null;
    });
}

另外加了一个熔断器，第三方服务连续失败 3 次后直接跳过后续请求，避免雪崩。

观测脚本分享

完整脚本已上传，包含告警阈值和自动诊断逻辑：

# 使用方法
chmod +x kafka-rebalance-diagnose.sh
./kafka-rebalance-diagnose.sh payment-consumer kafka:9092

脚本会自动检查：

• 消费者组状态是否稳定
• 是否有消息处理超时
• Broker 端 Rebalance 日志
• 配置参数是否合理

写在最后

这次故障前后折腾了将近 2 小时，其中大部分时间在"猜"问题在哪。事后我整理了这套脚本，下次遇到类似情况，5 分钟内就能定位根因。

说白了，Rebalance 多数时候不是 Kafka 的问题，而是消费者端的代码问题。要么是处理太慢，要么是心跳没跟上。

如果你也在被 Rebalance 困扰，先跑一下上面的脚本，看看是哪种情况。多数时候，答案就在日志里。