第2章：主流消息中间件对比
说实话，每次有团队问我「该选哪个消息中间件」，我都觉得这是个送命题。不是技术难选，而是每个中间件都有自己的脾气。我见过不少项目，选型时看了一堆对比文章，结果上线后各种踩坑。
今天我就把 RabbitMQ、Kafka、RocketMQ、ActiveMQ、Pulsar 这五个主流选手，从架构到实战经验，掰开了讲清楚。嗯，这里要注意，没有银弹，只有最适合你场景的。
2.1 架构设计：各有各的套路
先看架构，这是决定性能上限和运维复杂度的根本。
| 中间件 | 核心架构 | 存储模型 | 我眼中的特点 |
|---|---|---|---|
| RabbitMQ | Erlang/OTP，Exchange-Binding-Queue | 内存+磁盘（惰性队列） | 路由灵活，但吞吐量有天花板 |
| Kafka | Leader-Follower，分区日志 | 磁盘顺序写，零拷贝 | 吞吐之王，但运维门槛高 |
| RocketMQ | NameServer-Broker，长轮询 | 混合存储（内存+文件） | 阿里系，事务消息是亮点 |
| ActiveMQ | JMS规范，KahaDB | 文件或JDBC | 老牌，但性能已落后 |
| Pulsar | BookKeeper+Broker分离 | 分层存储，计算存储分离 | 云原生，弹性好但生态弱 |
我个人习惯先看存储模型。Kafka 的磁盘顺序写，说白了就是利用了机械硬盘的物理特性——磁头不用来回跳。我在一个日志采集项目里，单机压到 100MB/s 写入，CPU 占用才 30%。但 RabbitMQ 如果消息堆积多了，内存一满就开始换页，性能直接跳水。
核心差异一句话：Kafka 和 Pulsar 是为「堆积」设计的，RabbitMQ 和 ActiveMQ 是为「低延迟路由」设计的。选错了，后面运维会哭。
2.2 特性对比：谁更懂你的业务
你想想看，消息中间件最怕什么？丢消息、重复消费、顺序乱掉。我们一个个来看。
2.2.1 消息可靠性
- RabbitMQ：支持 Publisher Confirm 和 Consumer Ack。我建议生产环境一定要开 Confirm 模式，否则网络闪断就可能丢消息。
- Kafka：通过 ISR（In-Sync Replicas）机制保证。acks=all 是最安全的，但延迟会高一些。我曾经遇到过副本同步慢导致生产阻塞的情况，嗯，分区数别设太多。
- RocketMQ：同步刷盘+同步复制，可靠性最高。适合金融场景，但性能会打折扣。
- ActiveMQ：支持持久化，但 KahaDB 在大量消息时容易出问题。我建议别用它做核心链路。
- Pulsar：BookKeeper 的副本机制，数据持久化到 Ledger，理论上不会丢。
2.2.2 顺序消息
说白了，顺序消息是个伪命题——全局顺序代价太高。Kafka 只能在分区内保证顺序，RocketMQ 通过 MessageQueue 选择器也能做到。RabbitMQ 嘛，单队列单消费者才能保证顺序，但吞吐量就上不去了。
避坑指南：我曾经在一个订单系统里，要求严格全局顺序。结果用了 Kafka 单分区，吞吐量只有 2000 TPS。后来改成业务主键哈希分区，每个分区内有序，问题就解决了。别追求全局顺序，那是反分布式设计的。
2.2.3 事务消息
RocketMQ 的事务消息是独门绝技。它通过半消息+回查机制，实现了分布式事务的最终一致性。Kafka 在 2.5 版本后也支持了事务，但用起来比较重。RabbitMQ 没有原生事务消息，得自己用本地消息表实现。
2.3 优缺点：没有完美的中间件
| 中间件 | 优点 | 缺点 |
|---|---|---|
| RabbitMQ | 路由灵活，管理界面好用，社区活跃 | 吞吐量有限（万级），消息堆积性能下降 |
| Kafka | 吞吐量极高（百万级），持久化好，生态丰富 | 运维复杂，消息重复概率高，延迟不稳定 |
| RocketMQ | 事务消息，低延迟，功能全面 | 社区不如 Kafka，文档中文为主 |
| ActiveMQ | JMS 标准，部署简单 | 性能差，社区停滞，不推荐新项目 |
| Pulsar | 计算存储分离，弹性伸缩，多租户 | 生态弱，学习曲线陡，BookKeeper 运维复杂 |
我记得有个朋友选型时，非要拿 RabbitMQ 做日志采集。结果每天几亿条日志，RabbitMQ 直接 OOM 了。后来换成 Kafka，同样的机器配置，稳如老狗。反过来，有个电商项目用 Kafka 做订单消息，结果因为消息重复导致库存扣了两次。嗯，选型真的要看场景。
2.4 实战选型建议
我一般会问三个问题：
- 你的吞吐量要求是多少？ 万级以下 RabbitMQ 够用，十万级以上考虑 Kafka 或 Pulsar。
- 消息丢失的容忍度？ 金融、交易场景选 RocketMQ 或 Kafka（acks=all）。日志、监控可以接受少量丢失。
- 团队运维能力如何？ 小团队选 RabbitMQ 或 RocketMQ，大厂可以上 Kafka 或 Pulsar。
警告：别被「云原生」这个词忽悠了。Pulsar 虽然架构先进，但 BookKeeper 的运维复杂度不是一般团队能搞定的。我见过一个团队上了 Pulsar，结果半年后因为 BookKeeper 磁盘故障恢复不了，数据全丢了。选型要务实。
2.5 小结
说白了，消息中间件选型没有标准答案。RabbitMQ 适合业务系统内部解耦，Kafka 适合大数据管道，RocketMQ 适合阿里系生态，ActiveMQ 建议放弃，Pulsar 适合有运维能力的云原生团队。
我个人习惯是：先确定业务场景，再画架构图，最后做压测。别光看网上的对比文章，自己跑一遍压测，心里才有底。下一章我会详细讲 Kafka 的架构和实战，到时候咱们再聊。