📚 课程目录第4章 Kafka消费者详解

4、Kafka消费者详解：消费组与再均衡、位移提交、自动与手动提交、幂等性与事务

好，咱们进入第四章。前面我们把生产者怎么发消息聊透了，现在该聊聊消费者了。说实话，消费端才是生产环境里最容易出幺蛾子的地方。我见过太多团队，生产者写得挺稳，结果消费者一上线，各种位移丢失、重复消费、再均衡风暴全来了。

这一章，咱们就把消费者这几个核心机制掰开揉碎讲清楚。你把这些搞明白，实时入仓的消费端基本就稳了。

4.1 消费组与再均衡

先说说消费组。Kafka 的消费组，说白了就是一个逻辑上的消费者集群。同一个组里的消费者，共同分担一个或多个主题的分区消费任务。每个分区只能被组内的一个消费者消费，这是 Kafka 保证分区内消息有序消费的前提。

我刚开始用 Kafka 时，总觉得消费组就是个简单的负载均衡。后来线上出过一次事故，才真正理解了它的设计意图。

核心原则： 一个分区只能被同一个消费组内的一个消费者实例消费。不同消费组之间完全独立，可以重复消费同一条消息。

再均衡（Rebalance）是什么？就是消费组成员发生变化时，Kafka 重新分配分区归属的过程。触发条件有三个：

组内有消费者加入或离开
消费者订阅的主题发生变化
消费者长时间不发送心跳，被协调器判定为宕机

再均衡期间，整个消费组会短暂停止消费。所有消费者都会撤销已分配的分区，然后重新分配。这个过程如果频繁发生，就是所谓的「再均衡风暴」。我曾经在一个大促期间遇到过，某个消费者 GC 停顿时间过长，导致心跳超时，触发了全组再均衡。结果刚均衡完，另一个消费者又超时了，循环往复，整整卡了十几分钟。

避坑指南： 再均衡期间，消费者会触发分区撤销回调（onPartitionsRevoked）和分区分配回调（onPartitionsAssigned）。如果你在撤销回调里提交位移，一定要确保提交逻辑是幂等的，否则容易造成重复消费。

再均衡的策略主要有三种：

策略名称	分配逻辑	适用场景
Range	按主题分区范围分配	分区数均匀、消费者数固定的场景
RoundRobin	轮询分配，尽量均匀	多主题订阅、消费者数变化频繁的场景
Sticky	尽量保持已有分配，减少分区移动	生产环境推荐，避免不必要的分区迁移

我个人习惯在生产环境用 Sticky 策略。它能在再均衡时尽量保留消费者已有的分区，减少分区移动带来的开销。你想想看，如果每次再均衡都要把全部分区重新分配一遍，那些正在处理的消息怎么办？

// 设置 Sticky 分配策略
Properties props = new Properties();
props.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG, 
          "org.apache.kafka.clients.consumer.StickyAssignor");

4.2 位移提交

位移（Offset）是消费者消费进度的标记。Kafka 把每个分区已消费到的位置记录在内部主题 __consumer_offsets 里。这个设计很巧妙，它让消费者重启后能接着上次的位置继续消费。

位移提交的方式分两种：自动提交和手动提交。咱们一个一个说。

4.2.1 自动提交

自动提交是默认行为。消费者每隔 auto.commit.interval.ms（默认 5 秒）自动提交一次当前拉取到的最大位移。

听起来很方便对吧？但这里有个坑：自动提交的时机是「拉取到消息后」，而不是「处理完消息后」。如果消费者在处理消息的过程中崩溃了，位移已经提交了，但消息还没处理完。等消费者重启后，那些没处理完的消息就再也消费不到了。

注意： 自动提交只适用于「允许少量消息丢失」的场景，比如日志采集、监控指标等。对于实时入仓这种需要精确一次语义的场景，千万别用自动提交。

4.2.2 手动提交

手动提交给了你完全的控制权。你可以在确认消息处理完成后，再提交位移。这样即使消费者崩溃，重启后也能从上次提交的位置重新消费。

手动提交有两种模式：

