Kafka批量消费实战：原理、参数调优与避坑指南

1. 批量消费不是“调个参数”那么简单

先直接说结论：Kafka 的批量消费，本质上是在吞吐量、延迟、可靠性和代码复杂度之间做权衡，而不是某个配置项打开就万事大吉。我在生产环境里见过太多团队，把 max.poll.records 调到 500，结果下游处理不过来，消费者频繁触发 max.poll.interval.ms 超时，分区不断 rebalance，消费组原地抖动，消息延迟反而更高了。

所以这篇内容我会从底层原理讲到代码实现，再讲真实项目的调优思路，最后用排查实录收尾。不绕弯子，直接进入正题。

2. 先搞懂 Kafka 消费者到底是怎么“批量”拉消息的

2.1 poll 模型决定了消费的“批”从哪里来

Kafka 消费者和 RabbitMQ、RocketMQ 的最大区别在于：它不是推送模型，而是拉取模型（Pull Model）。消费者主动向 Broker 发起 FetchRequest，Broker 返回一批消息，这个动作对应代码里的 KafkaConsumer.poll()。

很多初学者以为“一次 poll 就返回一条消息”，这是最大误区。实际上一次 poll 可能返回 0 条、1 条、几百条甚至上千条，完全取决于你拉取时 Broker 端满足条件的数据量。换句话说，批量消费的第一层“批”，是 poll 一次性拉回来的这一批消息。

这里要区分两个容易混淆的概念：

• 批量生产（Batch Produce）：Producer 端攒一批消息再发出去，通过 batch.size 和 linger.ms 控制，优化的是发送端吞吐。
• 批量消费（Batch Consume）：Consumer 端一次拉取多条消息再处理，优化的是消费端吞吐。

实际面试中经常有人把这两个混着说，但其实它们分别在链路的两端，调优参数也不一样，后面我会逐个展开。

2.2 哪些参数真正影响“一次 poll 能拉多少”

翻遍 ConsumerConfig 的源码，真正决定一次 poll 返回多少数据的核心参数有这么几个：

关键逻辑在这里：一次 poll 拉回来的总条数，取决于 max.poll.records，但实际能不能拉满，受 fetch.min.bytes 和 max.partition.fetch.bytes 共同限制。比如你 max.poll.records 设了 1000，但每个分区的 max.partition.fetch.bytes 只有 1MB，每条消息 10KB，那最多也就拉 100 条上下。

我见过一个比较典型的配置错误：消费二进制消息时没调 max.partition.fetch.bytes，单条消息超过 1MB，分区数据一直拉不回来，但 Broker 端一点异常都没有，消费组就是不动。排查了很久才发现是这个参数在作怪。

2.3 “拉一批”和“处理一批”是两回事

这是很多团队做批量消费时最致命的误解。poll() 拉回来的 500 条消息，只是“候选数据”，怎么处理这些数据完全由你的业务代码决定。

如果你在循环里用单线程逐条处理，那 500 条只是给你一个“慢慢处理”的缓冲区，吞吐提升极其有限。真正的批量消费，是指：

1. 一次 poll 拉回 N 条消息；
2. 把这 N 条消息聚合成一个“批次”；
3. 以批次为单位做处理：批量写数据库、批量调接口、批量写 Redis、批量写 ES 等。

能做到第 3 步，才是真正吃到了批量消费的红利。所以我在设计批量消费方案时，从来不会只配参数，而是会把“批次处理”作为一套独立的代码框架来设计，这也是下文的核心内容。

3. 核心参数怎么调：不是越大越好

3.1 max.poll.records 的调优思路

先说结论：max.poll.records 不能拍脑袋设，它必须满足一个硬性约束——

单次 poll 返回全部消息的处理时长，必须小于 max.poll.interval.ms（默认 300000，即 5 分钟）。

如果处理超时，消费者会被判定为“死亡”，触发 rebalance，分区被分配给其他消费者，处理中的消息重新消费，可能造成重复。这个约束我在生产环境里亲眼见过太多次，所以每次调参都会先把处理耗时测一遍。

假设你的下游批量写接口单批 500 条耗时 2 秒，那么 1 秒能处理约 250 条。如果一次 poll 拉回 2000 条，处理耗时约 8 秒，虽然远小于 5 分钟，但这时候真正的瓶颈已经不在 Kafka 了，而在下游处理速度。

