RabbitMQ 与 AMQP 运维

• Exchange/Queue/Binding 概念
• direct 直连路由
• topic 主题路由

RabbitMQ 中，Producer 不直接发送消息到 Queue，而是发到 Exchange（交换机），Exchange 根据 Binding（绑定）关系与消息的 routing key 决定消息路由到哪些 Queue。四种交换机类型：direct（直连）按 routing key 精确匹配（Queue 的 binding key 与消息的 routing key 完全一致才收）；topic（主题）按 routing key 的模式匹配（支持通配符 * 匹配一个词、# 匹配零或多个词），适合多级路由；fanout（扇出）把消息广播到所有绑定它的 Queue，忽略 routing key；headers（头）按消息的属性（headers）匹配，不按 routing key。运维上需根据路由需求选择交换机类型，并注意 binding 与 routing key 的规划。

交换机的路由语义是 RabbitMQ 的核心。direct 精确、topic 模式化、fanout 广播、headers 按属性。模型是"发到交换机 → 按绑定路由 → 存到队列 → 消费者消费"。理解这四种类型决定如何设计消息路由拓扑。

• publisher confirm 确认机制
• mandatory/return 处理不可路由消息
• consumer ack 与 requeue

发送端可靠性：publisher confirm（发布确认）让 RabbitMQ 在消息成功持久化后返回确认，生产者据此判断是否成功；mandatory 标志配合 return（返回）机制，当消息无法路由到任何队列时，RabbitMQ 会将消息返回给生产者，避免静默丢失。消费端可靠性：消费者需显式 ack（basicAck），确认消息已处理；若处理失败可 basicNack/basicReject 并 requeue（重新入队）或进入死信。可靠性的组合要点：publisher confirm 保证"发送不丢"，mandatory/return 保证"路由不丢"，consumer ack 保证"消费不丢"，requeue 保证"失败可重试"。运维上需在发送端开启 confirm、消费端开启手动 ack，并监控 unmatched 消息与未确认消息。

RabbitMQ 可靠性靠三个环节：发送确认（confirm）、路由兜底（mandatory/return）、消费确认（ack）。requeue 提供重试但可能造成重复与消息乱序，需结合幂等。组合起来才能形成"端到端不丢"的闭环。

• Quorum Queue 的复制模型
• Streams 的复制模型
• 镜像队列的缺陷

Quorum Queue（仲裁队列）基于 Raft 协议，数据在多个节点（默认 3 个副本中的多数）之间复制，leader 写成功且多数确认后才返回，提供强一致性与自动故障转移，适合对可靠性要求高的场景。Streams 采用日志分段存储，也是多副本复制，适合消息流、可重放场景。镜像队列（mirrored queue）是旧版高可用方案，通过类 Raft 的算法在多个节点间复制，但存在脑裂风险、性能开销大、故障转移复杂等问题，因此 RabbitMQ 4.x 移除了镜像队列，统一推荐使用 Quorum Queue 与 Streams。运维上选择队列类型：Quorum Queue 适合可靠性优先，Streams 适合流式/重放场景。

镜像队列的高可用依赖"所有镜像同步"，其实现历史包袱重、易脑裂、性能差。Quorum Queue 用 Raft 解决一致性与自动选主，Streams 用日志复制解决流式场景。4.x 移除镜像队列是架构收敛，运维需迁移。

• memory high watermark（内存高水位）
• disk free limit（磁盘空闲限制）
• flow control（流量控制）

RabbitMQ 会监控内存与磁盘：内存高水位（vm_memory_high_watermark，默认 0.4）表示内存使用超过该比例时，RabbitMQ 进入 flow control（流量控制），停止接收新消息（阻塞生产者）以保护节点；磁盘空闲限制（disk_free_limit）表示磁盘剩余空间低于该阈值时，RabbitMQ 也会进入 flow control 暂停接收，防止磁盘写满损坏数据。flow control 是通过在连接/信道层面阻塞生产者投递来限制内存消耗。治理：合理设置水位阈值（如 0.4-0.6）、预留磁盘空间、监控流量控制状态（rabbitmqctl list_connections 的 state 字段）、定位内存占用大户（消息堆积、队列膨胀）并治理。

