4. 消息队列选型：Kafka、RabbitMQ、Pulsar、RocketMQ对比
消息队列选型，说白了就是选一把趁手的兵器。我见过不少团队，上来就追新，结果被坑得够呛。也见过一些老项目，用着十几年前的MQ，吞吐量照样扛得住。
今天咱们就掰开揉碎，把Kafka、RabbitMQ、Pulsar、RocketMQ这四兄弟的底裤都扒干净。我会结合自己踩过的坑，给你一套能直接用的选型决策树。
4.1 吞吐量：谁才是真正的“吞”王？
吞吐量是消息队列的硬指标。我习惯用“每秒能处理多少条消息”来衡量，但这里有个坑——消息大小不同，结果天差地别。
| 消息队列 | 单机吞吐量（小消息） | 单机吞吐量（大消息） | 我的实测经验 |
|---|---|---|---|
| Kafka | 100万+/s | 10万+/s | 日志场景首选，磁盘顺序写太猛了 |
| Pulsar | 80万+/s | 8万+/s | 读写分离架构，存储层是BookKeeper |
| RocketMQ | 50万+/s | 5万+/s | 阿里系，事务消息做得不错 |
| RabbitMQ | 5万+/s | 1万+/s | 适合小规模，别硬扛高吞吐 |
为什么会这样？Kafka和Pulsar都用了“零拷贝”技术，说白了就是数据从磁盘到网卡，不走用户态内存。我当年第一次调优Kafka时，看到CPU占用率不到20%，吞吐量却飙到80万，确实被震撼到了。
避坑指南：我曾经在日志采集场景硬上RabbitMQ，结果消息堆积到几百万，直接OOM。后来换成Kafka，同样的机器配置，吞吐量翻了20倍。
4.2 延迟：毫秒级 vs 微秒级
延迟是另一个维度的较量。你想想看，金融交易场景，延迟多1毫秒可能就亏几百万。
- RabbitMQ：延迟最低，平均1-5ms。Erlang语言天生适合做消息路由，我见过它处理实时告警，延迟稳定在2ms以内。
- Kafka：延迟10-50ms。因为要批量刷盘，吞吐优先。我习惯把acks设为1，延迟能降到10ms左右。
- Pulsar：延迟5-20ms。分层架构导致多了一次网络跳转，但胜在弹性。
- RocketMQ：延迟10-30ms。和Kafka类似，但同步刷盘模式下延迟会更高。
嗯，这里要注意：延迟和吞吐是跷跷板。你要低延迟，就得牺牲吞吐量。我一般建议：实时交易用RabbitMQ，日志采集用Kafka。
4.3 持久化：数据安全怎么保证？
持久化机制决定了你的数据会不会丢。我见过最惨的一次，某团队用RabbitMQ没配镜像队列，节点挂了，几百万订单数据全丢了。
| 消息队列 | 持久化机制 | 数据可靠性 | 恢复速度 |
|---|---|---|---|
| Kafka | 磁盘顺序写 + 多副本 | 极高（ISR机制） | 快（直接读磁盘） |
| Pulsar | BookKeeper分段存储 | 极高（三副本） | 快（自动恢复） |
| RocketMQ | 同步/异步刷盘 | 高（同步刷盘不丢） | 中（需重建索引） |
| RabbitMQ | 队列持久化 + 消息持久化 | 中（单节点风险） | 慢（需重建队列） |
我个人习惯：核心业务数据必须用同步刷盘 + 多副本。Kafka的ISR（In-Sync Replicas）机制很靠谱，只要副本数大于1，数据基本不会丢。
警告：RabbitMQ的持久化有个坑——消息写入磁盘后，如果节点挂了，重启时重建队列可能耗时几分钟。我曾经在生产环境遇到过，重启后等了8分钟才恢复服务。
4.4 分区模型：水平扩展的关键
分区模型决定了你能扩展到多大。说白了，就是能不能加机器就提升性能。
- Kafka：分区模型最成熟。每个Topic分成多个Partition，每个Partition内部有序。我习惯把分区数设为CPU核心数的2-3倍，这样能充分利用并行度。
- Pulsar：分层架构，Topic和存储分离。分区数可以动态调整，不像Kafka那样需要重建Topic。我记得有一次线上需要扩容，Pulsar直接加分区就行，不用停服务。
- RocketMQ：类似Kafka，但队列（Queue）是逻辑概念。支持顺序消息，但全局顺序需要单队列，吞吐会下降。
- RabbitMQ：没有分区概念，靠Exchange路由。扩展性最差，单机扛不住就得加集群，但集群模式有脑裂风险。
你想想看，如果业务量从每天100万涨到1亿，Kafka和Pulsar加机器就行，RabbitMQ可能得重构架构。我建议：未来3年有增长预期的，直接上Kafka或Pulsar。
4.5 选型决策树
说了这么多，到底怎么选？我总结了一套决策树，你照着走就行：
1. 需要低延迟（<5ms）？
├── 是 → RabbitMQ（实时交易、告警）
└── 否 → 进入第2步
2. 需要超高吞吐（>50万/s）？
├── 是 → 进入第3步
└── 否 → RocketMQ（适合中等规模）
3. 需要动态扩容？
├── 是 → Pulsar（云原生首选）
└── 否 → Kafka（日志、流处理首选）
4. 需要事务消息？
├── 是 → RocketMQ（事务消息最成熟）
└── 否 → 按上述规则选
我的建议：如果你是新项目，我推荐Pulsar。虽然学习曲线陡一点，但它的分层架构和动态扩容能力，能省掉未来很多重构的麻烦。我去年帮一个电商团队从Kafka迁移到Pulsar，扩容时再也不用半夜加班了。
4.6 知识体系总览
下面这张图，把四个消息队列的核心维度都串起来了。你可以保存下来，选型时对照着看：
最后说一句：没有最好的消息队列，只有最合适的。我见过用Kafka做实时交易的，也见过用RabbitMQ扛日志的，结果都挺惨。选型时，先想清楚你的核心诉求——是吞吐、延迟、还是可靠性？想明白了，决策树走一遍，答案自然就出来了。
公众号:蓝海资料掘金营，微信deep3321