更有意思的是 max.poll.records 设得过大，JVM GC 压力会骤增。500 条消息如果每条 10KB，也就 5MB，但如果消息体是复杂的 JSON，List 对象占用堆内存会成倍放大。我之前一个项目把 max.poll.records 调到 5000，线上频繁 Full GC，dump 下来一看全是消息对象，后来降回 1000，世界安静了。

3.2 fetch.min.bytes 和 fetch.max.wait.ms 的配合玩法

这两个参数组合起来，控制的是“实时性”和“批次量”的平衡。

如果你希望攒够一定数据量再拉，可以把 fetch.min.bytes 调大，比如 32KB。但问题在于：如果某个热门 Topic 消息量不大，你可能要等满 fetch.max.wait.ms（默认 500ms）才拉回一批，这会直接增加消息的端到端延迟。

相反，如果你追求低延迟，可以把 fetch.min.bytes 设为 1（默认值），让 Broker 有数据就立刻返回。但这样带来的问题是：如果消息量很大，一次 FetchRequest 可能只拿到一两条消息，fetch 请求会非常频繁，网络开销上去了，Broker 的 CPU 也会受影响。

我实际项目里常用的组合是：低延迟场景 fetch.min.bytes=1，fetch.max.wait.ms=200；高吞吐场景 fetch.min.bytes=65536（64KB），fetch.max.wait.ms=1000。没有绝对正确，只有场景适配。

3.3 一个容易被忽略的隐患：max.poll.interval.ms 之外的“隐形超时”

除了 max.poll.interval.ms，还有两个超时参数在批量消费中经常坑人：

• session.timeout.ms：默认 45000，用来检测消费者进程是否存活，如果消费者连不上 Broker 超过这个时间，会被判定死亡。注意，它和 poll 处理时长无关，但如果你的 GC 停顿时间过长，或者网络抖动，会触发误判。
• heartbeat.interval.ms：默认 3000，心跳发送间隔，必须远小于 session.timeout.ms，否则容易误触发 rebalance。

在批量消费场景下，如果你把一批消息的处理做的比较重（比如批量写 ES、批量写 ClickHouse），最稳妥的做法是：让消费者线程把消息提交给一个本地队列，立刻返回 poll 循环，再由专门的线程池处理。这样 poll 永远不超时，同时处理线程可以慢工出细活。

4. 批量消费的代码设计：从“能跑”到“好用”

4.1 第一种方案：poll 循环内直接批量处理（简单但有限）

先给一个最基础的示例，用原生 Kafka Client 实现：

java复制Properties props = new Properties();
props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(ConsumerConfig.GROUP_ID_CONFIG, "batch-consumer-group");
props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, 500);
props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "false");
props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(Collections.singletonList("batch-topic"));

try {
    while (true) {
        // 一次 poll 拉回最多 500 条
        ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000));
        if (records.isEmpty()) {
            continue;
        }

        // 将本批消息批量插入数据库
        List<UserEvent> batch = new ArrayList<>(records.count());
        for (ConsumerRecord<String, String> record : records) {
            batch.add(JsonUtils.parseObject(record.value(), UserEvent.class));
        }
        userEventMapper.batchInsert(batch);

        // 处理成功后手动提交偏移量
        consumer.commitSync();
    }
} finally {
    consumer.close();
}

这个方案的问题很明显：处理逻辑和 poll 循环强耦合，如果 batchInsert 耗时过长，poll 会超时；而且如果处理中途抛异常，offset 没有提交，重启后会从最后提交位置重新消费，造成重复。它适合数据量不大、下游写入有保障的轻量场景，比如日志转存、简单的埋点上报。

4.2 第二种方案：异步批量处理 + 手动提交语义（生产级）

为了解耦 poll 和处理，我推荐一个更健壮的架构：

java复制// 使用一个配置了合理参数的单线程消费，把消息投递到线程池，由线程池批量处理
ExecutorService processExecutor = new ThreadPoolExecutor(
        4, 8, 60, TimeUnit.SECONDS,
        new ArrayBlockingQueue<>(1024),
        new ThreadFactoryBuilder().setNameFormat("batch-process-%d").build(),
        new ThreadPoolExecutor.CallerRunsPolicy());

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(500));
    if (records.isEmpty()) {
        continue;
    }

    // 注意：这里必须先把本批数据封装成任务提交，不能直接循环内做处理
    processExecutor.submit(() -> {
        List<UserEvent> batch = new ArrayList<>(records.count());
        for (ConsumerRecord<String, String> record : records) {
            batch.add(JsonUtils.parseObject(record.value(), UserEvent.class));
        }
        userEventMapper.batchInsert(batch);
        return null;
    });

    // 提交一个任务后，立即提交偏移量
    // 但这里存在一个隐患：如果线程池中的任务还没执行完，偏移量已经提交了，消费者进程挂了会丢数据
    consumer.commitSync();
}

