消息队列选型结论预览
合成约束：8人Java团队，无专职中间件运维；订单峰值120条/秒，单消息2KB，要求至少一次投递，允许秒级积压恢复。这里没有采用近一年真实基准或云价，因此不呈现成本数字。
| 维度 | Kafka | RocketMQ | Pulsar | 本项目权重 |
|---|---|---|---|---|
| 团队上手 | 中 | 较高（Java友好） | 较低 | 25% |
| 订单语义 | 需自行设计 | 延迟/事务消息适配度较好 | 能力完整但复杂 | 30% |
| 运维复杂度 | 中 | 中 | 高 | 25% |
| 峰值余量 | 充足 | 充足 | 充足 | 10% |
| 托管可得性 | 待核云清单 | 待核云清单 | 待核云清单 | 10% |
暂定建议
在“现有云提供成熟托管 RocketMQ、团队已有Java经验”的前提下，优先做 RocketMQ 两周验证。原因不是它吞吐最高，而是三种方案都远超120条/秒，真正差异在订单延迟消息、失败重试与值班成本。若现有平台只对 Kafka 有成熟托管和监控，则改选 Kafka，避免为理论优势自建集群。
两周验证清单
- 重复消息：同一订单重放3次，库存只扣一次；
- 故障恢复：Broker不可用10分钟后，积压在15分钟内消化；
- 顺序性：同一订单“创建—支付—取消”不乱序；
- 可观测：能按订单号定位生产、消费和死信；
- 总成本：记录托管费、监控费和每周人工时。
明确不做
跨地域多活、百万级分区、Tiered Storage、复杂流处理均属当前过度设计。上线门槛是幂等键、重试上限、死信处理人和回放SOP齐备，而不是把三个中间件的高级功能都装上。