flow control 是 RabbitMQ 的保护机制，触发说明节点资源紧张。治理要从根源入手：内存水位过高往往因消息堆积或队列无消费者，磁盘告警因磁盘容量不足。运维需监控连接状态与队列堆积，及时消费或清理。

• 用户与 vhost 权限
• TLS 认证与加密
• 插件管理

用户与权限：RabbitMQ 通过用户（user）与虚拟主机（vhost）隔离租户，为用户配置 vhost 内的读、写、配置权限（configure/read/write），权限作用于具体资源（exchange/queue）。TLS 认证：配置 RabbitMQ 的 TLS 监听（启用 ssl 端口），使用证书实现传输加密与客户端证书认证（mTLS），并支持用户密码认证。插件管理：通过 rabbitmq-plugins enable/disable 管理插件（如 management、prometheus、shovel、federation），启用前评估兼容性。版本升级：升级前备份配置与数据、检查插件兼容性、滚动升级节点，避开生产高峰，升级后验证集群与队列。

安全与升级是运维基础。vhost 隔离 + 用户权限实现多租户安全，TLS 保障传输安全。插件与版本升级需谨慎，避免插件不兼容或数据损坏。升级前演练、升级中灰度、升级后验证是标准流程。

• 连接被重置的排查
• channel 异常关闭
• 消息丢失的定位

连接被重置：多由网络抖动、连接数超限、客户端长时间空闲被服务端关闭、内存/磁盘告警触发 flow control 导致，需检查服务端日志、连接状态与网络。channel 异常关闭：常见于声明冲突、权限不足、消息过大、prefetch 设置不当，需查看 channel 关闭原因（reply-code）。消息丢失：需排查发送端是否开启 confirm、消费端是否手动 ack、队列是否持久化（durable）、交换机是否持久，以及是否因未路由被 mandatory 丢弃。集群脑裂：多节点因网络分区导致部分节点无法通信，需通过 rabbitmqctl cluster_status 检查分区状态，配合 network partition handling 策略（如 pause 或 autoheal）恢复。

排障要"看现象找根因"。连接/channel 问题多与资源、权限、网络相关；消息丢失多因可靠性配置缺失（未持久化、未确认、未开启 confirm）。脑裂是网络分区问题，需配置分区处理策略并恢复一致性。

• 消息大小的影响
• 持久化开销
• 连接/信道管理

消息大小：过大的消息占用内存与带宽，RabbitMQ 在内存中处理消息，大消息会显著增加内存压力与吞吐下降，应拆分或使用外部存储。持久化开销：持久化消息（durable queue + persistent message）需要 fsync 到磁盘，开销高于非持久化，延迟与吞吐受影响，需权衡可靠性与性能。连接/信道管理：RabbitMQ 面向连接（TCP）与信道（channel，连接内的逻辑通道），信道很轻量可复用，应避免连接风暴（过多 TCP 连接），合理复用连接与信道。线程池配置：W1/W2 worker 线程池处理消息分发，需结合 CPU 核数与并发调整，避免线程饥饿或过高上下文切换。

性能调优围绕"内存、IO、并发"。消息大小与持久化决定内存与磁盘开销，连接/信道管理决定并发模型，线程池决定消息分发能力。RabbitMQ 是内存型，需控制队列堆积与消息大小。

• Shovel 插件
• Federation 插件
• Management UI

Shovel：实现跨集群/跨节点的消息转发，把消息从一个集群（或 queue）搬到另一个，适合简单的数据迁移、协议转换与容灾，配置灵活。Federation：实现跨集群的主题/队列联邦，把源集群的消息自动复制到目标集群，适合多集群同步与容灾。Management UI：提供图形化管理界面，用于查看队列、连接、监控、管理用户与策略，是运维的常用入口。Prometheus 插件：暴露 RabbitMQ 的指标（队列、连接、内存、磁盘等）供 Prometheus 采集，配合 Grafana 建立监控大盘。运维上这些插件应按需启用、统一纳入版本管理，并监控插件自身的运行状态与资源占用。