这段代码存在经典矛盾：如果你在投递任务后就提交 offset，万一任务执行前消费者挂掉，消息就丢了；如果你想等任务执行完再提交，poll 可能超时。

所以更稳妥的写法是引入一个“处理结果回调”，在任务真正完成后再提交 offset：

java复制while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(500));
    if (records.isEmpty()) {
        continue;
    }

    CountDownLatch latch = new CountDownLatch(1);
    processExecutor.submit(() -> {
        try {
            List<UserEvent> batch = new ArrayList<>(records.count());
            for (ConsumerRecord<String, String> record : records) {
                batch.add(JsonUtils.parseObject(record.value(), UserEvent.class));
            }
            userEventMapper.batchInsert(batch);
        } finally {
            latch.countDown();
        }
    });

    // 等待线程池处理完成再提交 offset
    boolean completed = latch.await(30, TimeUnit.SECONDS);
    if (completed) {
        consumer.commitSync();
    } else {
        // 记录日志、告警，决定是否退出消费或抛异常触发 rebalance
        log.error("batch process timeout, records count: {}", records.count());
        throw new RuntimeException("batch process timeout");
    }
}

注意这里有个细节：latch.await 会让 poll 循环阻塞，如果处理超过 max.poll.interval.ms 依然会触发 rebalance。所以上面的方案实际上对处理时效性要求很高，适合下游较快、batch 大小控制严格的场景。

4.3 第三种方案：手动控制拉取条数，自己攒批（灵活但复杂）

如果你追求极致的批量吞吐，可以放弃 max.poll.records 默认拉满的策略，改用 pause + resume 手动控制流量。原理是：

• 如果本批处理不过来，就 consumer.pause(partitions) 暂停分区拉取；
• 等处理完了再 consumer.resume(partitions) 恢复拉取。

这个方案能很好的解决“拉得太多处理不完”的问题，代码复杂度也明显上升。我在一个数据同步的项目里使用过，效果不错，但需要处理很多边界情况（如暂停期间其他分区的约束、rebalance 时的暂停状态恢复等），除非必要，不太建议新手一上来就这么搞。

4.4 顺带一提：Spring Boot 工程里的批量消费配置

如果你用 spring-kafka，事情会简单不少。只需要开启批量监听，并指定批量工厂：

java复制@Configuration
public class KafkaBatchConfig {

    @Bean
    public KafkaListenerContainerFactory<ConcurrentMessageListenerContainer<String, String>>
        batchFactory(ConsumerFactory<String, String> consumerFactory) {
        ConcurrentKafkaListenerContainerFactory<String, String> factory =
                new ConcurrentKafkaListenerContainerFactory<>();
        factory.setConsumerFactory(consumerFactory);
        // 开启批量监听
        factory.setBatchListener(true);
        // 一次 poll 最多拉取 200 条
        factory.getContainerProperties().setPollTimeout(3000);
        // 消费线程数
        factory.setConcurrency(3);
        return factory;
    }

    @Bean
    public KafkaListenerContainerFactory<ConcurrentMessageListenerContainer<String, String>>
        singleFactory(ConsumerFactory<String, String> consumerFactory) {
        ConcurrentKafkaListenerContainerFactory<String, String> factory =
                new ConcurrentKafkaListenerContainerFactory<>();
        factory.setConsumerFactory(consumerFactory);
        // 默认单条监听
        return factory;
    }
}

使用方式：

java复制@Component
public class BatchMessageConsumer {

    @KafkaListener(topics = "batch-topic", groupId = "spring-batch-group",
            containerFactory = "batchFactory")
    public void onBatchMessage(List<ConsumerRecord<String, String>> records) {
        log.info("收到批量消息，数量：{}", records.size());
        // 批量处理逻辑
        List<UserEvent> batch = records.stream()
                .map(record -> JsonUtils.parseObject(record.value(), UserEvent.class))
                .collect(Collectors.toList());
        userEventMapper.batchInsert(batch);
    }
}

在 Spring 工程里，有个参数容易被忽略：factory.getContainerProperties().setAckMode(ContainerProperties.AckMode.BATCH)。如果不设置 ackMode，默认是 BATCH，即本批消息全部消费成功后一次性提交偏移量，失败则本批全部重试，正好符合批量语义。

