Java Kafka生产者消费者实战：从入门到参数调优

做 Java 后端这几年，消息队列基本是绕不开的组件。我第一次在项目里引入 Kafka，就是为了解决订单服务跟库存服务之间同步调用越来越慢的问题。当时两个服务直接走 HTTP 接口，下单高峰期一个接口动不动好几秒，用户端体验很差。后来把订单消息发给 Kafka，下游服务自己去消费，整个链路一下就松了。这篇文章就把当时沉淀下来的一套基于 Java 的 Kafka 生产者-消费者示例完整拆一遍，从设计思路、环境搭建、核心代码到参数调优和排障，尽量都用大白话讲清楚。

如果你是刚开始学 Kafka 的 Java 开发，或者准备面试想搞懂生产者-消费者到底怎么玩，又或者想在本地快速把项目跑通，这篇应该能省你不少事。我不光会贴代码，还会解释每个参数为什么这么配、哪些配置在生产环境踩过坑，这些在官方文档里通常不会帮你总结。

1. 项目整体设计与核心思路

1.1 为什么选 Java + Kafka 这套组合

先说选型。消息队列不止 Kafka 一种，RabbitMQ、RocketMQ、Pulsar 都各有拥趸。但在 Java 生态里，Kafka 的客户端 API 设计得相当清爽，依赖少、上手快，而且它天然就是为高吞吐、分布式场景设计的。如果你处理的是日志采集、用户行为跟踪、订单消息同步这种流量大但允许一定延迟的数据，Kafka 基本是首选。

另外一点很实在：Kafka 用 Scala 和 Java 写的，天生跟 JVM 生态兼容。你在 Java 项目里引入 kafka-clients 依赖，不需要装额外的 broker 客户端组件，直接就能用。相比 RabbitMQ 的 AMQP 协议那一套，Java 原生的 Kafka Producer/Consumer API 更简单直观，对新人友好很多。

从业务角度看，生产者-消费者模式解决的其实是三个问题：

• 解耦：生产者不需要知道下游谁在处理消息，消费者也不关心消息从哪来，两边只依赖 Topic，互不感知。
• 削峰填谷：高峰期消息大量涌入，Kafka 先扛住，消费者按自己的速度慢慢消费，系统不会被打垮。
• 异步化：用户下单后立即返回成功，后续的发短信、积分、推送等操作异步消费，响应时间大幅降低。

1.2 Topic、Partition、Offset 三个概念必须搞懂

很多人学 Kafka 卡在概念上，其实用生活场景类比一下就通了。你可以把 Topic 想象成一个快递站点，发往同一个站点的快递都放一起；Partition 就是站点里的几个货架，货架之间物理隔离，可以并行处理；Offset 是快递在货架上的编号，消费者读到哪一件，就靠这个编号记录。

具体来说：

• Topic：消息的逻辑分类，生产者往 Topic 写，消费者从 Topic 读。一个 Topic 可以拆成多个 Partition。
• Partition：Topic 的物理分片，每个 Partition 内部消息是有序的，追加写入，不可修改。Partition 越多，并行度越高，但也意味着更多的文件句柄和元数据开销。
• Offset：消息在 Partition 内部的唯一序号，从 0 开始递增。消费者消费到哪一条，就是基于 Offset 来记录。

这里有个关键点：Kafka 只保证 Partition 内部有序，不保证整个 Topic 有序。如果业务要求订单消息严格按照下单顺序处理，那你得让同一个订单 ID 的消息都进同一个 Partition，这个通过 key 就能实现，后面生产者章节会细说。

1.3 生产者发消息的三种方式，怎么选

Kafka 生产者发消息有三种模式，新手很容易混淆。

第一种是发后即忘，直接 producer.send(record)，不关心结果。这种方式吞吐最高，但消息丢失风险也最大，生产环境基本不用。

第二种是同步发送，producer.send(record).get()，会阻塞等待 broker 响应。这种方式能保证消息送达，但吞吐量被拉低，适合对可靠性要求极高、数据量不大的场景。

