Consumer Rebalance (重平衡) 风暴与优化

【今日主题】：Consumer Rebalance (重平衡) 风暴与优化

【业务场景痛点】

场景：大型内容平台的实时推荐流消费系统。

• 架构：100+ 个 Consumer 实例组成一个 Consumer Group，订阅一个 500+ 分区的 Topic。
• QPS：平均消费速率稳定在 50万 QPS。
• 故障：在凌晨流量低谷期，运维对其中一个 Broker 进行例行重启。由于网络波动，导致 Consumer Group 的 Coordinator 感知到部分 Consumer 心跳超时。
• 灾难：触发全组 Rebalance。在 Rebalance 期间，所有 Consumer 停止消费，开始“分配分区”。整个过程持续了近 1 分钟。对于实时推荐系统，这意味着所有用户的推荐列表刷新失败，服务近乎不可用。更糟的是，Rebalance 完成后，大量 Consumer 因本地缓存失效导致 CPU 飙升，引发二次雪崩。

【架构与原理解析】

1. Rebalance 流程（画图式讲解）

Rebalance 本质上是将一个 Topic 的所有 Partition 重新分配给 Consumer Group 中的各个 Consumer 的过程。它由 Kafka 的 GroupCoordinator 协调完成。

• 阶段一：状态变更 (JoinGroup)

  • 触发器：一个 Consumer 加入组、离开组、或心跳超时。
  • 流程：所有 Consumer 向 GroupCoordinator 发送 JoinGroup 请求。Coordinator 会选出一个 Leader Consumer。
  • 关键点：只有 Leader 会收到所有成员列表，并负责分配方案。

• 阶段二：分区分配 (SyncGroup)

  • 流程：Leader Consumer 根据配置的分配策略（如 range, roundrobin, sticky）计算分区分配方案，通过 SyncGroup 请求发送给 Coordinator。其他 Follower Consumer 也发送 SyncGroup 请求，但携带空的分配方案。
  • 关键点：这是最耗时的阶段。如果 Leader 计算慢或网络差，整个组都在等待。

• 阶段三：消费恢复

  • 流程：所有 Consumer 收到自己的分区分配，开始从指定的 Offset 拉取消息。

2. 为什么默认配置在生产环境是“灾难”的？

• 默认配置：session.timeout.ms=10s, heartbeat.interval.ms=3s, max.poll.interval.ms=5min。
• 风险：默认的 session.timeout.ms 较短。如果 Consumer 处理一批消息耗时超过 10 秒（例如 Full GC 或逻辑复杂），心跳就会超时，Coordinator 认为该 Consumer 已死，立即触发 Rebalance。
• 结论：在高并发下，任何轻微的网络抖动或 GC 都可能引发连锁反应，导致整个消费者组频繁 Rebalance。系统将永远在“停止消费 -> 分配分区 -> 恢复消费 -> 再次故障”的循环中，有效吞吐为零。

【生产级配置与代码】

1. 核心配置 (consumer.properties)

要避免 Rebalance 风暴，必须拉长超时时间，并优化消费逻辑。

# 1. 会话超时：Consumer 失联多久后 Coordinator 会触发 Rebalance。
#    建议：设置为 30-60秒，给网络抖动和 GC 留出缓冲。
session.timeout.ms=30000

# 2. 心跳间隔：Consumer 向 Coordinator 发送心跳的频率。
#    建议：必须小于 session.timeout.ms 的 1/3。例如 session=30s，心跳=10s。
heartbeat.interval.ms=10000

# 3. 拉取超时：Consumer 两次 poll() 之间的最大间隔。
#    建议：根据业务处理能力设置，必须小于 session.timeout.ms。
#    如果业务处理慢，宁愿让该 Consumer 主动离组（触发轻量级 Rebalance），也不要卡住导致整个组 Rebalance。
max.poll.interval.ms=600000 # 10分钟，给复杂计算留足时间

# 4. 拉取数量：单次 poll 最大拉取消息数。
#    建议：根据消息大小和处理能力调整。避免一批消息过大导致处理超时。
max.poll.records=500

# 5. 分配策略：推荐使用 sticky 策略，减少 Rebalance 时的分区迁移。
partition.assignment.strategy=org.apache.kafka.clients.consumer.RangeAssignor,org.apache.kafka.clients.consumer.StickyAssignor

2. 代码演示 (Java)

以下代码展示了如何处理 Rebalance 监听、手动提交 Offset，以及避免在 poll 循环中阻塞。

import org.apache.kafka.clients.consumer.*;
import org.apache.kafka.common.TopicPartition;
import org.apache.kafka.common.serialization.StringDeserializer;
import java.time.Duration;
import java.util.*;

public class StableConsumer {

    public static void main(String[] args) {
        // 1. 配置 Consumer
        Properties props = new Properties();
        props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "kafka-broker1:9092");
        props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
        props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
        props.put(ConsumerConfig.GROUP_ID_CONFIG, "realtime-recommendation-group");

