内部机制：broker 到底怎么做到的

3.1AMQP 0-9-1 帧：channel 多路复用的根

一条 TCP 上传输的最小单位是帧（frame）；每一帧都带 2 字节的 channel 编号，broker 靠交错这些帧、按编号还原，实现一条连接上多路 channel 并行。

底层机制（比文档深一层）：一帧 = 1 字节帧类型 + 2 字节 channel 编号 + 4 字节 payload 长度 + payload + 1 字节帧尾。帧尾固定是 0xCE（十进制 206）：解析器读完声明的长度后，下一个字节必须正好是 0xCE，否则判定字节流错位，直接断开整条连接——这是协议自带的成帧校验。帧类型只有四种：method（类型 1，一次 RPC，如 Basic.Publish）、content-header（类型 2，消息属性 + body 字节数）、content-body（类型 3，消息体原始字节）、heartbeat（类型 8，心跳）。

一次逻辑 publish 不是一帧，而是一串：先一个 method frame（声明"这是一次 publish，发给哪个 exchange、什么 routing key"），紧接一个 content-header frame（带消息属性和总 body 大小），再接 1 个或多个 content-body frame（消息体）。消息体大于 frame_max 时被切成多个 body frame——frame_max 在 connection.tune 阶段由 client 与 broker 协商，默认约 131 KB。

channel 多路复用的实现，就是给每帧打编号再交错：channel 1 的 method 帧、channel 2 的 body 帧、channel 1 的 header 帧，可以在同一条 TCP 上首尾相接地传，broker 读到每帧前缀的编号，把它投递给对应的会话状态机。这正是应用避免"每个任务开一条 TCP 连接"的原因——几百个并发任务复用一条 TCP 上的几百个 channel，握手、文件描述符、内核缓冲都省下来。

代价直接来自交错：同一 channel 上的帧严格按到达顺序处理——一个 channel 是串行的。所以一个 channel 不能被多个线程共享：线程 A 刚写完 method 帧、还没写 header 帧，线程 B 插进来写自己的 body 帧，编号一样、序列被打乱，broker 重组时把 B 的 body 当成 A 的消息体，或读到错误的帧尾直接断连。这把 01 章 §1.1"channel 不能跨线程"的结论落到了字节层面的因果。

3.2每队列一个 Erlang 进程：单队列的吞吐天花板

RabbitMQ 用 Erlang 写成，每个队列、每个 connection、每个 channel 都是一个独立的 Erlang 进程；一个队列的全部工作串行穿过它那一个进程邮箱，被钉在大约一个 scheduler/核上——单队列因此有一个换大机器也抬不动的吞吐上限。

底层机制（比文档深一层）：一个队列就是一个 gen_server 风格的 Erlang 进程（classic 队列是 rabbit_amqqueue_process，quorum 队列是 rabbit_fifo 状态机 + Ra 进程）。进程之间不共享内存，只靠消息传递：publish、ack、consumer 注册，全部变成发给该队列进程邮箱（mailbox）的 Erlang 消息，进程从邮箱里一次取一条、顺序处理。BEAM 的 scheduler 通常每个 CPU 核一个，一个进程在某一时刻只能跑在一个 scheduler 上——于是一个队列的全部吞吐被一个进程、约一个核所限定。

这是 RabbitMQ 最具决定性的性能事实：单个队列的处理能力，被单进程、单核的串行邮箱框死。一条队列打满了一个核，换一台核更多、主频更高的机器——那一条队列快不了多少，因为瓶颈不是机器总算力，是单进程串行。扩展的唯一方向是更多队列 / 分片：把负载摊到多个队列进程上，让它们各占一个核并行跑（如 consistent-hash exchange 把消息按 key 散列到 N 个队列，或用 sharding 插件）。绝不是"加一台更大的机器"。

场景走查：一个订单系统把全部订单事件发进单个 quorum 队列 orders。压测发现吞吐卡在某个数字，CPU 总利用率只有 30%，但 rabbitmqctl 显示 orders 队列进程的 reductions（Erlang 的 CPU 计量）持续打满。换 16 核机器，吞吐几乎不变。根因：单队列单进程的串行天花板。改法是用 consistent-hash exchange 按 order_id 把消息散到 8 个队列 orders.0..7，每个队列各占一个核并行消费——总吞吐随队列数近线性上升。

