首次生产部署

把 RabbitMQ 跑上生产不难，难的是让它长期稳定运行。这一章关注上线之后的事：容量怎么估、升级怎么滚、备份怎么恢复，而不是把配置项再罗列一遍。

1. 容量规划

配置跟着容量走，容量估算出现偏差，内存或磁盘压力迟早超出预期。规划前先回答三个问题。

• 峰值吞吐多少 msg/s，每条消息平均多大。
• 消息保留多久，是否需要落盘长期保存。
• 单队列最大堆积多少，消费者不可用多久需要系统继续扛住。

前两个问题决定消息流入速度和积压规模，第三个决定系统需要承受的积压峰值，三者共同决定内存、磁盘容量与水位告警的设定。例如峰值 1 万 msg/s、平均消息体 1KB、假设消费者中断后系统需要持续扛住 10 分钟的流入量，消息体的原始数据量约为 6GB（按 1 万 × 1KB × 600 秒估算）。这只是初步估算，不能直接当成内存或磁盘的配置值，还要叠加消息元数据、索引、队列类型、副本数量和持久化开销。最终容量应通过接近生产的消息大小和堆积规模压测来确定。

硬件上，内存对 RabbitMQ 最敏感。持久化消息可以落盘，内存主要承载消息元数据、队列索引、未确认消息和运行时状态，不同队列类型的内存模型有差异，堆积时内存仍是首要压力点。磁盘用 SSD，持久化消息和 Raft 日志都吃磁盘延迟。CPU 不是主要瓶颈，但核数不能凭经验定死，取决于吞吐量、消息大小、队列类型和副本数量，4 核可作为试运行的起点，不代表达到生产目标的最低配置。网络要保证内网低延迟，还要关注节点间带宽和丢包，集群节点之间的复制、心跳和故障检测都对网络抖动敏感。

2. 关键配置

生产部署前需要核对以下配置项。安全相关项必须主动设置，资源与连接参数要结合负载调整，没有放之四海皆准的固定值。

# 示例值，需结合节点内存与磁盘容量调整
vm_memory_high_watermark.relative = 0.6
disk_free_limit.absolute = 2GB

# 生产环境建议显式设置
loopback_users.guest = true

# 以下多为默认值或可选调优项，按连接规模与网络环境评估
heartbeat = 30
channel_max = 2047
tcp_listen_options.backlog = 1024
tcp_listen_options.nodelay = true

内存水位默认是 0.4。提高阈值能让 broker 在触发流控前使用更多内存，但会压缩操作系统和其他进程的可用内存，应结合节点可用内存与堆积规模设置，不宜直接套用固定值。磁盘剩余空间阈值默认 50MB 偏低，磁盘一到阈值就可能拒绝写入，但 2GB 也不是通用安全线，要按磁盘容量、消息写入速率和故障处置时间设置，并配置更早触发的监控告警，为扩容或清理留出时间。

guest 用户默认只允许本机登录。生产环境应为每个应用创建独立账户并配置最小权限，不再需要 guest 时直接删除，不要为远程访问放宽 guest 的本地登录限制。heartbeat、channel_max、tcp_listen_options 这几项需要结合客户端协商、连接规模和网络环境评估，不是必须修改的通用清单。

3. 高可用策略

需要队列级复制容错时，通常优先考虑 Quorum Queue。声明队列时在参数中指定 x-queue-type: quorum，队列状态和消息由 Leader 通过 Raft 复制到其他成员；Leader 所在节点故障时，只有剩余成员仍构成多数派才能选举新 Leader 并恢复服务，选举期间相关操作可能短暂停顿，不能理解成完全无中断。

镜像 Classic Queue 已在 RabbitMQ 3.9 弃用，并在 4.0 移除。旧配置中如果看到 ha-mode、ha-sync-mode 这类镜像队列策略，说明仍在用已移除的旧机制，应在升级前确认是否还有依赖。镜像队列采用异步复制，Leader 崩溃时尚未复制到成员的消息存在丢失风险，具体是否丢失取决于复制进度和发布确认状态。新项目不要引入镜像队列策略，老项目应制定迁移到 Quorum 的计划；迁移不能只改队列类型参数，还要处理队列重新声明、消息迁移和客户端兼容。

