团队最近在做系统拆分，需要引入消息队列。一开始同事提了一句"用 Kafka 吧"，我问他为什么，他说"大家都用啊"。于是花时间把主流的几个 MQ 过了一遍，记录一下选型的心路历程。
消息队列是什么
说白了就是把"同步调用"变成"异步发送"。以前是 A 调 B，B 返回结果 A 才继续——同步、耦合、B 挂了 A 也废。加一层 MQ 之后：A 发消息到队列，B 什么时候消费是 B 的事，A 不用等。
这就带来了三大好处：解耦、削峰、异步。
三个选手
项目里主要考察的是 RabbitMQ、Kafka 和 RocketMQ。各有各的脾气。
消息可靠性高 ──────────────── 吞吐量大
│ │
RabbitMQ Kafka/RocketMQ
│ │
适合业务消息 适合大数据/日志
RabbitMQ — Erlang 写的，社区最老牌，功能很齐全。它的核心概念是 Exchange 和 Queue，消息先到 Exchange，Exchange 根据路由规则投递给 Queue。
延迟消息要装插件（rabbitmq_delayed_message_exchange），这个有点烦，不过大部分场景够用了。我本地装了个试了下，管理界面挺直观，能看到每秒消息量、队列积压情况。就是事务消息不支持，要自己实现。
Kafka — 天生就是为高吞吐设计的。消息存在文件里，顺序写磁盘，速度比想象中快很多。给所有消息编号（offset），消费者自己维护消费到哪了，想回头读也能重读。
Kafka 的设计思路是"不要把消息当宝贝，适当丢点没事"，所以传统业务系统用它做核心链路要三思。延时消息也不自带，要绕一下。另外它依赖 ZooKeeper（新版逐步去掉了），部署运维相对重。
RocketMQ — 阿里开源，Java 写的。如果你团队是 Java 技术栈而且消息可靠性要求很高，这个可能是最合适的。事务消息原生支持，延迟消息也自带，这些在电商场景很实用。
缺点嘛——生态比 Kafka 小，社区活跃度一般，碰到问题搜出来的讨论不太多。还有它的网管面板有点简陋，比 RabbitMQ 的管理界面差不少。
怎么选
| 场景 | 推荐 |
|---|---|
| 业务解耦，消息不能丢 | RabbitMQ 或 RocketMQ |
| 实时数据管道，海量日志 | Kafka |
| Java 团队，事务消息需求 | RocketMQ |
| 小团队，运维成本敏感 | RabbitMQ |
我们最后选了 RabbitMQ，因为团队人不多，部署简单，而且消息量增长速度可预见——一年内每天撑死几十万条。Kafka 是屠龙刀，但我们眼下的需求切菜刀就够了。
总结
选型最怕的就是"别人都这么用"。没有一个 MQ 是万能药，合适的场景选合适的工具，别为了炫技给自己加维护负担。
评论