# 启用一致性哈希 exchange 插件
rabbitmq-plugins enable rabbitmq_consistent_hash_exchange

# 声明一个 x-consistent-hash 类型的 exchange，按 routing key 哈希分流
rabbitmqadmin declare exchange name=orders type=x-consistent-hash

# 绑定 8 个队列，weight 写在 binding key 上（这里各为 1）
# 消息按 order_id 哈希落到其中一个队列，8 个队列进程吃 8 个核
for i in $(seq 0 7); do
  rabbitmqadmin declare queue name=orders.$i queue_type=quorum
  rabbitmqadmin declare binding source=orders destination=orders.$i routing_key=1
done

3.3credit 流控与内存/磁盘告警：背压如何传导

队列给它的发布 channel 发放 credit（额度），每条消息扣 1，队列把消息推向下游（持久化）后才补额度；额度耗尽 → channel 进程阻塞 → TCP 不再读 socket → 背压沿 TCP 直接顶住生产者。

底层机制（比文档深一层）：每个 channel 进程向它要写入的队列进程持有一笔 credit。每发一条消息扣 1 个 credit。队列进程只有在把这条消息向下游推进之后（比如交给持久化层、写入 message store）才给该 channel 回补 credit。生产者快于队列处理速度时，credit 越扣越少，归零那一刻 channel 进程停止处理新的入站帧 → 它不再从 TCP 连接读取字节 → socket 接收缓冲填满 → TCP 滑动窗口归零 → 生产者的 send 阻塞。背压就这样从队列一路逆向传到生产者的网络栈，不需要应用层协议参与，靠的是 TCP 自身的流控。

这套机制是有靶向的：credit 是 channel ↔ 队列这一对之间的，只有压垮了某队列的那条发布路径会被减速。别的 channel、别的队列照常跑。这与下面要说的"告警"形成鲜明对比——告警是全局的核弹。

内存高水位与磁盘告警是最后一道防线，不是日常流控。两条全局红线：

底层机制（告警这一层）：内存或磁盘告警一旦触发，broker 给所有携带 publish 的连接下达 channel.flow / 直接停止读取，整个集群范围内的生产全部冻结，直到资源回落到阈值以下自动解除。关键的两点：① 告警只冻结 publisher，不动 consumer——让消费继续排空队列，是它能自愈的前提；② 告警只阻塞、不丢消息、也不把消息换页丢弃。它是"踩了急刹"，不是"扔货减重"。这与某些系统"内存满了就丢老消息"的策略截然不同。

场景走查：消费者集体宕机，消息在队列里疯涨。先是 credit 流控把对应发布 channel 一条条减速（靶向）；堆积继续逼近 60% RAM，内存告警触发，整个集群所有生产连接被冻结，监控里 publish rate 瞬间归零、生产端线程卡在 send 上。运维重启消费者后队列开始排空，内存回落到水位线以下，告警自动解除，publish 恢复。全程没有一条消息丢失，代价是生产侧的一段冻结。

3.4quorum 队列与 Raft：多副本一致性

每个 quorum 队列本身就是一个 Raft 集群（建在 Ra 库上）：一个 leader、N 个 follower、一份复制的预写日志；publisher confirm 只在消息被提交到多数派（N/2 + 1）之后才返回。

底层机制（比文档深一层）：每个 quorum 队列是一个独立的 Raft 组，跑在 Ra（RabbitMQ 团队实现的 Raft 库）上。组里一个 leader 负责接收所有写入，N 个 follower 复制 leader 的预写日志（write-ahead log，每条消息是一条 log entry）。一条 publish 的流程：client 发给 leader → leader 追加到自己的 log → 并行复制给 followers → 当多数派（含 leader，共 N/2 + 1 个节点）都把这条 entry 写进各自的 log，这条 entry 被标记为 committed → leader 此时才向生产者回 confirm。confirm 的语义因此变成"已被多数派持久记录"，这正是 02 章 §2.3所指的那个 fsync/安全保证的来源。