第三种是异步发送，producer.send(record, callback)，发送时注册一个回调，broker 返回结果后触发。这是生产环境最常用的方式，吞吐和可靠性兼顾。回调里能拿到消息的 Partition、Offset 和异常信息，用来做日志记录和失败重试非常方便。

我自己的实践是：核心交易链路用异步发送加回调，配合重试机制；日志类数据量大的场景，把回调逻辑简化，减少回调带来的额外开销。

2. 开发环境准备与基础概念

2.1 本地环境搭建：JDK、Maven、Kafka

在写代码之前，先把环境跑起来。需要准备的东西有三个：JDK、Maven、Kafka。

JDK 建议直接用 17，现在大部分 Java 项目都已经切到 17 甚至 21 了，kafka-clients 3.x 版本在 JDK 17 下运行没有问题。有朋友刚装完 JDK 17，在 IDEA 里跑项目报“源发行版 17 需要目标发行版 17”，这个警告的意思是编译器级别没对上。去 IDEA 里把 Project Structure 的 SDK 和 Java Compiler 的 Target bytecode version 都改成 17，问题就解决了。

Maven 的话，建议直接用 3.8 以上版本，然后去 ~/.m2/settings.xml 里配个国内源，不然拉依赖会很痛苦。

Kafka 的安装分两种模式：老版本是 ZooKeeper + Kafka，新版本（3.3+）支持 KRaft 模式，不需要 ZooKeeper，单机体验更轻量。我建议本地直接上 KRaft 模式，步骤少很多。从官网下载二进制包后，执行：

bash复制# 生成一个集群 ID
kafka-storage.sh random-uuid

# 用返回的 UUID 格式化存储目录
kafka-storage.sh format -t <UUID> -c config/kraft/server.properties

# 启动 Kafka
kafka-server-start.sh config/kraft/server.properties

启动成功后，用 kafka-topics.sh 创建一个测试主题。这里提醒一下：本地测试副本因子设 1 就行，集群环境至少要 3，这是两套逻辑。

bash复制kafka-topics.sh --create --topic orders --partitions 3 --replication-factor 1 --bootstrap-server localhost:9092

2.2 引入 kafka-clients 依赖

创建一个 Maven 项目，在 pom.xml 里加依赖：

xml复制<dependency>
    <groupId>org.apache.kafka</groupId>
    <artifactId>kafka-clients</artifactId>
    <version>3.6.1</version>
</dependency>

这个依赖体积不大，它会自动带上 SLF4J API 等传递依赖。如果项目里没有日志实现，在控制台看不到输出，加一个 logback-classic 或者 slf4j-simple 就行。

对 Java 版本比较敏感的同学注意：kafka-clients 3.4 版本以上要求 JDK 8 或者 11 以上，3.6 版本开始也兼容 JDK 17，具体看官方文档的兼容性矩阵就行。选版本的时候不要盲目追新，稳定版 3.4 到 3.7 都够用。

2.3 一个贴近业务的示例背景

为了不让你看代码看得一头雾水，我先定一个业务场景：模拟一个订单系统，用户在商城下单后，订单服务把订单消息发送到 Kafka 的 orders 主题，库存服务作为消费者，从 orders 主题拉取订单消息并扣减库存。

这个场景很典型，既有生产者，又有消费者，还有明确的业务语义。后面所有代码、参数、排障都会围绕这条线展开。

3. 生产者端设计：参数与代码实现

3.1 核心参数配置与踩坑经验

生产者代码看起来就几十行，真正的学问全在参数配置里。我挑了六个最关键的参数，挨个说清楚。

bootstrap.servers 是 Kafka 集群的地址列表，配 localhost:9092 就行。注意这个只是用来建立初始连接的，不是配了它就跟所有 broker 都直连，客户端会通过这个地址拿到集群的完整元数据，再跟所有 broker 建立连接。

key.serializer 和 value.serializer 是序列化器。消息在网络上传输必须转成字节数组，key 和 value 都要指定序列化方式。一开始用 StringSerializer 就行，后面如果传对象，再换成 JSON 序列化器或者 Avro 序列化器。

acks 是可靠性级别的开关，它有 0、1、all 三个值，这是面试高频考点，也是生产配置最容易纠结的地方：

