消息队列选型与可靠性设计.docx

消息中间件选型评估与投递可靠性设计文档实例

（软件研发技术文档·数据与实例为据）

第一章选型背景与硬性约束

本次为订单事件总线选消息中间件，日峰值消息量1.2亿条、单条平均1.5KB、峰值吞吐4.6万条每秒。硬性约束四条：支持消息回溯、单Topic可承载亿级堆积、有序消息有解决方案、社区或厂商可长期维护。约束先立，选型才有尺子，不凭熟悉程度拍板。

软性偏好两条：团队运维经验、与现有监控体系集成度。约束与偏好分开列，避免被熟悉度绑架选了不合适的。选型文档要能回答一个问题：为什么是它而不是另一个，每个候选都要写淘汰理由，写不出淘汰理由说明没真比较过。

表1-1选型硬性约束

约束项

要求

权重

是否可让步

日消息量

1.2亿/天

必达

否

峰值吞吐

46000条/秒

必达

否

消息回溯

支持7天

必达

否

堆积能力

亿级/Topic

必达

否

有序消息

分区内有序

高

可降级

第二章候选中间件能力横向对比

候选四个：Kafka、RocketMQ、Pulsar、RabbitMQ。用同一压测环境各跑一轮基准，消息体1.5KB、三副本、同步刷盘。压测条件不一致的对比一律作废。结果差异主要在延迟与吞吐的平衡上——Kafka吞吐最高但P99延迟抖动，RocketMQ延迟平稳，RabbitMQ吞吐偏低。

单Topic堆积测试最能拉开差距：Kafka与RocketMQ在亿级堆积下读性能几乎不