MQ 选型与容量规划

本文是消息队列系统学习系列的 L3 实战篇。前置：[30. rocketmq-deep-dive]。 学完可以配合面试题食用：01-mq-selection-comparison-kafka-rabbitmq-rocketmq-pulsar、23-pulsar-architecture-bookkeeper

为什么选型比"哪个最好"更重要

"哪个 MQ 最好"是个伪问题。Kafka 能扛百万级吞吐，但加个事务消息就要折腾半天；RabbitMQ 路由灵活，但单机吞吐不到万级。选型不是比参数，是拿业务场景去匹配中间件的设计哲学。

选型失误的代价很高：Kafka 扛日志流是天然优势，拿它做订单事务消息推广后要补一堆可靠性方案；RocketMQ 事务消息是即开即用，但日志场景的吞吐上限不如 Kafka。选错了，后续架构改造成本远超初期评估花的时间。

四大 MQ 对比矩阵

先看四个主流选型各自的设计定位：

quadrantChart
    title MQ 选型定位
    x-axis 吞吐量低 --> 吞吐量高
    y-axis 运维简单 --> 运维复杂
    quadrant-1 轻量灵活
    quadrant-2 高性能业务
    quadrant-3 入门/嵌入式
    quadrant-4 流式骨干
    RabbitMQ: [0.25; 0.3]
    RocketMQ: [0.6; 0.55]
    Kafka: [0.85; 0.7]
    Pulsar: [0.8; 0.8]

Kafka

定位：日志流/事件流骨干。设计目标就是极高吞吐下的大规模流式数据处理，连消息本身都被设计成"不可变日志"。

维度	说明
吞吐	单机百万级 msg/s，社区有压测到 200 万+
延时	毫秒级，但批量刷盘，极低延时场景不如 RabbitMQ
可靠性	ISR + acks=-1 可做到不丢，但需配合幂等 + 事务
运维	依赖 ZK（或 KRaft），有 rebalance 和磁盘均衡问题
适用	日志采集、埋点、大数据管道、CDC、事件溯源

RocketMQ

定位：业务消息。阿里在 Kafka 基础上改造，把 Kafka 缺的业务友好特性（事务、延时、消息轨迹）直接内置了。

维度	说明
吞吐	单机十万级，低于 Kafka 但远高于 RabbitMQ
延时	毫秒级，事务消息引入半消息机制会多一次 RTT
可靠性	同步双写 + 事务消息回查，金融级
运维	相对简单，但 NameServer 无状态 + Broker 主从，部署不如 Kafka 成熟
适用	订单、交易、支付、电商核心链路

RabbitMQ

定位：灵活路由 + 轻量消息。AMQP 模型让路由规则极其灵活，适合小规模但路由复杂的场景。

维度	说明
吞吐	万级，Erlang 的调度器在大量连接时吃力
延时	微秒级，纯内存路由，延迟最低
可靠性	Confirm + Return + 镜像队列，配置到位不丢
运维	管理控制台成熟，但 Erlang 排障门槛高
适用	内部系统异步、任务分发、小流量但路由复杂的场景

Pulsar

定位：存算分离 + 多云原生。BookKeeper 做存储层，Broker 只做计算，弹性最好。

维度	说明
吞吐	单机百万级，存算分离后扩展性上限高
延时	毫秒级，但 BookKeeper 写路径比 Kafka 多一跳
可靠性	BookKeeper 的 Ledger 机制天然高可靠
运维	组件多（Broker/BookKeeper/ZK），运维复杂度最高
适用	多云部署、异地多活、多租户隔离严格、弹性需求大的场景

选型决策树

不要背参数，按业务场景画决策树：

你的场景是什么？
├── 日志/埋点/CDC/事件流 ——> Kafka
│   └── 需要同时支持事务消息？——> 上 Pulsar
│
├── 订单/交易/支付/高可靠业务 ——> RocketMQ
│   └── 吞吐量要求低于万级？——> 可用 RabbitMQ 替代
│
├── 内部异步/任务分发/路由复杂 ——> RabbitMQ
│   └── 未来扩展到万级以上？——> 建议直接上 RocketMQ
│
└── 多云/多数据中心/多租户隔离 ——> Pulsar
    └── 团队运维能力不够？——> Kafka 配合 MirrorMaker

三个常见决策误区：

• "Kafka 吞吐最高所以选它"：吞吐高不等于适合业务场景。用 Kafka 做订单消息，要自己实现事务消息的本地消息表回查，代码量翻倍。
• "RabbitMQ 简单好上手去哪都用"：单机吞吐上限 1-2 万/s，加集群后复杂度飙升，日均千万级消息就别用 RabbitMQ 了。
• "Pulsar 设计先进所以选它"：存算分离确实先进，但运维组件数比 Kafka 多一倍，小团队别碰。