• acks=0：生产者发出去就不管了，不等 broker 确认。吞吐最高，但消息可能直接丢。
• acks=1：leader 副本写入成功就返回确认。正常情况下不会丢，但 leader 挂了且数据没同步到 follower 时会有损失。
• acks=all：所有 ISR 副本都写入成功才返回确认。可靠性最高，延迟也最高。

我自己的经验是：核心业务数据用 acks=all，日志数据用 acks=1，几乎不用 acks=0，那点吞吐优势不值得拿数据可靠性去换。

retries 是重试次数。网络抖动、broker 短暂不可用都会导致发送失败，设置合理的重试能提高成功率。但要注意：重试可能导致消息乱序，如果业务对顺序敏感，还得设置 max.in.flight.requests.per.connection=1，也就是同一个连接最多只有一个未确认的请求，这样失败重试就不会超过后面的消息。

batch.size 和 linger.ms 要放在一起讲。Kafka 生产者是批量发送消息的，batch.size 指定一个批次的大小（默认 16KB），linger.ms 指定批次在内存里等待的最大时间（默认 0）。两者配合：要么攒够 16KB 立即发，要么等 5 毫秒也发。线上调优时，如果消息单个体积小、量又大，可以适当调大 batch.size 和 linger.ms，吞吐会明显提升。但 linger.ms 不能设太大，不然延迟就上去了。

3.2 生产者完整代码实现

下面是完整的生产者代码示例，我加了不少注释，方便你对照理解：

java复制import org.apache.kafka.clients.producer.*;
import org.apache.kafka.common.serialization.StringSerializer;

import java.util.Properties;
import java.util.concurrent.atomic.AtomicInteger;

public class OrderProducer {

    public static void main(String[] args) {
        Properties props = new Properties();
        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
        props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        // 核心可靠性配置：所有 ISR 副本确认
        props.put(ProducerConfig.ACKS_CONFIG, "all");
        props.put(ProducerConfig.RETRIES_CONFIG, 3);
        // 批量聚合配置
        props.put(ProducerConfig.BATCH_SIZE_CONFIG, 16384);
        props.put(ProducerConfig.LINGER_MS_CONFIG, 5);
        props.put(ProducerConfig.BUFFER_MEMORY_CONFIG, 33554432);

        KafkaProducer<String, String> producer = new KafkaProducer<>(props);

        AtomicInteger successCount = new AtomicInteger(0);
        AtomicInteger failCount = new AtomicInteger(0);

        try {
            for (int i = 0; i < 100; i++) {
                String orderId = "O" + System.currentTimeMillis() + "-" + i;
                String key = "user-" + (i % 10);
                String value = String.format(
                        "{\"orderId\":\"%s\",\"productId\":\"p%d\",\"amount\":%d,\"userId\":%d}",
                        orderId, i, i * 10, i % 10
                );

                ProducerRecord<String, String> record = new ProducerRecord<>("orders", key, value);

                // 异步发送 + 回调，这是生产环境最常用的方式
                producer.send(record, (metadata, exception) -> {
                    if (exception == null) {
                        successCount.incrementAndGet();
                        System.out.printf("消息发送成功: partition=%d, offset=%d, key=%s%n",
                                metadata.partition(), metadata.offset(), key);
                    } else {
                        failCount.incrementAndGet();
                        System.err.printf("消息发送失败: key=%s, error=%s%n", key, exception.getMessage());
                    }
                });
            }
        } finally {
            // flush 会把缓冲区里还没发出去的消息强制发送
            producer.flush();
            System.out.printf("发送完成: 成功=%d, 失败=%d%n", successCount.get(), failCount.get());
            producer.close();
        }
    }
}

这段代码里有几个细节值得展开说。

producer.flush() 很关键。因为生产者是异步发送，消息先攒在内存缓冲区，如果不主动 flush，close() 时可能会丢一部分未发送的消息。flush() 会阻塞当前线程直到所有消息发送完成。实际项目中在关闭生产者之前，一定要先 flush。

