Kafka 实战：从消息生产到消费，搞懂核心概念与避坑要点

消息队列是分布式系统的标配组件，而 Kafka 几乎是这个领域的默认选择。订单系统用它做异步解耦，日志系统用它做海量采集，实时计算用它做数据总线。但很多人在第一次用 Kafka 时都会踩同一个坑：把 Kafka 当成普通的“消息队列”来用，照着 RabbitMQ 的经验写代码，结果在分区、消费组、偏移量这几个概念上处处碰壁。本文从 Kafka 的核心模型讲起，讲清楚生产、存储、消费全链路的关键机制与避坑要点，帮你第一次就把 Kafka 用对。

一、Kafka 的核心模型：先理解 Topic、分区与副本

Kafka 的数据组织单位是 Topic，生产者往某个 Topic 写消息，消费者从某个 Topic 读消息。一个 Topic 由一个或多个分区（Partition）组成，分区是 Kafka 并行能力的来源：分区越多，同一时刻能并行写入和读取的吞吐就越高，但分区也不是越多越好，分区过多会增加 Broker 的文件句柄与元数据开销，Leader 选举和故障恢复也会变慢。一般建议从业务量出发，按“目标吞吐 / 单分区吞吐”估算，再留出 2 到 3 倍余量。

每个分区有多个副本（Replica），其中一个是 Leader，其余是 Follower。所有读写请求都只走 Leader，Follower 只负责从 Leader 同步数据。副本因子一般设为 3，配合 min.insync.replicas=2，可以在一台 Broker 宕机时仍然保证数据不丢。副本因子设为 1 虽然省磁盘，但任何一次磁盘故障都会直接丢数据，生产环境不要这样做。

消息在分区内是严格有序的，带同一个 Key 的消息会被固定发到同一个分区，这就是 Kafka 保证局部有序的机制。需要全局有序的场景只能用单分区 Topic，但代价是吞吐被限制在单个分区的水平上，是否值得要按业务权衡。

二、生产者：可靠性由三个参数决定

生产者的发送是异步的，send() 方法只是把消息放进本地缓冲区，由后台线程批量发送。批量发送是 Kafka 高吞吐的关键：batch.size 控制每批数据的大小，linger.ms 控制等待凑批的时间，两个参数配合可以把大量小消息合并成一次网络请求。延迟敏感的场景可以把 linger.ms 设为 0，吞吐优先的场景可以适当调大。

可靠性主要由 acks 参数决定。acks=0 是发送后不管，速度最快但可能丢消息；acks=1 是 Leader 落盘即确认，Follower 同步失败时仍可能丢；acks=all 是所有同步副本都落盘才确认，配合 min.insync.replicas 是最安全的组合，代价是延迟略高。对订单、支付这类不允许丢消息的场景，必须用 acks=all。

幂等生产者是另一个容易忽略的开关。开启 enable.idempotence=true 后，生产者会给每条消息分配单调递增的序列号，Broker 会去重因网络重试导致的重复消息。Kafka 3.0 之后这个开关默认就是开启的，如果你用的是老版本客户端，记得手动打开。

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());
// 关键可靠性配置：全部副本确认 + 开启幂等
props.put(ProducerConfig.ACKS_CONFIG, "all");
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);

Producer<String, String> producer = new KafkaProducer<>(props);
producer.send(new ProducerRecord<>("order-topic", "order-1001", "下单成功"));

三、消费者与消费组：偏移量是最容易出错的地方

消费者以消费组（Consumer Group）的形式工作：同一个组内的消费者共同分担一个 Topic 的分区，每个分区同一时刻只会被组内一个消费者消费；不同组之间互不干扰，各自维护自己的消费进度。消费进度就是偏移量（Offset），Kafka 把它存在内部的 __consumer_offsets Topic 里。

最常见的坑是自动提交偏移量。默认配置下消费者每 5 秒自动提交一次偏移量，如果处理逻辑在提交之后崩溃，重启后会从已提交的位置继续消费，中间未处理完的消息就丢了。正确的做法是关闭自动提交，在业务处理成功后再手动提交：

props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);
// 处理成功后手动同步提交
consumer.commitSync();

消费者的另一个关键参数是 max.poll.interval.ms，它规定了两次 poll 之间允许的最大间隔。如果单条消息处理耗时超过这个值，消费者会被判定为死亡并触发 Rebalance，分区会被重新分配给其他消费者。处理耗时较长的任务要么调大这个参数，要么把耗时操作拆成异步处理，不要让 poll 循环长时间停住。

四、Rebalance：理解它，才能减少它的影响

Rebalance 是 Kafka 保证分区分配均衡的机制：消费者加入、退出或崩溃时，都会触发一次 Rebalance，把分区重新分配。Rebalance 期间所有消费者都会暂停消费，频繁 Rebalance 会直接拖垮消费吞吐。

减少 Rebalance 影响有三个办法：第一，合理设置会话超时参数，session.timeout.ms 不要设得太小，避免一次短暂 GC 就被误判死亡；第二，使用静态成员身份（group.instance.id），让消费者重启后保持原来的身份，避免不必要的分区重分配；第三，消费逻辑保持幂等，即使 Rebalance 导致消息被重复消费，业务结果也不会出错。

五、消息会不会丢、会不会重：三张对照表

把“丢”和“重”的问题放在生产、存储、消费三个环节看：

• 生产环节：网络抖动导致发送失败——用 acks=all + 幂等生产者 + 业务重试解决。
• 存储环节：Broker 宕机——用副本因子 3 + min.insync.replicas=2 解决。
• 消费环节：处理成功但提交失败，或者提交成功但处理失败——用手动提交 + 消费幂等解决。

Kafka 只能保证“至少一次”投递，精确一次需要事务 API 配合，而且只对 Kafka 内部的读-处理-写链路有效。一旦消费端要写数据库，就必须靠业务层面的幂等键（比如用订单号做唯一索引）来兜底。指望 Kafka 一个人保证端到端精确一次，是不现实的。

六、上线前核对清单

• Topic 分区数是否按吞吐估算过，而不是随手写了个 3
• 副本因子是否为 3，min.insync.replicas 是否为 2
• 生产者 acks 是否为 all，幂等开关是否打开
• 消费者是否关闭自动提交，是否在业务成功后手动提交偏移量
• 消费处理是否幂等，max.poll.interval.ms 是否大于最长单条处理耗时
• 监控是否覆盖消费延迟（Lag）：Lag 持续增长是消费能力不足最直接的信号

总结

Kafka 的设计哲学是“把复杂留给自己，把简单留给用户”：分区带来并行，副本带来可靠，消费组带来弹性伸缩。但这份简单是有前提的——生产者要配对 acks，消费者要管好偏移量，业务层要做好幂等。理解 Topic、分区、副本、消费组、偏移量这五个概念，再对照上面的清单逐项核对，第一次用 Kafka 就能避开绝大多数生产事故。