5. 批量消费的经典杀手：重复消费、乱序和事务边界

5.1 重复消费是必然，不是偶然

很多团队在批量消费踩坑后，第一反应是“Kafka 为什么重复了”。实际上对于 Kafka 这种 at-least-once 语义的系统，重复是常态，你需要做的是幂等。

批量消费场景下重复的概率远高于单条消费，原因有几个：

• 批量处理到一半抛异常，offset 没提交，本批消息重新拉取；
• 消费者 rebalance 期间，部分已拉取未提交 offset 的消息被分配给其他消费者重新处理；
• enable.auto.commit 开启时，提交 offset 的时机不可控。

我在实践中总结了一套批量幂等的基础方案：

1. 为每条消息定义一个全局唯一业务 ID（比如订单号、用户事件 ID）；
2. 在批量写入时，在数据库表中添加唯一索引；
3. 写入用 INSERT ... ON DUPLICATE KEY UPDATE 或 INSERT IGNORE 类型语句，保证重复写入不会产生脏数据；
4. 如果写入的是 Redis，可以用 SETNX 或 SET EX NX 做幂等标记。

如果消息本身没有唯一 ID，可以在生产端生成时写入消息体一个 traceId，消费端用这个 traceId 做去重。不要去依赖 Kafka 自带的 offset 去重，那是做不到的。

5.2 有序性：批量消费最容易破坏的隐性规则

Kafka 的分区保证的是分区内有序，但在批量消费里，以下操作会破坏这个保证：

• 多线程消费同一个分区。你用一个线程池处理同一分区的消息，线程池调度顺序无法保证，消息就乱序了。
• 批量写入失败后重试。如果本批 500 条消息里有 300 条写成功了，剩下 200 条重试，那 200 条中的顺序可能被重试框架打乱。
• 使用事务性消费者做本地事务时，把一批消息塞进本地 DB 后再提交 offset，如果 DB 回滚而 offset 已提交，会造成消息丢失，顺序自然无从谈起。

如果业务对顺序敏感，我建议这样设计：

• 一个分区绑定一个单线程消费线程池，不要多个线程消费同一个分区；
• 批量处理时，如果一条失败，回滚本批全部处理，保证有序性；
• 保证 max.poll.records 不要设置太大，避免单批重试成本过高。

5.3 事务边界：怎么保证“这批消息要么全成功，要么全失败”

Kafka 从 0.11 开始支持生产者事务，配合消费端 read_committed 隔离级别，可以实现端到端 Exactly-once 语义。但说实话，我很少建议业务团队在生产环境直接上这个方案，因为复杂度极高。

对于大部分场景，更可靠的“事务边界”是用下游存储的事务：

• 把一批消息写入 MySQL 时，启一个本地事务，本批全部入库成功后，再提交 offset；
• 如果入库失败，回滚，不提交 offset，触发重拉。

上面这个方案的问题在于“本地事务 + offset 提交”不是原子的。要真正解决，可以引入“事务消息表”：

sql复制-- 在每个消费服务对应的业务库里，建一张消费记录表
CREATE TABLE consumer_offset (
    topic        VARCHAR(64) NOT NULL,
    partition    INT         NOT NULL,
    offset       BIGINT      NOT NULL,
    process_time TIMESTAMP   DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (topic, partition)
);

消费逻辑调整为：

1. 开启本地事务；
2. 把本批消息的业务数据写入业务表；
3. 更新 consumer_offset 表，记录本批最大 offset；
4. 提交本地事务；
5. 接下来手动提交 Kafka offset，即使这步失败，重启后也会从 consumer_offset 表中恢复位点。

这个方法虽然增加了一次 DB 写，但能把 Kafka 消息处理和业务数据写入绑成一个可靠事务，在生产实践中非常稳。

5.4 批量消费的下游写入优化，直接影响上限

批量消费的最终胜败取决于下游引擎能不能扛住批量写入。这里把我的实测经验列一下：

以 MySQL 为例，见过太多新人没用 rewriteBatchedStatements，以为用了 executeBatch() 就是批量了，实际 JDBC 还是逐条发送，性能完全没起来。加上这个参数后，实测 1000 条一次提交，耗时从原来的 8 秒降到 300 毫秒。

6. Spring Boot 工程里的批量消费完整落地示例

6.1 项目配置和依赖

先用 Maven 引入关键依赖（基于 Spring Boot 2.7+，Kafka Client 3.x）：

xml复制<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-json</artifactId>
</dependency>

配置文件：

