消息队列选型终极对决：Kafka / RabbitMQ / Pulsar 的场景边界

日志传输用了 Kafka，结果团队顺手把订单消息也塞了进去，后来发现消息重试、乱序、补偿链路一团糟；交易链路用了 RabbitMQ，到了大促夜里队列积压、磁盘告警、消费雪崩一起爆；看上了 Pulsar 的存储计算分离和多租户，最后却被 BookKeeper、分层存储和运维复杂度教育了一遍。

真正的问题从来不是“哪个 MQ 更强”，而是你是否把它放在了正确的位置。本文不做参数罗列，而是站在事件驱动架构和生产工程的视角，把 Kafka、RabbitMQ、Pulsar 的能力边界、架构本质、工程取舍和落地代码一次讲透。

一、先说结论：没有最强的 MQ，只有最合适的事件链路

如果你只想先拿到答案，可以记住下面这张结论表。

一句话总结：

• Kafka更像分布式事件日志平台。
• RabbitMQ更像业务消息路由器。
• Pulsar更像面向平台化场景的下一代消息底座。

二、为什么很多团队会选错：把“事件流”当成“业务消息”

选型错误，通常不是因为不懂产品，而是因为没有先把消息分类。

在事件驱动架构里，至少要区分四类消息：

1. 领域事件
   例如OrderCreated、PaymentSucceeded、InventoryReserved。关注的是业务状态变化。

2. 集成事件
   例如订单系统通知积分系统、营销系统、履约系统。关注的是跨系统解耦。

3. 命令消息
   例如“请立即发送短信”“请为订单创建履约任务”。关注的是明确动作和执行结果。

4. 数据流事件
   例如点击流、埋点、日志、数据库变更流。关注的是高吞吐、可重放、可分析。

很多事故，根因都在这里：

• 用适合数据流的平台承载强业务确认消息。
• 用适合业务路由的平台承载海量堆积流式数据。
• 用适合平台化治理的架构，去服务一个只有 3 人维护的小团队。

所以，消息队列选型的第一原则不是性能，而是先识别消息语义。

三、事件驱动架构下，MQ 到底承担什么角色

很多文章一上来就在比 TPS、延迟和副本数，但在架构层面，MQ 的角色至少有五种：

1. 解耦
   上游只发布事件，不感知下游的存在和处理速度。

2. 削峰
   把同步链路变成异步链路，用队列吸收突发流量。

3. 广播
   一个业务事件触发多个订阅者并行处理。

4. 重放
   支持回溯历史事件，便于补数、审计、重建状态。

5. 平台化治理
   在大规模系统中统一做租户隔离、配额、审计、权限和观测。

这五种角色并不总是由同一个系统承担。

现实中的成熟架构，往往是组合拳：

• 交易链路用RabbitMQ
• 数据采集用Kafka
• 多业务线统一事件总线用Pulsar
• 核心数据一致性靠Outbox + CDC

四、底层原理决定了上层边界

4.1 Kafka：本质是分布式 Commit Log

Kafka 的核心不是“队列”，而是可持久化、可分区、可重放的提交日志。

它的关键特征：

• Producer 以追加写方式写入分区日志。
• Broker 基本不维护每条消息的消费状态。
• Consumer 通过 offset 自行声明“我消费到哪里了”。
• 顺序写盘、批量发送、零拷贝决定了它擅长高吞吐。

这带来三个天然优势：

1. 吞吐极高
   尤其适合日志、埋点、CDC、流式 ETL。

2. 消息可回放
   这对补数、回溯、离线重建非常有价值。

3. 生态成熟
   和 Flink、Spark、Debezium、Connect 这类流式组件天然适配。

但也带来天然限制：

• Kafka 不是按“单条消息生命周期”设计的。
• 它不擅长精细化的逐条确认、退回、路由。
• 它的有序性是分区内有序，不是全局有序。
• 如果业务需要复杂重试、死信治理、延迟投递，通常要额外补工程。

所以 Kafka 适合“事件流”，不天然适合“事务型业务指令总线”。

4.2 RabbitMQ：本质是智能路由代理

RabbitMQ 的核心不是“存储”，而是路由。

它的强项在于：

• Exchange 类型丰富：Direct、Topic、Fanout、Headers。
• Queue 语义成熟：ACK、NACK、TTL、DLX、优先级、延迟插件。
• 更适合一条业务消息从发布到处理完成的完整生命周期控制。

这意味着 RabbitMQ 非常适合：

• 订单创建后通知多个业务方
• 支付结果回调
• 短信、邮件、站内信异步发送
• 需要重试、死信、延迟取消的业务任务

但 RabbitMQ 的短板也很明显：