4. 生命周期操作

滚动升级。滚动升级不是所有版本组合都适用的通用流程，升级前先核对源版本到目标版本的官方升级路径、Erlang/OTP 兼容要求和 Feature Flags 状态，并确认集群健康、队列副本正常。逐节点升级时，一次只下线一个节点；下线前先排空该节点上的客户端流量和应用连接，再检查该操作是否会让任何 Quorum Queue 失去多数派。节点升级重启后，等它重新加入集群、队列副本追上进度、关键指标恢复正常，再动下一个。

备份与恢复。RabbitMQ 没有统一的「全量备份」命令，要区分元数据和消息数据。元数据（Exchange、Queue、Binding、用户和权限定义）用 rabbitmqctl export_definitions 导出 JSON，恢复用 import_definitions，它重建的是拓扑和访问配置，不恢复队列里的消息。导出的定义文件可能包含用户密码哈希等敏感信息，应限制其访问权限并妥善保管。

rabbitmqctl export_definitions /backup/definitions.json
rabbitmqctl import_definitions /backup/definitions.json

Quorum Queue 的副本用于节点故障期间维持服务，不是灾难恢复备份，不能替代误删、集群整体故障或数据损坏后的消息恢复。业务如果要求在这种场景下找回消息，要单独设计消息备份或跨集群灾备方案，并验证恢复点和数据完整性；双写也不是通用方案，没有失败处理和一致性设计反而会引入新的数据不一致。手工复制运行中的 broker 数据目录不可靠，必须遵循对应版本的官方备份恢复步骤。导出成功不代表恢复可用，应在测试环境实际演练一次导入并核对结果。

扩缩容。新节点加入集群后，已有 Quorum Queue 的副本不会自动迁移到它。让新节点承载队列副本需要显式调整成员分布，而 rabbitmq-queues rebalance quorum 只是重新平衡各节点的 Leader 数量，不能替代副本迁移。缩容前要检查目标节点承载的队列成员和 Leader 分布，以及剩余成员是否仍满足多数派，需要时先迁移或移除成员再下线；一个节点即使没有某队列的 Leader，也可能承载着它的 Follower，不能仅凭没有 Leader 就认定可以安全下线。

5. 用户与权限

最小权限原则，每个应用一个独立账户，只授予它需要访问的资源。set_permissions 的三个正则参数依次控制 configure、write、read 权限，分别匹配可配置、可写入、可读取的资源，不是简单地限制到应用自己的队列和交换机，过宽的通配会授予不必要的权限。部署前核对实际资源命名规则，密码使用 CHANGE_ME 之类的占位值，不要直接抄用示例。

# 创建应用用户并配置最小权限
rabbitmqctl add_user appuser CHANGE_ME
rabbitmqctl set_permissions -p / appuser "^app\\..*" "^app\\..*" "^app\\..*"

# 删除默认 guest
rabbitmqctl delete_user guest

管理员账户的创建与更完整的权限管理见安全配置，这里不重复。

6. 监控

上线前先确认监控采集和告警通道可用，再放开生产流量，关键指标和告警阈值见管理与监控。对于预期持续消费的队列，消费者数量降为 0 且队列仍有待消费消息时是最容易被忽略的告警，此时消息会持续堆积；允许空闲的队列则要按业务预期设置告警条件。判断消费是否异常要结合堆积量、增长速度和最老消息等待时间，不能等磁盘告警才发现问题。

指标	说明	告警阈值
队列消息数	待消费堆积	持续增长且超过业务上限告警
消费者数量	消费能力	预期持续消费的队列降为 0 且有待消费消息时告警
连接数	连接使用	接近连接限制或文件描述符上限时告警
内存使用	内存水位	结合配置水位、历史峰值和增长趋势预警
磁盘使用	剩余磁盘空间	触发 broker 磁盘告警前预警
发布速率	生产压力	与消费速率、确认速率联合分析
消费者确认速率	消费进度	与发布速率对比