回调里的 metadata 能拿到消息写入的 Partition 和 Offset，这俩信息在排查问题时候非常好用。如果发现某个 key 的消息始终落在同一个分区，不要慌，这正是默认分区器的正常行为：如果 key 不为 null，就对 key 的哈希值取模，算出分区号，同一个 key 一定进同一个分区。

3.3 分区策略：key 怎么决定消息去哪

默认分区器的逻辑很简单：key 为 null 时，使用粘性分区策略，随机把消息打散到各分区；key 不为 null 时，对 key 做哈希，hash % numPartitions 得到分区号。

这意味着什么？如果你希望同一个用户的订单消息都顺序处理，就用用户 ID 当 key，同一个用户的消息永远进同一个分区，消费者按分区顺序消费，顺序就保证了。

如果你只关心吞吐、不关心顺序，key 可以传 null，让 Kafka 自己均匀分配。

如果默认策略满足不了需求，比如你想让某些 VIP 用户的消息走单独的高性能分区，可以实现自定义分区器，实现 Partitioner 接口，在 partition() 方法里写自己的路由逻辑，然后在配置里指定：

java复制props.put(ProducerConfig.PARTITIONER_CLASS_CONFIG, MyPartitioner.class.getName());

不过自定义分区器要慎用，分配不均会导致数据倾斜，有个分区写爆了，其他分区空闲，反而更慢。

4. 消费者端设计：消费模型、Offset 与代码实现

4.1 消费组是怎么回事

消费者跟生产者的最大区别，在于消费者是以“消费组”为单位工作的。同一个消费组里的消费者共同消费一个 Topic，每条消息只会被组内一个消费者处理。不同消费组之间互不影响，都能消费到全量消息。

这个设计很巧妙。类比一下：一个订单消息，订单服务消费一次用于更新订单状态，短信服务消费一次用于发通知，两个服务的消费组不同，各自都能拿到全量消息。而订单服务内部如果起了多个实例，同一个消费组内会分担消息，保证一条消息不被重复处理。

有了消费组，还要理解 Rebalance，也就是消费者组成员发生变化（新增、宕机、主动退出）时，Kafka 会把分区重新分配给组内消费者。Rebalance 期间消费会暂停，对实时性要求高的业务会有感知。后面常见问题章节我再细说 Rebalance 太频繁怎么排查。

4.2 消费者核心参数逐个拆解

消费者参数里，有几个是必须理解的。

group.id 是消费组 ID，同一个组的消费者必须一致，否则会被当成不同的组，消息就会重复消费。

enable.auto.commit 控制是否自动提交 Offset。默认是 true，每 5 秒自动提交一次。这个配置对新手来说是坑：如果你消费逻辑处理时间是 10 秒，自动提交周期是 5 秒，万一消费到第 8 秒时进程挂了，Offset 已经提交过了，重启后消息就丢了。所以生产环境我建议设置 enable.auto.commit=false，改为手动提交。

auto.offset.reset 决定消费组没有 Offset 记录时从哪开始消费。earliest 表示从分区最早的消息开始，latest 表示只消费新消息。如果你用全新的消费组去消费一个已存在的 Topic，又想拿到历史数据，就设 earliest；如果只关心新数据，设 latest。

max.poll.records 是单次 poll 最多拉取多少条消息。默认是 500 条，值太大单次处理时间过长，可能触发 max.poll.interval.ms 超时导致消费者被踢出组。值太小又频繁拉取，吞吐低。一般建议 200~500 条之间，要根据自己的单条处理耗时来试。

4.3 消费者完整代码：手动提交 Offset 才是正道

下面这段是消费者的完整实现，我特意关闭了自动提交，用的 commitSync() 同步提交：

java复制import org.apache.kafka.clients.consumer.*;
import org.apache.kafka.common.serialization.StringDeserializer;

import java.time.Duration;
import java.util.Collections;
import java.util.Properties;

public class OrderConsumer {