yaml复制spring:
  kafka:
    bootstrap-servers: 10.0.0.11:9092,10.0.0.12:9092,10.0.0.13:9092
    consumer:
      group-id: batch-consume-group
      auto-offset-reset: earliest
      enable-auto-commit: false
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      max-poll-records: 500
      properties:
        max:
          poll:
            interval:
              ms: 300000
        session:
          timeout:
            ms: 15000
        heartbeat:
          interval:
            ms: 3000
    listener:
      type: batch
      concurrency: 3
      ack-mode: BATCH

这里有个细节我从实践中踩过坑：max.poll.interval.ms 默认 5 分钟，如果你生产环境批量处理一次超过 5 分钟，消费者会被踢出分组。所以如果业务处理耗时可能较长，可以把 max.poll.interval.ms 调的更大，比如 10 分钟，对应的 session.timeout.ms 和 heartbeat.interval.ms 也要合理设置，且心跳间隔建议不超过 session 超时的 1/3。

6.2 批量消费服务端代码

来看一个实际的“订单事件”批量消费代码，批量写入 MySQL：

java复制@Slf4j
@Component
public class OrderEventBatchConsumer {

    @Autowired
    private OrderEventMapper orderEventMapper;

    @KafkaListener(topics = "order-event-topic", groupId = "batch-consume-group",
            containerFactory = "batchKafkaListenerContainerFactory")
    public void consume(List<ConsumerRecord<String, String>> records) {
        if (CollectionUtils.isEmpty(records)) {
            return;
        }

        long start = System.currentTimeMillis();
        log.info("开始消费订单事件批，数量：{}", records.size());

        List<OrderEvent> batch = new ArrayList<>(records.size());
        for (ConsumerRecord<String, String> record : records) {
            try {
                OrderEvent event = JSON.parseObject(record.value(), OrderEvent.class);
                batch.add(event);
            } catch (Exception e) {
                // 单条解析失败不能拖死整批，跳过或记录死信
                log.error("解析订单事件失败，offset={}, value={}", record.offset(), record.value(), e);
            }
        }

        if (batch.isEmpty()) {
            return;
        }

        try {
            // 批量写入
            orderEventMapper.batchInsert(batch);
            // ackMode=BATCH 时，这里成功后 spring-kafka 会自动提交本轮偏移量
        } catch (Exception e) {
            log.error("批量写入订单事件失败，本批数量：{}", batch.size(), e);
            // 抛出异常触发重试或死信逻辑
            throw new KafkaException("批量消费失败", e);
        }

        long cost = System.currentTimeMillis() - start;
        log.info("订单事件批次处理完成，数量：{}，耗时：{}ms", records.size(), cost);
    }
}

注意上面代码中有一个 try-catch：解析单条消息失败时，我选择忽略并记录日志，而不是让整批失败。这是生产环境非常实用的取舍：如果一条脏数据导致整批回滚，会带来雪崩式重复消费。但忽略也需要配合“死信”机制，比如把解析失败的消息发送到 order-event-dlq 主题，后续人工处理。

6.3 批量写入 MySQL 时的 Mapper 写法

MyBatis 批量插入有两种常见写法。第一种是 XML 中 foreach 拼接 SQL：