• 大量消息长时间积压不是它的优势区间。
• 磁盘压力、内存压力和镜像复制会迅速抬高成本。
• 当消费变慢时，队列积压会连锁影响整个集群。

它是优秀的业务消息总线，不是天然的海量事件存储系统。

4.3 Pulsar：本质是面向平台化的分层消息系统

Pulsar 的关键设计是Broker 无状态 + BookKeeper 持久化存储。

这意味着：

• Broker 可快速扩缩容。
• 存储和计算解耦，更适合云原生弹性。
• 多租户、命名空间、配额、分层存储非常强。

它适合的典型场景：

• 平台团队统一承载多个业务域的消息流量
• IoT 设备接入与设备级隔离
• 跨机房、多租户、冷热数据分层
• 同时存在流式消费与队列式消费的复杂平台

但代价也很现实：

• 组件更多，理解门槛更高
• BookKeeper 调优难度高于传统 MQ
• 小团队缺少经验时，问题定位成本很高

Pulsar 不是不能用，而是要先确认：你需要的是它的能力，还是只是在为未来想象中的复杂度买单。

五、一张表看清 Kafka、RabbitMQ、Pulsar 的核心差异

如果你需要一个更直白的判断标准：

• 数据流优先 Kafka
• 业务消息优先 RabbitMQ
• 平台化统一底座优先 Pulsar

六、真正能落地的选型方法：先看业务约束，再选中间件

不要先问“选哪个 MQ”，而要先问下面八个问题：

6.1 消息是“命令”还是“事件”

• 如果是“请你去做某件事”，更偏命令消息，RabbitMQ 更顺手。
• 如果是“某件事已经发生”，更偏事件流，Kafka/Pulsar 更合适。

6.2 需要多强的一致性

• 只要最终一致即可：多数 MQ 都能承载。
• 必须确保数据库提交和消息投递一起成功：重点不在 MQ，而在Outbox。

6.3 是否需要回放历史

• 需要补数、审计、重新计算画像、回刷风控规则：Kafka/Pulsar 更合适。
• 不需要长期保留，只关心消费完成：RabbitMQ 更自然。

6.4 是否存在海量堆积

• 日志、IoT、埋点、CDC 往往天然有堆积需求。
• 订单、支付这类业务消息通常更关注及时处理，不适合长期堆积。

6.5 路由规则复杂吗

• 一个消息扇出多个下游，且每个下游规则不一样：RabbitMQ 更强。
• 只是按 Topic 分发：Kafka/Pulsar 足够。

6.6 团队是否有运维能力

• 没有专职中间件平台团队，尽量避免把 Pulsar 当默认选项。
• 团队熟悉 Kafka 生态，流式链路优先 Kafka。

6.7 是否要求多租户隔离

• SaaS 平台、IoT 平台、内部多业务线共享底座时，Pulsar 的租户体系优势明显。

6.8 上下游是否能接受异步补偿

• 如果业务不能容忍“消息可能稍后重试”，要重新审视边界，也许不该直接异步化。

七、架构师最该警惕的五个误区

7.1 误区一：把 Kafka 当事务消息队列

Kafka 可以做到高可靠，但它并不天然等于“适合所有交易消息”。

问题通常出在：

• 没有正确配置acks=all
• 没启用幂等 Producer
• 消费端没有做幂等
• 顺序和重试策略设计不完整
• 误以为“写进 Kafka”就等于“业务完成”

7.2 误区二：用 RabbitMQ 扛日志洪峰

RabbitMQ 不是不能吞吐高，而是它在持续高写入 + 长堆积 + 慢消费的组合下成本很高。

如果你的场景是：

• 每秒数十万到百万条埋点
• 下游可能延迟消费
• 需要按时间回放

那么 RabbitMQ 大概率不是最优解。

7.3 误区三：因为“未来可能复杂”而上 Pulsar

很多团队并不是真的有多租户、分层存储、Broker 弹性扩缩容需求，只是被概念吸引。

架构设计最忌讳的不是技术落后，而是超前复杂化。

7.4 误区四：以为 MQ 能解决分布式事务

MQ 只能帮助你做异步解耦和最终一致性，不能自动解决：

• 本地事务和消息投递原子性
• 幂等
• 重复消费
• 下游业务回滚

真正的关键机制通常是：

• Outbox Pattern
• CDC
• 幂等键
• 补偿状态机

7.5 误区五：只做消息发送，不做治理闭环

生产上最容易出事故的，不是“发不出去”，而是：

• 发出去了但没人消费
• 消费失败无限重试
• 积压没人发现
• 死信堆满没有补偿流程
• 消息格式升级导致新老消费者不兼容

MQ 不是 SDK，它是一个需要治理体系的基础设施。

八、生产级事件驱动架构应该怎么设计

8.1 一个推荐的分层模型