    public static void main(String[] args) {
        Properties props = new Properties();
        props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
        props.put(ConsumerConfig.GROUP_ID_CONFIG, "order-group");
        props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
        props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
        // 关闭自动提交，改为手动提交
        props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "false");
        props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
        props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, 500);

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

        // 订阅 orders 主题
        consumer.subscribe(Collections.singletonList("orders"));

        try {
            while (true) {
                // 拉取消息，1 秒超时
                ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000));
                for (ConsumerRecord<String, String> record : records) {
                    // 这里就是实际的业务处理逻辑
                    System.out.printf("处理订单: partition=%d, offset=%d, key=%s, value=%s%n",
                            record.partition(), record.offset(), record.key(), record.value());

                    // 模拟库存扣减等耗时操作
                    Thread.sleep(5);
                }
                // 处理完一批消息后，同步提交 Offset
                consumer.commitSync();
                System.out.printf("本批次消费并提交完成，共 %d 条%n", records.count());
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            consumer.close();
        }
    }
}

手动提交还有两种方式，commitSync() 和 commitAsync()，我一般用 commitSync()，因为同步提交失败会抛出异常，方便感知问题；commitAsync() 是异步提交，不阻塞主线程，吞吐更高，但失败不会自动重试，加上回调函数处理失败逻辑也可以。网上很多例子为了演示简单用 commitSync()，生产环境如果处理量大、对延迟敏感，可以改用 commitAsync() 配合定时同步提交。

这里还有一个很重要的工程实践：先处理业务逻辑，再提交 Offset。如果先提交再处理，处理失败重启后消息就丢了；如果先处理再提交，处理成功但提交失败，重启后会重复消费。所以你要根据业务选：能容忍重复就先用后提交，不能容忍丢就处理后提交。

4.4 重复消费和数据丢失的防范思路

重复消费和数据丢失，本质是 Offset 和业务处理的顺序问题。

如果业务处理完消息还没提交 Offset 就崩溃，重启后会从旧 Offset 开始，这条消息会被再处理一次，这就是重复消费。要防重复消费，最靠谱的办法不是靠 Kafka，而是在业务层做幂等。比如处理订单消息时，先查订单状态，如果已经是“已处理”就跳过；或者在数据库里用唯一索引，重复插入直接报错，捕获即可。

而数据丢失最容易发生在自动提交场景，比如处理超时、进程被 kill -9。我的建议是生产环境统一手动提交，并且把关键逻辑打日志，万一出问题能靠日志重建。

5. 完整运行示例：从零跑通整个生产者-消费者链路

5.1 启动顺序与验证步骤

前面的代码写完，运行步骤我帮你理一下，第一次跑的人跟着做不会乱。

第一步，确认 Kafka 已经启动。执行 kafka-topics.sh --list --bootstrap-server localhost:9092，能看到 orders 主题就算成功。

第二步，运行 OrderProducer 主类。控制台会输出每条消息的发送结果，包括分区号和偏移量。100 条消息发完后，程序自动退出。

第三步，运行 OrderConsumer 主类。控制台会开始打印消费到的消息，格式类似：

code复制处理订单: partition=0, offset=0, key=user-0, value={"orderId":"O1715000000000-0","productId":"p0","amount":0,"userId":0}

如果生产者已经发完消息再启动消费者，因为 auto.offset.reset=earliest，消费者也能消费到之前的历史消息。这就是这个参数在起作用。

想观察消费组和 Offset 的变化，可以用命令行工具：

bash复制kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group order-group

输出里会显示每个分区的当前 Offset、Log End Offset、Lag（堆积量）。Lag 为 0 表示消费完了，Lag 很大说明消费速度跟不上生产速度，这是排查延迟问题的关键指标。

5.2 分区数与消费者线程数的匹配关系

很多新手会问：消费者起多少个线程合适？答案不是越多越好，Kafka 的消费并行度受分区数限制。

同一个消费组内，一个分区同一时刻只能被一个消费者实例消费。所以如果你只有一个分区，起 10 个消费者线程也是白搭，只有 1 个线程在干活，其他 9 个闲着。消费者线程数超过分区数时，超出的部分没有任何分区可分配。