        // 生产级稳定性配置
        props.put(ConsumerConfig.SESSION_TIMEOUT_MS_CONFIG, "30000");
        props.put(ConsumerConfig.HEARTBEAT_INTERVAL_MS_CONFIG, "10000");
        props.put(ConsumerConfig.MAX_POLL_INTERVAL_MS_CONFIG, "600000");
        props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "false"); // 关闭自动提交！
        props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "latest");

        // 2. 创建 Consumer 并注册 Rebalance 监听器
        KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
        consumer.subscribe(Collections.singletonList("user_click_events"), new ConsumerRebalanceListener() {
            @Override
            public void onPartitionsRevoked(Collection<TopicPartition> partitions) {
                // 重要：在分区被回收前，手动提交 Offset，防止消息丢失或重复
                // 注意：这里提交的是本次 poll 循环开始前的 Offset，不是处理中的
                System.out.println("分区即将被回收，提交 Offset: " + consumer.commitSync());
            }

            @Override
            public void onPartitionsAssigned(Collection<TopicPartition> partitions) {
                // 重要：在分区分配后，可以加载本地缓存、建立连接等
                System.out.println("分区已分配: " + partitions);
                // 可以在这里从外部存储（如 Redis）恢复消费进度
            }
        });

        // 3. 消费循环
        try {
            while (true) {
                // 拉取消息，超时时间可配置
                ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
                
                if (records.isEmpty()) {
                    continue;
                }

                // 业务处理：必须在 max.poll.interval.ms 内完成
                for (ConsumerRecord<String, String> record : records) {
                    try {
                        // 模拟业务逻辑（例如调用推荐模型）
                        processMessage(record.value());
                    } catch (Exception e) {
                        // 异常处理：记录死信队列或重试，不要阻塞循环
                        System.err.println("处理失败，写入死信队列: " + record.value());
                    }
                }

                // 4. 手动异步提交 Offset：确保业务处理成功后才提交
                consumer.commitAsync((offsets, exception) -> {
                    if (exception != null) {
                        System.err.println("提交失败，需要监控并处理: " + offsets);
                        // 可以在这里触发告警
                    } else {
                        // System.out.println("提交成功: " + offsets);
                    }
                });
            }
        } finally {
            consumer.close();
        }
    }

    private static void processMessage(String message) {
        // 模拟耗时操作
        if (message.length() > 0) {
            // 模拟处理逻辑
        }
    }
}

【老司机的血泪教训】

1. 误区一：max.poll.interval.ms 设置过短，且业务逻辑复杂

   • 事故：一个数据清洗任务，单次 poll 拉取了 1000 条记录，每条记录需要 1 秒处理。总耗时超过 max.poll.interval.ms。Consumer 被踢出组，触发 Rebalance。但新分配的 Consumer 同样会拉到这 1000 条，同样超时。最终陷入无限 Rebalance 循环。
   • 教训：必须根据业务处理速度调整 max.poll.interval.ms 和 max.poll.records。如果单条处理慢，就减少 max.poll.records。如果无法优化速度，考虑将任务拆分到多个更轻量的 Consumer 中。

2. 误区二：在 Rebalance 监听器中执行耗时操作

   • 事故：开发在 onPartitionsAssigned 中初始化了一个耗时 30 秒的数据库连接池。导致该 Consumer 无法及时响应心跳，被判定为死亡，再次触发 Rebalance。
   • 教训：Rebalance 监听器的回调是同步阻塞的。onPartitionsRevoked 和 onPartitionsAssigned 中的代码必须极快执行（毫秒级）。任何耗时初始化或清理工作，都应该异步处理或放到 poll 循环之外。

【今日运维命令/作业】

作业：观察你的消费者组在发生 Rebalance 时的状态。

命令：查看消费者组的详细信息，包括当前成员、分配的分区和消费进度。

# 命令格式
kafka-consumer-groups.sh --bootstrap-server <kafka_broker_url:9092> --describe --group <your_consumer_group_id>

# 示例
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group realtime-recommendation-group

输出解读：

• CURRENT-OFFSET 和 LOG-END-OFFSET：计算 Lag。
• CLIENT-ID / HOST：查看当前是哪些 Consumer 实例在消费。
• 观察点：在执行 Broker 重启或杀死 Consumer 进程时，反复执行此命令，观察 CURRENT-OFFSET 是否停滞、Consumer 实例是否消失，从而直观感受 Rebalance 的过程。

---

总结：Consumer 的稳定性不在于代码的复杂，而在于配置的“冗余”和“宽容”。今天请务必在测试环境模拟 Consumer 处理超时，观察 Rebalance 的发生，并通过调整 session.timeout.ms 和 max.poll.interval.ms 来平息这场风暴。记住，在分布式系统中，给组件留出“犯错”的时间，就是给自己留出“生存”的空间。