各插件各司其职：Shovel 做单点跨集群转发，Federation 做多集群联邦复制，Management UI 提供图形化管理入口，Prometheus 插件暴露指标供监控。选型按需求而定：数据迁移用 Shovel，多集群同步用 Federation，监控告警用 Prometheus。

• 死信的产生条件
• TTL 与消息过期
• x-dead-letter-exchange 配置

RabbitMQ 死信（DLX）机制用于处理无法正常消费的消息。消息成为死信的三种情况：消息被 basicReject/basicNack 且 requeue=false、消息因 TTL 过期、队列达到最大长度（max-length）。配置 x-dead-letter-exchange 指向一个死信交换机，死信消息会被路由到该交换机（可按 x-dead-letter-routing-key 指定路由 key），进入死信队列。TTL 通过 x-message-ttl 或 per-message 设置消息存活时间，过期后进入死信。重投策略：从死信队列取出消息后，分析失败原因，修复后重新投递到原队列或业务处理，配合重试次数与退避，避免无限重试。

死信机制是"消费失败 + 过期 + 超长"的兜底。DLX 把不可消费消息路由到专门队列，供人工或补偿处理。重投要结合失败原因分类，避免把死信无脑重投导致无限循环。运维需监控死信队列堆积。

• 队列长度监控
• prefetch 设置
• 消费者处理能力

堆积治理先监控队列长度（messages）与消费速率，判断是生产过快还是消费不足。prefetch（basicQos）设置消费者一次从队列预取的消息数，控制消费者缓冲，避免消费者拉取过多消息导致内存积压；prefetch 过大会导致消费者堆积、消费不均，过小则增加网络往返、降低吞吐。消费者处理能力：通过扩容消费者实例、优化处理逻辑、提升下游性能来提升消费速率。限流：通过消费端速率控制或队列 TTL/长度限制，避免无限堆积。运维上需结合 prefetch 与消费能力合理设置，避免消费者被压垮。

堆积的本质是消费速率 < 生产速率。prefetch 是"消费者侧的分批拉取"，平衡吞吐与内存。治理需监控队列长度并设置告警，扩容消费者或调整 prefetch。过度消费会压垮下游，需限流。

• Erlang cookie 的一致性
• 节点发现机制
• 网络分区处理策略

Erlang cookie 是集群节点间认证的密钥，所有节点必须一致，否则节点无法加入集群。节点发现：通过集群配置（disk 节点集合）与 peer discovery 机制（如 DNS、K8s 服务发现）让新节点加入集群。网络分区处理：RabbitMQ 支持 pause-minority、pause-if-all-down、autoheal 等策略，在发生网络分区时决定如何暂停节点或自动恢复，避免脑裂导致数据不一致。集群恢复：网络恢复后，按策略自动或手动恢复，检查分区状态（partition）、重启受影响节点、确认队列与数据一致。运维上需统一 cookie、配置分区策略、监控分区状态。

Erlang cookie 是集群安全的基础，不一致会导致节点无法互信。网络分区是 RabbitMQ 集群的主要风险，需通过分区策略避免脑裂那一半继续写，从而保证数据一致。恢复时优先处理分区状态，再重建节点。

• channel.basicQos 设置
• 公平分发（fair dispatch）
• prefetch 过大/过小的影响

默认 RabbitMQ 采用轮询分发（round-robin），不感知消费者处理速度，可能导致快的消费者被冷落、慢的被压垮。通过 channel.basicQos(prefetch) 设置消费者"一次预取的最大未确认消息数"，实现公平分发：消费者处理完并 ack 后才有资格继续拉取，从而按处理能力分配消息。prefetch 过大：消费者会一次性拉取大量消息到内存，某些消费者积压、分配不均，且处理慢的消费者拖累整体；prefetch=1：每次只取一条，最公平但网络往返多、吞吐低。设置原则：根据单条消息处理耗时与吞吐需求权衡，通常按"处理时间 × 目标吞吐"估算，良好实践是设置一个适中值（如 10-100），并保证消费者处理能力匹配。