同步提交（commitSync）： 阻塞等待提交结果。优点是可靠，缺点是会阻塞消费线程。
异步提交（commitAsync）： 不阻塞，立即返回。优点是性能好，缺点是提交失败时不会重试。

我一般这样用：

// 同步提交，确保位移准确
try {
    consumer.commitSync();
} catch (CommitFailedException e) {
    // 提交失败，记录日志，必要时重试
    log.error("位移提交失败", e);
}

// 异步提交，配合回调处理失败
consumer.commitAsync((offsets, exception) -> {
    if (exception != null) {
        log.warn("异步提交失败，offsets: {}", offsets, exception);
    }
});

你可能会问：异步提交失败了怎么办？嗯，这里有个技巧。异步提交失败后，如果立即重试，可能会导致位移回退。比如你提交 offset=100 失败了，但后续又提交了 offset=200 成功了。这时候如果重试 offset=100，就会把位移回退到 100，造成大量重复消费。

我的做法是：异步提交失败后，只在程序关闭前做一次同步提交兜底。平时异步提交失败就记录日志，不重试。

4.3 幂等性与事务

聊完位移提交，咱们进入更高级的话题：幂等性和事务。这两个机制是 Kafka 实现精确一次语义（Exactly-Once Semantics, EOS）的基石。

4.3.1 幂等性

幂等性保证生产者发送的消息不会因为网络重试而重复写入。它的原理很简单：每个生产者有一个唯一的 producerId，每条消息带一个递增的序列号。Broker 端会检查序列号，如果发现重复的序列号，就直接丢弃。

开启幂等性只需要一个配置：

props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);

但注意，幂等性只保证单个生产者会话内的不重复。如果生产者重启了，producerId 会变，之前的序列号信息就丢了。所以幂等性不能跨会话保证。

经验之谈： 幂等性开启后，生产者吞吐量会有轻微下降（大约 5%-10%），因为需要额外的序列号校验。但对于实时入仓场景，这点性能损失完全可以接受。

4.3.2 事务

事务解决了跨分区、跨会话的原子性写入问题。它让生产者可以原子性地写入多个分区，要么全部成功，要么全部失败。

事务的实现依赖一个协调器（Transaction Coordinator），它负责管理事务的状态。整个流程分四步：

生产者向协调器注册事务
生产者发送消息到目标分区
生产者提交或中止事务
协调器将事务结果写入事务日志

配置事务需要三步：

// 1. 设置事务 ID
props.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "txn-id-001");

// 2. 初始化事务
producer.initTransactions();

// 3. 在事务内发送消息
try {
    producer.beginTransaction();
    producer.send(new ProducerRecord<>("topic-a", "key", "value"));
    producer.send(new ProducerRecord<>("topic-b", "key", "value"));
    producer.commitTransaction();
} catch (Exception e) {
    producer.abortTransaction();
}

消费者端要配合事务，需要设置隔离级别：

props.put(ConsumerConfig.ISOLATION_LEVEL_CONFIG, "read_committed");

这样消费者只会读取已提交的事务消息，不会读到未提交或已中止的消息。

关键点： 事务和幂等性不是互斥的。开启事务时，幂等性会自动开启。事务是幂等性的超集，它解决了跨分区、跨会话的原子性问题。

我在做实时入仓时，事务用得最多的地方是「读取-处理-写入」的 ETL 场景。比如从 Kafka 消费数据，经过 Flink 处理后，再写入另一个 Kafka 主题。这时候用事务可以保证「消费位移提交」和「生产结果写入」这两个操作原子化，不会出现「数据写了但位移没提交」或者「位移提交了但数据没写」的情况。

但事务也有代价。它会增加延迟，因为每次事务提交都需要两阶段提交协议。对于延迟敏感的场景，需要权衡一下。

好了，这一章的内容就到这儿。消费组、位移提交、幂等性和事务，这几个概念你吃透了，Kafka 消费端的基本功就算扎实了。下一章咱们会把这些知识用到 Flink 的 Kafka Connector 里，看看 Flink 是怎么和 Kafka 打交道的。