消息队列选型实战：Kafka、RocketMQ、RabbitMQ 与 Pulsar 的边界

选型先看业务形态，再看技术参数

消息队列选型的常见错误是拿「吞吐量对比表」做决定——百万 TPS 在你的业务里可能一辈子用不上，而你要的事务消息、延迟消息、顺序消息能力它偏偏没有。正确的路径：先明确业务的四个形态问题（消息量级、是否需要事务、消费模式、生态绑定），再让候选队列对号入座。一、四者的真实定位

1. Kafka：日志流与大数据管道的事实标准。顺序写磁盘 + 零拷贝带来极高吞吐（单集群百万级），分区模型天然支持并行消费。短板：原生不支持延迟消息、事务消息场景有限（Kafka 事务只覆盖「消费-生产」原子性）、消息查询能力弱。适合：日志采集、埋点管道、流计算源头；
2. RocketMQ：电商交易场景的最佳实践。事务消息（半消息+回查）、延迟消息（固定级别/任意精度）、顺序消息（分区有序）、消息轨迹一应俱全。Java 技术栈团队运维成本低。适合：订单、支付等交易链路；
3. RabbitMQ：低延迟、路由灵活（Exchange 四种模型）、管理界面成熟。短板：吞吐上限低（万级到十万级）、堆积能力弱（堆积多了性能骤降）。适合：任务分发、RPC 异步化、中小规模业务集成；
4. Pulsar：存算分离架构（BookKeeper + Broker），扩容体验好、原生多租户、支持分层存储（冷数据卸载到对象存储）。短板：组件多、运维复杂度最高、社区生态弱于前两者。适合：多租户平台型业务、海量主题场景。

二、三个高频决策点

1. 要不要事务消息：交易链路需要「本地事务与消息发送原子性」——只有 RocketMQ 原生提供，Kafka 要自己封装本地消息表，选型时这一条常常一票定音；
2. 顺序怎么保：全局有序代价极高，业务上多数只需要「分区有序」（同一订单 ID 进同一队列）——Kafka/RocketMQ 都支持按 key 分区，全局有序需求先反思业务；
3. 堆积怎么办：消费端故障时的堆积承受力差异巨大（Kafka/Pulsar 堆积无压力，RabbitMQ 堆积即降级）。消费可靠性差的业务不要选 RabbitMQ。

三、云上托管的取舍

自建 vs 云托管：中小团队直接用云托管（CKafka/TDMQ/AMQP）——省掉集群运维、监控告警、版本升级三件套，成本增加有限；只有当成本占比显著（日消息亿级）或需要深度定制（插件、内核调优）才值得自建。用云托管时把「公网访问关闭 + ACL 权限 + 版本升级窗口」三件事确认好，安全与稳定性就拿到了八成。

四、迁移视角

没有队列是终身绑定：生产端把「发消息」抽象成统一接口，消费端按主题订阅——真正的锁定在客户端 SDK 与运维体系。新项目选型时多看一眼 Pulsar 的存算分离与分层存储，它是消息队列架构演进的方向；存量系统则优先考虑团队技术栈匹配度，迁移成本往往高于一切理论优势。

选型的本质是业务形态与系统能力的匹配：交易选 RocketMQ、流处理选 Kafka、轻量集成选 RabbitMQ、平台化选 Pulsar。参数对比表做参考，业务形态做决定。