外观
存储与高可用、扩展与并行矩阵
本页结论：七个产品的高可用模型差异极大——RabbitMQ 以队列为单位做 Raft 多数派复制（Quorum Queue），Kafka 以分区为单位做 ISR 副本，RocketMQ 以 Broker 为单位做主从/DLedger 复制，Pulsar 把存储下沉到 BookKeeper、Broker 本身无状态，Redis 靠主从复制 + Sentinel 故障转移（Stream 是单 key 无法分片），NATS JetStream 以 Stream 为单位做 Raft 复制，Artemis 以 Broker 为单位做 live/backup 对（复制或共享存储）；扩展粒度与多租户能力同样由各自架构决定。
覆盖 spec §8.2「高可用与扩展矩阵」，并合并「存储与高可用」「扩展与并行」两个主题。版本基线与标记规则见矩阵总览（checkedAt: 2026-08-19）。
复制与高可用
| 能力 | RabbitMQ | Kafka | RocketMQ | Pulsar | Redis Streams | NATS | Artemis |
|---|---|---|---|---|---|---|---|
| 复制单元与协议 | ✅ Quorum Queue：队列级 Raft 多数派复制（storage-ha） | ✅ 分区级副本 + ISR（in-sync replicas）机制，KRaft 复制元数据（storage-ha） | 🔧 Broker 主从复制：同步双写/异步复制；DLedger/Controller 模式可自动选主，需额外部署形态（storage-ha） | ✅ 存算分离：消息写入 BookKeeper ledger 多副本，Broker 无状态、随时可替换（storage-ha） | 🔧 实例级主从复制（异步）：Stream 随实例复制；集群模式按 key 分片但单个 Stream 仍是单 key（storage-ha） | ✅ Stream 级 Raft 复制：R3 Stream 跨节点多数派（需 JetStream 集群模式）（storage-ha） | 🔧 Broker 级 live/backup 对：journal 复制到 backup（异步），或共享存储（shared store）切换（storage-ha） |
| 写入确认条件 | 🔧 Quorum Queue 写入需多数派落盘才确认，延迟高于单节点（storage-ha） | ✅ acks=all 要求 ISR 全部副本确认；配合 min.insync.replicas 控制可写性（reliability） | 🔧 同步双写等主从都成功；异步复制主机确认即返回（reliability） | ✅ 写确认需 ensemble 中满足 write/ack quorum 的 bookie 落盘（可配）（storage-ha） | 🔧 主节点写入即返回；WAIT 可等待副本确认，AOF 刷盘策略另配（reliability） | ✅ R>1 时写确认需 Raft 多数派落盘（storage-ha） | 🔧 写确认以 live journal 落盘为准（BLOCK_ON_DURABLE_SEND）；到 backup 的复制是异步的（storage-ha） |
| 故障容忍 | ✅ Quorum Queue 可容忍少数派节点丢失；失去多数派时该队列不可写（保数据安全）（storage-ha） | ✅ ISR 收缩后仍可读写；ISR 少于 min.insync.replicas 时拒写（storage-ha） | 🔧 异步复制主机宕机有丢消息窗口；同步双写从机故障影响可用性（pitfalls） | ✅ bookie 故障后自动触发副本修复（rereplication）；Broker 故障由无状态架构直接接管（storage-ha） | 🔧 异步复制下主节点宕机有丢数据窗口；Sentinel 自动故障转移但非强一致（storage-ha） | ✅ R3 Stream 容忍少数派节点故障；单节点 R1 无容错（storage-ha） | 🔧 live 宕机 backup 激活接管；异步复制下可能丢失未复制消息；需 quorum/检查机制防脑裂（storage-ha） |
| 元数据服务 | ✅ 节点间内置（4.x 无外部依赖） | ✅ KRaft 内置控制器集群，无需 ZooKeeper（storage-ha） | ✅ NameServer 集群无状态注册发现；5.x 架构为 proxy + namesrv + broker（concepts） | 🔧 依赖 ZooKeeper/Oxia 存元数据，是部署的一部分（storage-ha） | ✅ 无独立元数据服务；Sentinel/Cluster 自带元数据机制（storage-ha） | ✅ 无外部依赖：JetStream 元数据内置 Raft 管理（storage-ha） | ✅ 无外部依赖：集群节点经 discovery group/广播互连，拓扑信息在节点间传播（storage-ha） |
扩展与并行
| 能力 | RabbitMQ | Kafka | RocketMQ | Pulsar | Redis Streams | NATS | Artemis |
|---|---|---|---|---|---|---|---|
| 扩容粒度 | 🔧 增加队列数 + 增加节点分担队列；单队列无分区，吞吐受单队列上限约束（storage-ha） | ✅ 分区是并行单位：Topic 分区数决定消费并行度；分区只能增、难缩（storage-ha） | ✅ MessageQueue 数可调：队列数决定消费并行度，可在线调整（storage-ha） | ✅ 分区 Topic + Broker 水平扩展；存算分离使存储容量（bookie）与服务层独立扩缩（storage-ha） | 🔧 单 Stream 无法拆分：扩容靠增加 Stream 数 + 增加消费组成员；集群模式横向分片到多 key（storage-ha） | 🔧 单 Stream 无分区：扩容靠 Subject 拆分多 Stream + 增加消费实例（storage-ha） | 🔧 集群中把队列分布到更多节点分担；单队列无分区，吞吐受单队列与 paging 配置约束（storage-ha） |
| 消费并行上限 | 队列数（每队列内竞争消费，prefetch 控流） | Consumer Group 内有效消费者数 ≤ 分区数，多余消费者空闲（routing） | 队列数 × 消费线程配置（集群消费模式组内分担队列）（routing） | 由订阅类型决定：Shared 最灵活、Key_Shared ≤ 不同 key 数、Exclusive/Failover 单活（routing） | 组内消费者数无硬性上限，但都从同一 Stream 拉取，吞吐受单 Stream 与实例能力约束（routing） | 一个 Consumer 可多实例共同拉取；并行度不受「分区数」限制但受 Stream 吞吐限制（routing） | 队列数（每队列内多消费者竞争分发；Message Group 同组串行）（routing） |
| 热点拆分能力 | 🔧 靠拆分队列手动分摊 | 🔧 热点 key 集中在单分区，需业务改造 key 设计（pitfalls） | 🔧 MessageGroup 倾斜时同样集中到单队列（pitfalls） | 🔧 Key_Shared 的 key 倾斜导致消费者负载不均（pitfalls） | 🔧 热点 Stream 无法拆分，只能业务层拆分多 Stream（pitfalls） | 🔧 热点 Stream 无法拆分，只能按 Subject 拆多 Stream（pitfalls） | 🔧 热点队列无法拆分，只能业务层拆分多队列（pitfalls） |
| 多租户 | ✅ Virtual Host：vhost 级资源与权限隔离（轻量，无原生配额体系）（concepts） | ➖ 无原生租户层级：topic 命名约定 + ACL + Quota 组合近似（operations） | ➖ 无原生租户层级：ACL + 部署层隔离（operations） | ✅ 原生 Tenant/Namespace 层级：配额、保留策略、权限按命名空间管理（concepts） | ➖ 无租户层级：ACL + DB 编号/键前缀约定（operations） | ✅ 原生 Account 层级：每账号独立 Subject 空间、权限与 JetStream 配额（concepts） | ➖ 无原生租户层级：角色 + 地址级权限（security-settings）做隔离（operations） |
路由与分发机制（扩展视角）
| 产品 | 机制 | 对扩展的影响 |
|---|---|---|
| RabbitMQ | ✅ Exchange + Binding（routing） | 路由灵活但消息落点由绑定决定，扩容靠增加队列 |
| Kafka | ✅ partition key 哈希（routing） | key 分布直接决定负载是否均匀 |
| RocketMQ | ✅ Topic + MessageQueue 选择 / MessageGroup（routing） | 队列数与发送策略共同决定负载分布 |
| Pulsar | ✅ 分区 key + 订阅类型（routing） | 分区数决定服务层并行，BookKeeper 决定存储扩展 |
| Redis Streams | ✅ 单 key Stream + 消费组竞争（routing） | 无分片路由：扩展只能靠业务拆分多个 Stream |
| NATS | ✅ Subject 通配路由 + Stream 捕获（routing） | 路由灵活但 Stream 无分区：扩展靠 Subject 树拆分 |
| Artemis | ✅ Address anycast/multicast + selector + Message Group（routing） | 无分片路由：扩展靠增加队列数并分布到集群节点 |
完整路由语义见投递语义矩阵的路由部分。
脚注：同名异义
- 「扩容」：Kafka/RocketMQ/Pulsar 的扩容主要是「增加分区/队列并重均衡」；RabbitMQ 的扩容是「增加队列并把队列分布到更多节点」——前者扩的是数据分片，后者扩的是独立队列的数量。
- 「副本」：Kafka replica 是分区副本（有 Leader/Follower 与 ISR）；RabbitMQ Quorum 副本是 Raft 成员（多数派概念，无 ISR）；RocketMQ 主从是 Broker 级角色；Pulsar 的副本在 BookKeeper ledger 层（bookie 不区分 leader）；Redis 副本是整个实例的主从镜像（异步、无分片感知）；NATS 副本是 Stream 级 Raft 组成员；Artemis 副本是 Broker 级 live/backup 对（复制或共享存储）。七者的故障切换方式与数据一致性窗口都不同。
- 「Broker 无状态」：仅对 Pulsar 成立——其消息状态在 BookKeeper，Broker 宕机不丢数据；Kafka/RocketMQ 的 Broker 本身持有数据（或主从持有），RabbitMQ 节点持有队列数据。