容量规划：日均 1 亿消息的推演

选完 MQ 后，集群规模怎么定？拿一个具体场景做推演。

场景：电商核心链路，日均 1 亿条消息，峰值 TPS = 日均 TPS × 3 倍（假设 70% 流量集中在 4 小时内）。

步骤 1：算峰值吞吐

日均消息量 = 100,000,000
峰值时段 = 4 小时 = 14,400 秒
峰值占比 = 70%
峰值 TPS = (100,000,000 × 70%) / 14,400 ≈ 4,860 msg/s

步骤 2：定分区数

以 Kafka 为例，单分区吞吐约 10-20 MB/s（单条消息按 1 KB 算，约 1-2 万 msg/s）。但分区数不是越多越好：

• 每个分区对应一个文件目录，大量分区增加文件句柄
• 消费者数 > 分区数时多出的消费者空转
• 建议分区数 = 预估峰值 TPS / 单分区安全吞吐

目标峰值 TPS = 4,860
单分区安全吞吐 = 5,000 msg/s（留余量）
最少分区数 = 4,860 / 5,000 ≈ 1，但考虑消费者并行度，建议 4-6 分区

步骤 3：算磁盘

单条消息大小 ≈ 1 KB（含元数据）
日写入量 = 100,000,000 × 1 KB ≈ 95 GB
保留周期 = 3 天（日志场景一般 3-7 天）
磁盘需求 = 95 GB × 3 = 285 GB

考虑副本和换页缓冲：副本数 2 → 570 GB。建议每台 Broker 配置 1 TB NVMe SSD，三台 Broker，每台 333 GB 写入，留足余量。

步骤 4：定集群规模

选型: Kafka
峰值 TPS: 4,860
目标 Broker 数: 3（至少 3 台保证 ISR 多数派）
每台 Broker 配置: 8 核 / 32 GB / 1 TB SSD
分区数: 6（3 Broker × 2 分区/台）
副本数: 2（min.insync.replicas=2）

步骤 5：上云 vs 自建

维度	自建	上云（阿里云 RocketMQ / 腾讯云 CMQ）
人力	维护 3 人	0 人
成本（月）	3 台服务器 ≈ 3,000 元	按量计费 ≈ 5,000-10,000 元
弹性	扩容需采购	秒级扩容
SLA	自己保证	99.95%+
问题	磁盘故障/OOM/GC 调优	单 Topic 有限制/API 不完全兼容

月均 1 亿消息量级，自建成本更低，但隐性成本是运维排障时间。如果团队没有专职 MQ 运维，上云是更省心的选择。

多集群与租户隔离

业务隔离：订单、营销、日志三个场景建议分三套集群，而不是塞到一个集群用 Topic 区分。原因是：

• 一个集群的积压会影响所有 Topic（Kafka 的 rebalance 是全集群的）
• 日志流量大，可能把订单 Topic 的磁盘刷满
• 升级/重启一个集群不影响其他业务

Topic 命名空间：如果必须共享集群，用命名空间隔离。Kafka 的 Topic 名前缀 + ACL 控制，RocketMQ 的 Tag 也能做部分隔离。但注意：命名空间防的是权限，防不了磁盘争抢和 rebalance 影响。

常见误区与小结

• 误区一：分区数越大吞吐越高。分区数超过 Broker CPU 核心数后，文件句柄和 IO 争抢会抵消并行收益，反而降低吞吐。经验值：分区数 ≤ Broker 数 × 2。
• 误区二：消息体越大越好。消息体超过 1 MB 后，吞吐量急剧下降，序列化/反序列化成为瓶颈。大消息走对象存储，MQ 只传引用。
• 误区三：选型只看功能对比表。功能对比表是静态的，但线上流量是动态的。选型后一定要做 1.5 倍峰值压测，确认集群在极限情况下的延迟曲线。
• 误区四：容价比选便宜的。自建 Kafka 三台机器的硬件成本低于上云，但加上排障、值班、升级的人力成本，多数场景上云更划算。
• 误区五：零副本规避磁盘成本。单副本的 Kafka 集群，Broker 宕机数据全丢，这不是"节约成本"是"赌运气"。

小结：选型不是技术选秀，是拿业务场景去匹配中间件的设计哲学。容量规划的核心是"先算后做"——峰值 TPS 算清楚、分区数有依据、磁盘打够余量。下一篇 32 讲 MQ 生产手册：不丢、不重、不积压的实战打法。

参考

参考：Kafka 官方文档《Kafka Design》、RocketMQ 官方文档《Best Practice》、Pulsar 官方文档《Architecture Overview》