所以正确的做法是：先确定分区数，再确定消费者实例数。分区数越多，消费者并行度越高。但分区数也不是越大越好，每个分区会有额外的文件句柄和元数据开销。我的经验是：结合目标吞吐量来算，单个分区每秒能扛大概几千到上万条消息（跟消息大小、硬件有关），你根据业务高峰期每秒消息数除以单分区吞吐，就能估算出需要的分区数。比如每秒需要处理 5 万条，单分区扛 1 万条，分区数至少 5 个，留点余量可以设 8 到 10 个。

5.3 从 String 到 JSON：消息体序列化的演进

上面示例里消息体是手拼的 JSON 字符串，方便演示。但真实项目里，消息体肯定是一个对象，比如 OrderMessage。这时候有两个选择。

选择一：使用 JSON 序列化器。项目中引入 Gson 或 Jackson，发送前手动把对象转成 JSON 字符串，消费端再解析回来。这种方式实现简单，消息可读性好，调试方便。缺点是 JSON 体积相对大，还有版本变更时字段兼容性要自己控制。

选择二：使用 Avro 配合 Schema Registry。Avro 是二进制序列化格式，体积小、序列化速度快，还带 Schema 演进机制。生产环境的数据管道项目很多用这个方案，但需要额外部署 Schema Registry，复杂度高不少。

我的建议是：中小项目先用 JSON 方案别犹豫，先跑通业务再去优化序列化层。等你有几千万条消息的规模，再考虑 Avro 也不迟。

6. 常见问题与排查技巧实录

6.1 消息延迟高，从哪里开始查

消息延迟高是 Kafka 生产环境里最常见的烦恼。从我的经验来看，先定位延迟发生在哪个环节，比盲目调参重要得多。

第一个环节是生产端延迟。检查 linger.ms 是不是太小，比如 0，那生产者几乎不聚合，每条消息都单独发，小消息场景下网络往返开销很大。这时可以把 linger.ms 调到 5~10，batch.size 调大，吞吐会明显改善。

第二个环节是消费端延迟。用 kafka-consumer-groups.sh 看消费者组的 Lag，如果 Lag 持续增长，说明消费速度跟不上生产速度。先看 max.poll.records 是不是太大，导致单次处理周期过长；再看业务处理逻辑有没有慢操作，比如查数据库、调外部接口。

第三个环节是 broker 端延迟。如果所有消费者的 Lag 都在涨，但消费者本身没有问题，那要查 broker 的磁盘 IO 和网络带宽。Kafka 对磁盘顺序读写的依赖很高，机械硬盘和 SSD 的差距很大，如果日志目录所在的磁盘 IO 打满，整个集群都会跟着变慢。

6.2 常见的 JVM 和编译报错怎么处理

很多 Java 开发用 Kafka 时遇到的不是 Kafka 本身的问题，而是 JVM 和编译环境的坑。

java.lang.OutOfMemoryError: Insufficient memory 出现时，一般是堆内存不足或者无法分配足够的本机内存。先检查 KAFKA_HEAP_OPTS 环境变量，本地测试可以设 export KAFKA_HEAP_OPTS="-Xmx512m -Xms512m"，如果数据量很大再调大。同时确认系统可用物理内存，Kafka broker 启动时如果有多个进程抢占内存，也容易触发这个问题。

“源发行版 17 需要目标发行版 17”这个警告，本质是 IDEA 里编译级别和 JDK 版本不匹配。解决办法：File -> Project Structure -> Project 里把 SDK 设为 17，Project language level 设为 17；再到 Settings -> Build, Execution, Deployment -> Compiler -> Java Compiler 里确认 Target bytecode version 是 17。改完重新编译，警告消失。

还有 Lombok 相关的警告，比如“you aren't using a compiler supported by lombok”。大多是 IDE 内置编译器版本和 Lombok 版本不兼容。升级 Lombok 版本，或者确认 IDEA 的 Annotation Processing 已经开启，一般都能解决。

6.3 消费者频繁掉线、Rebalance 停不下怎么办

消费组频繁 Rebalance 是个让人头大的问题，表现就是消费暂停、消息处理被反复打断。

