要上进的柯同学记得刚接手一个新项目时，业务方丢过来一句话：“下单成功之后同步通知积分和短信就行。”我最初老老实实写了两个 HTTP 调用，线上跑了两周就开始折磨人：短信服务一抖动，下单接口跟着变慢；积分服务升级，订单系统还要跟着发版。后来决定把 Spring Boot 项目接入 Apache Kafka，把“下单成功”变成一个事件，由各下游服务自己订阅。这个改动看起来简单，真正做扎实却踩了不少坑。
这篇文章不是讲 Hello World 级别怎么调通，而是把 Spring Boot 与 Apache Kafka 集成时真正需要决策的事情讲清楚：用哪种封装方式、生产端怎么配才能不丢消息、消费端怎么设计才能扛得住重复消费、出了问题怎么排查。内容适合已经会用 Spring Boot 写接口，想在生产环境稳定使用 Kafka 的后端开发工程师。需要说明，这里说的“集成”不只是 spring-kafka 依赖加进去，而是指从依赖选型、配置参数、发送与消费代码，到上线后的监控告警一整条链路。
1. 集成之前先想清楚：Kafka 在项目里到底承担什么角色
1.1 从一次“HTTP 连环调用”聊起
很多团队第一次引入 Kafka，是因为受够了接口之间互相等待。我参与过的一个订单系统特别典型：下单成功后，订单服务需要调用积分服务加积分、调用短信服务发通知、调用搜索服务同步索引。这三个调用任何一个超时，下单接口就被拉慢，最坏情况下数据库连接被占满，整条交易链路直接雪崩。
后来把“下单成功”改成事件后，订单服务只负责把事件发到 Kafka，积分、短信、搜索各自订阅。这样订单服务不再关心下游状态，下游也不影响订单主链路。这种用法就是“异步解耦”。
除了异步解耦，Kafka 还经常承担两个角色：流量削峰和事件驱动。秒杀场景里，先把请求写入 Kafka，后端服务按自己的消费能力慢慢处理，不会瞬时间压垮数据库；事件驱动则是把系统里发生的业务变更变成一串事件流，比如“库存变更”“用户状态变更”，其他模块监听这些事件做响应，让业务模块之间的关系从“调用别人”变成“响应发生了什么”。
1.2 什么场景不该硬上 Kafka
Kafka 不是万能的。延迟队列、定时任务这类需求不要指望 Kafka 原生支持，虽然可以靠预留延迟字段或额外轮询实现，但这属于“歪着用”，容易把自己绕晕。如果业务要求强一致的同步结果，比如支付后必须马上查到余额变更，那最好还是走接口调用或分布式事务方案，Kafka 的最终一致性并不适合所有场景。
另一个容易被忽视的问题是运维成本。引入 Kafka 意味着要维护 broker 集群，无论是 ZooKeeper 模式还是 KRaft 模式，都需要额外的人力。如果团队规模不大，消息量也一般，RabbitMQ 可能是更轻的选择。Kafka 的核心优势是高吞吐、日志保留、重放历史数据，这些能力不是所有项目都需要的。
1.3 Kafka 和 RabbitMQ 的取舍
简单给个结论：如果只为了给 Spring Boot 项目异步解耦，吞吐要求一般、希望开发简单，RabbitMQ 更容易上手；如果团队已经接受事件驱动思想，业务量增长快，或者需要保留一段时间的事件流、能重放历史数据，Kafka 更合适。
提示：选型不是技术比拼，而是看团队运维水平和业务约束。引入 Kafka 的同时，意味着你需要额外运维一套集群，这个成本要提前算进去。
1.4 先理解 Topic、Partition、Offset 这三个核心概念
在动手写代码前，最好先把 Kafka 的最小模型搞清楚。Topic 是消息的分类，比如“订单事件”；Topic 内部被分成若干 Partition，每个 Partition 是一个有序日志文件；Offset 是消息在 Partition 中的位置。消息写入时先写入某个 Partition，消费者按 Offset 顺序读取。这个模型决定了后面所有可靠性设计和并发设计。
很多新手不理解为什么 Kafka 吞吐高，核心就在 Partition。分区让消息可以分散到多个 broker 上存储，消费者也可以并行读取不同分区。但分区又带来顺序性和消费组的概念，后面消费端配置部分会重点展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 依赖选型：Spring Kafka 还是 Spring Cloud Stream，别再重复封装
2.1 它们与原生 Kafka Client 的关系
消息客户端与 Kafka Broker 通信靠的是原生库 kafka-clients，它负责网络连接、分区分配、offset 管理。Spring Kafka 是对 kafka-clients 的封装，提供了 KafkaTemplate、@KafkaListener、KafkaAdmin 这些提升开发效率的工具。Spring Cloud Stream 又在 Spring Kafka 外面包了一层 Binder 抽象，目标是屏蔽不同 MQ 的差异。
我见过一些团队为了“不引入框架”，直接用 kafka-clients 写循环 poll 和 while(true) 消费。业务简单时没问题，一旦要处理重试、offset 提交、死信队列，代码会迅速失控。Spring Kafka 的价值不是魔法，而是把这些分布式客户端编程中容易出错的细节规范化，同时保留直接访问底层 KafkaConsumer 的能力。
2.2 版本兼容：最容易被忽视的环节
Spring Kafka 自身依赖 kafka-clients，Spring Boot 的 BOM 会统一管理版本。实际项目里最常见的问题不是 Broke