消息队列选型，我踩过的几个坑

做后端这几年，消息队列换过三回。第一家公司用 RabbitMQ，第二家用 Kafka，现在这摊业务自己在维护 RocketMQ。每次换都要跟人解释一遍为什么，干脆写下来。

先别急着选框架，想清楚你为什么要用 MQ

很多人选型是先看哪个火，再往里塞业务。结果把 MQ 用成了摆设，或者把简单的同步调用拆成异步，反而多了个要运维的东西。

我见过最离谱的用法，是两个服务之间明明直连就能搞定，硬中间插个队列，美其名曰"解耦"。解是解了，但消息丢了、积压了、重复了，排查起来多一层跳板。先用不用得上 MQ，比用哪个 MQ 重要得多。

四个维度，按你的业务排序

吞吐量、可靠性、生态成熟度、团队熟悉程度，这四样没有全能的，你得知道自己最缺哪个。

如果业务就是削峰填谷，几万 TPS 起步，Kafka 基本没得选。它的顺序写盘和页缓存机制就是为高吞吐设计的，单机几十万条消息很轻松。代价是配置项多，副本机制、分区策略、消费者组，新手上手容易翻车。

如果追求功能完整、路由灵活，RabbitMQ 合适。各种交换机类型、延迟队列、优先级队列开箱即用，做业务编排特别顺手。它的问题是吞吐量上限摆在那，几万 QPS 就有点吃力了，而且集群模式写起来麻烦，镜像队列坑不少。

RocketMQ 算是中间路线。吞吐接近 Kafka，功能比 Kafka 完整，事务消息、定时消息、消息轨迹都是现成的。社区在国内活跃，文档也友好。我们选它，说白了就是团队里没人能真正玩透 Kafka 的运维，RocketMQ 出了问题至少找得到人问。

Pulsar 我了解过但没上生产。分层存储和存算分离的思路确实先进，多租户也做得好，但部署复杂度摆在那，小团队扛不住。

几个容易被忽略的坑

第一个是消息不丢不等于一定不重。At-least-once 语义下，重复消费是常态。消费端幂等这件事，选型的时候就要想好，别等上线了才发现同一笔订单被处理了两遍。

第二个是积压。Kafka 靠加分区能撑住积压，RabbitMQ 就不太行，单队列消费能力是有上限的。业务能预估峰值就提前留余量，别等报警了再扩容。

第三个是运维成本。自建一套 Kafka 的硬件和人力成本，够买好几年的云服务。业务量不大就别折腾，云厂商的托管版省心太多。真要自建，先想清楚谁负责半夜爬起来处理分区故障。

说到底

没有最好的 MQ，只有最合适的。小团队、业务不复杂，RabbitMQ 或者干脆托管版起步；吞吐是命根子，上 Kafka；要吞吐又要省心，RocketMQ 值得一试。

选型这事的核心是，你搞清楚自己的业务到底要什么，然后拿最省力的方案去够着它。别为了炫技上重武器，最后运维的坑全得自己填。