故障与恢复：leader 宕机，剩余 follower 通过 Raft 选举在数百毫秒内选出新 leader，队列继续可用——只要多数派节点还活着。一个宕机后重新加入的节点，从它自己 log 的 offset 处续传缺失的 entry，不需要全量重新同步。这套行为是 Raft 算法保证的，不是 RabbitMQ 自己拼的。

这取代了 classic mirrored queues（镜像队列）。老的镜像队列用的是一套自研的链式复制协议——master 把消息异步推给 mirror，mirror 常常处于"未同步"（unsynchronised）状态，不是任何共识算法。网络分区下它的行为是未定义的：可能两边都自认 master，愈合时一边的数据被丢弃，造成真实的消息丢失。RabbitMQ 4.0 已彻底移除镜像队列（见 01 章 §1.5的过时配置警告）。quorum 队列把"多副本"从一个尽力而为的复制，升级成了有数学证明的多数派共识。

3.5Khepri 取代 Mnesia：元数据存储与消息存储

集群元数据（vhost、队列定义、binding、权限）的存储从 Mnesia 换成了基于 Raft 的 Khepri；网络分区下只有多数派分区继续推进，少数派暂停并在愈合后追平——且这个行为刻意不可配置。

元数据存储：Mnesia → Khepri 的世代更替

底层机制（比文档深一层）：Mnesia 是 Erlang 自带的分布式数据库，RabbitMQ 从诞生起一直用它存元数据。它的复制是点对点、无自动冲突解决的：网络分区时，两侧节点都还能各自写元数据（建队列、改 binding），愈合那一刻两份不一致的状态撞在一起，没有自动裁决谁对。官方给的两个缓解手段都不可靠——pause_minority（少数派暂停）在抖动网络里容易误判，autoheal（自动愈合）会挑一侧丢弃；而 pause_minority 触发恢复时甚至可能把整个元数据库 dump 出来再重灌一遍，代价高昂。

Khepri 是 RabbitMQ 团队新写的元数据存储，同样建在 Ra（即 quorum 队列用的那个 Raft 库）之上——元数据的每一次变更都走 Raft，提交到多数派才生效。分区时的行为因此变得确定：只有多数派那一侧能继续修改元数据，少数派一侧暂停元数据写入，等网络愈合后从 Raft 日志追平。和 pause_minority 不同，这不是一个可调的策略，而是 Raft 内建的、唯一的行为。

消息存储：4 KB 阈值与那道性能悬崖

底层机制（比文档深一层）：消息体存哪，取决于它和 queue_index_embed_msgs_below（默认 4 KB）的大小关系。大于该阈值的消息，写进每 vhost 共享的 message store——一组引用计数的段文件（segment files），多个队列引用同一份消息体时靠 ref-count 共享，所有引用都 ack 后才回收。小于阈值的消息，直接内嵌进每队列的 queue index（队列索引）。queue index 本身记录每条消息的位置 + 投递/ack 状态，是队列的账本。

这条 4 KB 线是一道真实的性能悬崖：小于 4 KB 的消息内嵌在索引里，无论 backlog 堆多深，单条消息占用的队列内存基本是常数——索引结构紧凑、可批量顺序刷盘。一旦消息超过 4 KB 走 message store，每条消息多一次间接引用、段文件的随机访问与回收开销随之而来。所以"把消息控制在 4 KB 以内"对深队列场景是实打实的优化，跨过这条线性能特征会变。（顺带：classic 队列那个"confirm 前未必 fsync"的窗口，02 章 §2.3所说，物理上就发生在这套 message store / queue index 的落盘时序里。）

# 当前生效值（默认 4096 字节）
rabbitmqctl eval 'application:get_env(rabbit, queue_index_embed_msgs_below).'
# => {ok, 4096}

# rabbitmq.conf 里调整：把 8 KB 以下的消息也内嵌进索引
# 收益：更多小消息走常数内存路径；代价：索引变大、单段刷盘更重
queue_index_embed_msgs_below = 8192