xml复制<insert id="batchInsert" parameterType="list">
    INSERT INTO order_event (
        order_id, event_type, event_time, payload, created_at
    ) VALUES
    <foreach collection="list" item="item" separator=",">
        (#{item.orderId}, #{item.eventType}, #{item.eventTime}, #{item.payload}, NOW())
    </foreach>
</insert>

第二种是使用 MyBatis 的 ExecutorType.BATCH。但实测下来，第一种 foreach 配合 JDBC 的 rewriteBatchedStatements=true，性能已经很理想，而且代码更直观。

需要注意 MySQL 对单条 INSERT 语句有 max_allowed_packet 限制，默认 4MB 或 64MB。如果 max.poll.records 设得过大，一次拼出来的 SQL 可能超过这个限制，导致批量插入失败。我的经验是单批总字节数控制在 1~2MB 以内比较稳，这也是为什么我建议 max.poll.records 别盲目的设成 5000。

6.4 批量消费中的“消息积压”监控

批量消费做的好不好，不能光看日志，还要有监控。我在项目里会重点关注几个指标：

很多团队在“消费延迟高”这个问题上走了弯路，一上来就想调大 max.poll.records，实际最有效的手段往往是：

1. 增加消费者实例数（提升并行度）；
2. 增加 Topic 分区数（扩大并行上限）；
3. 优化下游写入（批量、去事务化、异步化）。

7. 真实踩坑案例：一条消息引发的 rebalance 风暴

7.1 问题现象

去年做一个支付事件同步服务，用的就是批量消费，max.poll.records=500，spring-kafka 的 ackMode 是 BATCH。上线后跑了三天，突然收到告警：消费组持续 rebalance，消费延迟从几百条涨到几十万条，下游订单同步几乎停摆。

看日志，发现一个很有意思的规律：所有消费者实例都在疯狂打印“commit failed”“coordinator not available”，同时大量分区在 active / revoke / assigned 之间反复横跳。

7.2 排查过程

一开始我怀疑网络问题，检查了 Broker 和消费者之间网络，一切正常。随后看了消费者日志，定位到一条关键异常：

code复制org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member.

意思是提交偏移量时，消费者已经不在分区所有者列表里了。这说明 rebalance 已经发生，而 rebalance 的根因通常是 poll 循环超时。于是我看 max.poll.interval.ms 配置，发现配置中心里被某位同事调成了 10000（10 秒）。

这就解释通了：当某批 500 条消息里包含几条大 JSON（单条 200KB），解析加批量写入 MySQL 超过 10 秒，poll 超时，触发 rebalance。rebalance 后，未提交 offset 的分区分配给其他消费者，又会重新拉取这些大消息，造成“永远处理不完、永远超时、永远 rebalance”的死循环。

7.3 解决方法

处理手段分两步：

1. 临时止血：把 max.poll.interval.ms 从 10000 调整为 300000（5 分钟），同时把 max.poll.records 从 500 降到 200，缓解单批处理压力。
2. 根治：检查生产端是否有消息体过大的情况，把单条消息超 100KB 的事件做了拆分；同时把批量消费改成“poll 中只做解析和入队，由独立线程池批量写库”，彻底规避 poll 超时问题。

改完观察一整天，rebalance 消失，消费延迟从十几万降到几千，再到几百，恢复正常。

这个案例给我的教训是：批量消费的参数必须和业务处理耗时强关联，而不是拍脑袋设一个“看起来大”的值。 任何一次 poll 后做的事情越多，风险就越高。

7.4 排查问题速查表

8. 批量消费的后续扩展：不要停在“能消费”

8.1 可扩展方向一：消费端滑动窗口批处理

如果你的业务要求“攒够 1000 条才写一次”或“每 2 秒写一次”，可以将 poll 循环改成滑动窗口模式。中心思想是：维护一个本地队列，消费者轮询拉取消息，把消息放入队列，当队列大小达到阈值或达到时间阈值时，触发一次批量处理。这个方案相当于把 Kafka 的批量拉取和业务批处理解耦，能更好地控制下游写入频率。

8.2 可扩展方向二：批量消费 + 流式计算框架

如果消息量极大，而且需要复杂的聚合、窗口计算，除了裸用 Kafka Consumer，还可以考虑集成 Flink（FlinkKafkaConsumer 天然支持批量拉取 + checkpoint 语义），或使用 Kafka Streams 的 groupBy + window 来做批量窗口计算。我之前用 Flink 消费 Kafka 写入 ES 的项目里，批量效果远优于手写消费者，因为 Flink 的 checkpoint 机制把 offset 和下游写入做成了事务绑定，重复消费的问题被框架层面解决了大半。

8.3 可扩展方向三：消费端背压控制

当 Kafka 某个分区消息量异常激增时，下游写入引擎（比如 MySQL）会不堪重负。除了用 pause / resume 手动控制拉取，还可以在业务层实现简单的令牌桶限流：只有拿到令牌才继续 poll，否则 sleep 一段时间。这种做法在削峰填谷时非常有效，代价是代码复杂度上升。

回到标题本身，“Kafka 批量消费实现”听起来像是一个很窄的技术点，但真正做下来，你会发现它牵扯到参数调优、线程模型、幂等设计、事务边界、下游写入优化、问题排查等多个环节。我见过很多项目在批量消费上栽跟头，基本都是因为只把它当成“几个配置项”来处理。

我个人在做这套方案时最大的体会是：先把 “poll 频率” 和 “处理速度” 的解耦想清楚，再用参数去适配这个模型，而不是反着来。 这比单纯把 max.poll.records 调大有效得多。如果你正在做批量消费，建议先从当前业务的单批处理耗时开始测，画出“批大小-耗时”曲线，再倒推参数该怎么设，这样基本不会出大问题。