prefetch 是消费者侧的"流量控制"，本质是"未确认消息数上限"。过大牺牲公平与内存，过小牺牲吞吐。公平分发让处理能力强的消费者多消费，整体吞吐更优。设置需结合消息处理耗时与并发。

• 单队列单消费者保证顺序
• 多消费者破坏顺序
• 业务自行排序

单队列单消费者场景下，RabbitMQ 按先进先出顺序投递消息，能保证顺序（前提是单消费者、无并发 ack 乱序）。多消费者场景下，多个消费者消费同一队列，消息被并行消费，顺序无法保证。此外，即使单消费者，如果消息重试/requeue、或消费者并发处理，也可能破坏顺序。业务自行排序的常用方法：消息带业务时间戳或序号，消费端按时间戳/序号在本地缓冲排序后再处理；或按业务 key 将消息路由到同一队列并单消费者处理；或用数据库/状态机按业务顺序恢复。运维上需明确业务对顺序的要求，避免为全局顺序牺牲吞吐。

RabbitMQ 保证"队列内 FIFO + 单消费者顺序"，多消费者或并发/重试会破坏顺序。业务排序需自带语义（时间戳/序号），在消费端排序。这是"用业务字段重排"的通用做法，避免依赖 MQ 的全局顺序。

• 连接与信道的关系
• 连接/信道内存开销
• 连接数限制

RabbitMQ 中一个 TCP 连接（connection）可承载多个信道（channel），信道是轻量的逻辑通道，消息操作在信道上进行。连接与信道都占用内存（连接有 TCP 缓冲与 Erlang 进程，信道也有进程与队列），连接数过多会带来内存与 CPU 压力。防护连接风暴：服务端限制每个客户端的连接数（如 channel_max、可用连接配额）、控制连接超时；客户端侧应复用连接、合理创建信道、避免每次操作新建连接。运维上需监控连接与信道数，设置阈值告警，防止客户端连接风暴耗尽资源。

连接是 TCP 级别，信道是逻辑通道。连接数过多是常见问题（客户端连接池未复用），导致资源耗尽。限制连接数 + 客户端复用连接是双向防护。信道虽轻量，过多也会增加 Erlang 进程开销。

• frame_max 限制消息大小
• 大消息传输问题
• 大消息存储方案

frame_max 定义 AMQP 帧的最大字节数，限制单条消息及帧大小，超过 frame_max 的消息无法发送。RabbitMQ 的消息在内存中处理，大消息（如几十 MB 以上）会显著增加内存压力、降低吞吐，并可能因超过 frame_max 而被拒绝。大消息处理策略：不在 MQ 中直接传大内容，而是把大消息内容存到外部存储（如对象存储、DB、文件），MQ 只传消息引用（如 ID、URL），消费者按引用获取内容；或分段传输。序列化策略：使用紧凑高效的序列化格式（如 protobuf、消息压缩），减少消息体积。运维上需明确 frame_max 与消息大小上限，规划大消息的存储方案。

RabbitMQ 是内存型，大消息是反模式。frame_max 是硬限制，超过即失败。合理做法是"MQ 只传元数据 + 内容放外部存储"，这是通用的大消息处理模式，兼顾可靠性与性能。

• Streams 日志分段存储
• 消费游标
• 保留策略

Streams 采用日志分段存储，消息以追加方式写入日志文件，支持按 offset 或时间回溯消费，消费游标（consumer offset）记录消费者在流中的位置，支持从任意位置开始消费与重放。保留策略通过 x-max-length-bytes、x-max-length（条数）或 x-max-age（时间）控制流的保留范围，超限数据被清理。Quorum Queue 也基于日志（Raft 复制日志），但消费语义是"分配制"（消费后 ack 移出），不保留已消费消息；Streams 适合"可重放、可回溯"场景。运维上需按场景选择，配置保留策略与监控流大小。

Streams 是"日志 + 游标"模型，适合需要回溯/重放的场景；Quorum Queue 是"消费即移除"模型，适合可靠工作队列。两者都基于日志多副本。保留策略决定流的数据边界，需按需配置避免无限增长。