最常见的原因是消费者处理消息耗时过长，超过了 max.poll.interval.ms 默认的 5 分钟。消费者在两次 poll() 之间的间隔如果超过这个时间，Kafka 会认为消费者已经挂了，触发 Rebalance，把它踢出组。解决办法是调整两个参数：调大 max.poll.interval.ms 给业务处理留出时间；或者调小 max.poll.records 减少单次拉取量。

另一个原因是消费者心跳超时。session.timeout.ms 默认是 45 秒，heartbeat.interval.ms 默认是 3 秒，如果 GC 停顿或者网络抖动导致心跳没发出去，broker 认为消费者死掉，也会触发 Rebalance。这种情况可以适当调大 session.timeout.ms，但要注意调太大会延迟故障感知时间。

还有一个隐藏坑：消费者的 poll() 逻辑里如果写了死循环或者阻塞方法，超过了 max.poll.interval.ms，Rebalance 会一直触发。我排查过一个案例，就是开发者在处理消息时调了一个会长时间阻塞的外部接口，造成周期性 Rebalance，浪费了大半天才定位到。

6.4 Kafka 集群宕机时的基本处理思路

单机版 Kafka 宕机，重启就是；集群版宕机，处理思路就完全不一样了。

Kafka 集群里一个 broker 挂了，只要这个 broker 不是某些 Partition 的 leader，或者这些 Partition 在其他 broker 上有完整的 ISR 副本，系统通常还能继续工作。broker 挂掉后，控制器负责重新选举 leader，这个过程会短暂影响该 broker 上 leader 分区的写入，但不会影响整个集群。

如果你的集群在 broker 挂掉后出现大量生产失败，先检查 acks 配置和 ISR 情况。acks=all 时，如果 leader 所在的 broker 挂了，ISR 里的 follower 会接管，生产端可能因为短暂的 leader 选举报错，这时生产端的 retries 配置就发挥作用了。消费者端一般不感知 broker 故障，因为消费者会自动感知新的 leader。

还要关注硬盘。磁盘写满导致 broker 崩溃，比网络问题更隐蔽。Kafka 不会自动清理消费完的消息，只按保留时间或大小删除。如果某个 Topic 的积压量巨大，磁盘很容易被打满。我的习惯是给磁盘使用率设监控告警，超过 70% 就关注，超过 85% 就考虑清理旧日志或扩容。

7. 面试高频考点：照着这些准备基本够用

这个示例做完，顺便聊几句面试。Java 和 Kafka 的面试题高频区，跟生产者-消费者强相关的点我总结成了一张表：

面试的时候，光背概念不够，最好能把代码里的参数含义讲清楚，再结合一个你自己的真实案例。我在面试应届生时，最怕的是说“我配过 acks=all”但说不清为什么选 all 而不是 0。你把上面的代码跑通一遍，理解了每个参数背后的权衡，面试时聊起来会非常自然。

还有几个相关的 Java 基础点，像“生产者-消费者模式在 Java 里怎么用 wait/notify 实现”，这是另一个话题，但本质思路跟 Kafka 是相通的：解耦、缓冲、异步。区别在于 Kafka 把这个模式扩展到了分布式环境，用网络和磁盘做缓冲。

8. 一点实操总结

最后说点我自己在实践中的体会。这个生产者-消费者示例，代码量不大，但背后牵扯出的知识面很宽，从 JVM 配置到参数调优，从分区策略到消费组协调，每一块都有很多值得深挖的地方。如果你是自己学习，建议不要只把代码跑通就完事，一定要自己动手改参数，观察改动前后的行为差异。

比如你故意把 acks 改成 0，然后关掉 Kafka broker 重启，再对比之前 acks=all 的表现，很快你就能理解可靠性这几个档位到底差在哪。再比如给消费者加一段 Thread.sleep(5000)，看着 kafka-consumer-groups.sh 里 Lag 的变化，你会比看一百篇文章都记得牢。

另外一个提醒：如果你想把这个示例往生产上搬，先评估好幂等性设计、监控告警和日志记录这三件事。Kafka 本身再稳，业务层如果没有兜底，关键时刻照样会出大问题。先把单机链路跑通，再逐步往集群、高可用方向演进，这条路是最稳妥的。