需要复制和高可用的持久业务队列，优先评估 Quorum Queue。它基于 Raft 复制，通常使用 3 或 5 个成员；只要多数派仍可用，已获发布确认的消息具有明确的数据安全边界。
Table of contents
Open Table of contents
集群不等于每条消息都有副本
RabbitMQ 节点加入集群后共享拓扑元数据，但具体队列类型决定消息怎样存储。Quorum Queue 有一个 Leader 和多个成员副本，发布确认要等法定人数接受。少数派一侧不能继续推进，这正是防止双写分叉的代价。
3 成员可容忍 1 个永久不可用，5 成员可容忍 2 个。成员过多会增加复制成本；RabbitMQ Quorum Queue 文档建议使用较小的奇数规模，并说明临时队列、最低延迟或超长积压可能不适合它。
容量看速率和年龄
积压字节可粗略估算为：
积压字节 ≈ (生产速率 - 消费速率) × 平均消息大小 × 持续秒数 × 副本数还要为索引、段文件、重投和磁盘水位留余量。比“消息条数”更有业务意义的是最老消息年龄：10 万条 1 秒清空与 100 条卡了 2 小时是不同事故。
必做故障演练
- 停止 Leader，记录重新选举期间的 Confirm 延迟和客户端恢复时间。
- 失去多数派，确认生产者超时而不是误报成功。
- 让消费者持续失败，检查投递上限和死信路径。
- 制造磁盘高水位，验证发布端背压与告警。
- 滚动升级一个节点，确认客户端连接分散且拓扑声明幂等。
扩容 Broker 不会自动解决单个热队列的吞吐上限。先按业务键拆队列或采用流式队列，再评估节点扩展。运维变更应先备份定义，记录 Policy 版本，并准备停止发布和回切入口。
下一步
继续阅读08-15 Kafka 客户端消息流转，比较日志型消息系统的消费模型。