• vhost 隔离
• 资源配额（limits）
• 监控大盘

vhost 是 RabbitMQ 的逻辑隔离单元，每个 vhost 有独立的交换机、队列、绑定与权限，不同租户（业务）用不同 vhost 隔离，用户在各 vhost 内配置独立权限。资源配额（limits）：通过 rabbitmqctl set_vm_memory_high_watermark、set_disk_free_limit 以及队列级别限制（vhost 的队列/连接配额）控制资源使用，防止某个租户耗尽集群资源。监控大盘：通过 Prometheus 插件采集队列、连接、内存、磁盘、吞吐等指标，在 Grafana 建立统一大盘。告警设计：按队列堆积、连接数、内存水位、磁盘水位、flow control 状态设置分级告警，避免告警风暴。

多租户治理的核心是"隔离 + 配额 + 可观测"。vhost 隔离逻辑资源，配额限制资源占用，监控与告警保障可观测。合理设计 vhost 与权限、设置配额、建立监控告警，是租户治理的三要素。

• TTL+DLX 经典方案
• 延迟消息插件
• 选型取舍

TTL+DLX 经典方案：消息先发到一个设置了 TTL 的中间队列，到期后消息进入死信（DLX）被路由到业务队列，实现延迟。优点是无需额外插件、基于原生机制；缺点是每条消息的延迟时间需在队列 TTL 或消息 TTL 上体现，固定在队列 TTL 时无法灵活设置不同延迟，且消息到期顺序与 TTL 有关（先到期的先处理），大量消息时会有额外开销。延迟消息插件（rabbitmq_delayed_message_exchange）：提供专门的延迟交换机，直接在消息上设置延迟时间，支持任意延迟，实现更优雅、性能更好；缺点是需要启用插件，且依赖插件维护。取舍：追求简单或无插件约束用 TTL+DLX，需要灵活延迟与性能用插件。

TTL+DLX 是"用原生特性模拟延迟"，灵活性与性能受限；插件是专用延迟交换，更专业。选型取决于是否需要灵活延迟、插件可用性与团队维护能力。延迟消息本身有存储成本，需评估规模。

• 3.x 到 4.x 兼容性
• 镜像队列迁移到 Quorum 队列
• 迁移风险

3.x 到 4.x 升级：4.x 移除了镜像队列，是否兼容取决于使用特性；需确认所用插件、客户端版本与配置在 4.x 的兼容性，升级前测试。镜像队列迁移到 Quorum 队列：由于 4.x 移除镜像队列，需将镜像队列迁移到 Quorum Queue。路径：创建对应的 Quorum 队列，通过 Shovel 或消息重放把旧队列数据迁移过去，切换消费者到新队列，再删除旧镜像队列。风险：迁移期间可能丢消息、顺序变化、消费中断；Quorum Queue 对消息持久化要求高、性能与镜像队列有差异，需评估。迁移前备份、在低峰执行、验证数据完整。

4.x 移除镜像队列是重大变更，迁移到 Quorum Queue 是必须路径。迁移需"新建 Quorum 队列 → 数据迁移 → 切换 → 清理"，并评估可靠性、性能与顺序差异。升级与迁移都是高风险操作，需演练回退。

• Quorum 队列 leader 选举
• 少数派存活
• 客户端重连

Quorum Queue 基于 Raft，集群中副本节点选举出 leader，leader 负责读写，写入需多数副本确认。少数派存活：当 leader 所在节点故障或网络分区导致多数派不可达时，Quorum Queue 无法选出新 leader，写入会失败（保持可用性边界），避免产生脑裂的多个 leader；只有多数派存活才能继续接受写入。客户端行为：leader 变更时，客户端连接会收到异常，需重连到新 leader；重连后客户端可重新发布（publish）被拒绝的消息，但由于 published message 可能已投递，存在重复，需配合幂等。运维上需监控 leader 状态、副本健康与客户端重连。

Quorum Queue 的"多数派"决定可用性边界：少数派存活时只能读不能写，防止脑裂。客户端重连是故障转移的基础，重发布需幂等处理。这是 Raft 一致性在消息队列的应用。