可靠投递：让消息的托管链不断裂

2.1发送端不丢：publisher confirms

publisher confirms 让 broker 在消息被处理后回一个确认，生产者据此知道这条消息已被托管，不是发进了黑洞。

底层机制（比文档深一层）：confirm 是异步且按 delivery tag 累进的。生产者在 channel 上开启 confirm 模式后，broker 给这条 channel 上发出的每条消息按发布顺序编号（从 1 递增的 delivery tag）。生产者不必发一条等一条——它持续 publish，broker 在消息"处理完成"时回 basic.ack，且可以批量确认：一个 basic.ack 带 multiple=true 表示"到这个 tag 为止全部确认"。所谓"处理完成"对持久化消息意味着"已写入"（写入的真实强度见 2.3，那里有一个关键的 fsync 缺口）；路由失败的消息走 basic.nack。生产者侧需维护一个"已发出未确认"的窗口，收到 ack 后从窗口移除，超时或 nack 则重发。

场景走查：一个支付回调服务每秒 publish 几千条结算消息。开启 confirm 模式后，它把每条消息的 delivery tag 和业务 ID 存进一个本地未决表，继续不停 publish。broker 陆续回 basic.ack(tag=4200, multiple=true)，服务一次性把 tag ≤ 4200 的记录从未决表清掉。某条消息的 routing key 拼错、无队列可达，broker 回 basic.nack(tag=4201)，服务据此告警并把这条转人工补偿——这条本来会被静默吞掉，现在看得见了。

channel.confirm_delivery()  # 开启 confirm 模式

def on_confirm(tag, multiple, nacked):
    # multiple=True 表示 tag 及之前的都确认；nacked=True 表示这是 nack
    if nacked:
        resend(pending.pop_le(tag))   # broker 拒收，重发
    else:
        pending.discard_le(tag)       # 已托管，从未决窗口移除

channel.add_on_confirm_callback(on_confirm)

for msg in stream:                    # 持续发布，不逐条阻塞等待
    channel.basic_publish("orders", msg.key, msg.body,
                          mandatory=True)   # 无队列可达就退回，不静默丢
    pending.add(channel.next_delivery_tag, msg)

上面的 mandatory=True 是 confirms 的搭档：confirms 回答"broker 收下了吗"，mandatory 回答"收下后有队列接吗"——无队列可路由时 broker 通过 basic.return 把消息退回生产者，而不是默默丢弃。两者合起来才覆盖 1.2 里那个"publish 成功 ≠ 进了队列"的缺口。

与下一节的关系：confirm 守住了消息进 broker 这一段。消息推给消费者之后，能不能不丢、会不会把消费者撑爆，是另外两个接缝。

2.2消费端不丢、不撑爆：consumer ack 与 prefetch

手动 ack 让 broker 在消费者真正处理完后才删除消息；prefetch 限定一次最多推几条未确认消息，防止单个消费者吞掉整条队列。

底层机制（比文档深一层）：prefetch 限的是一条 channel/consumer 上 Unacked 状态（见 1.4）的消息条数上限。broker 推一条，Unacked 计数 +1；消费者 ack 一条，计数 −1，broker 才补推下一条。所以 prefetch 和 ack 是同一个反馈环的两端：忘了 ack，Unacked 计数只增不减，撞到 prefetch 上限后 broker 停止投递——消费者就此"挂起"，但它其实没死，只是再也拿不到新消息。basic.nack 是 RabbitMQ 的扩展，支持 multiple（一次否定到某 tag 为止）和 requeue（退回还是丢弃）；basic.reject 功能相同但只能一次一条。注意 4.x 里全局 QoS（global prefetch）已弃用，prefetch 应按 per-consumer 设置。

prefetch 取值有量纲化的经验法则：prefetch ≈ 往返时延 / 单条处理时间。极端值 prefetch=1（入门教程"公平分发"的默认）把吞吐锁死在"每个网络往返才处理一条"——若 RTT 为 125ms，上限约 8 条/秒。实战起步给 10–50，消费者慢、消费者多时调小。

场景走查：四个消费者从一条订单队列取货，单条处理约 50ms，RTT 约 10ms。按经验法则 10/50 远小于 1，prefetch 给个位数即可，取 prefetch=5：每个消费者手里最多压 5 条未确认，broker 在它 ack 后即时补推，四个消费者负载基本均摊。若误设无限 prefetch，启动瞬间最快的那个消费者把上万条全拉进内存，自己 OOM 重启，重启后名下 Unacked 全部 requeue，又一次涌入下一个消费者——形成"击鼓传 OOM"。

channel.basic_qos(prefetch_count=5)   # per-consumer，最多 5 条 Unacked

def handle(ch, method, props, body):
    try:
        process(body)                              # 业务处理
        ch.basic_ack(method.delivery_tag)          # 处理完才确认 → broker 删除
    except TransientError:
        ch.basic_nack(method.delivery_tag, requeue=True)    # 可重试：退回队列
    except PoisonError:
        ch.basic_nack(method.delivery_tag, requeue=False)   # 必失败：走 DLX（见 2.4）

channel.basic_consume("orders", handle, auto_ack=False)   # 关键：不要自动 ack

与下一节的关系：confirm 和 ack 守的是"在线消息不丢"。但 broker 一旦重启或崩溃，内存里的队列和消息还在不在，是另一套机制——而且这里藏着本章最大的认知陷阱。

2.3重启与崩溃不丢：durable ≠ persistent ≠ safe

durable 是队列定义能否扛重启，persistent 是单条消息要不要落盘，两者都满足也未必扛得住崩溃——那要 quorum。

底层机制（比文档深一层）——本章最重要的一点：满足了 durable + persistent，仍有一个被多数教程跳过的缺口。classic 队列在回送 publisher confirm 之前，并不保证已经 fsync 到磁盘。持久化消息先进的是操作系统的写缓冲，broker 随即回 confirm，真正刷盘是稍后批量进行的（通常有一个 ≤200ms 的窗口）。如果 broker 正好在这个窗口内崩溃（断电、内核 panic、被 OOM kill），这条"durable + persistent + 已 confirm"的消息照样会丢——它从来没真正落到盘上。这就是为什么 quorum 队列存在：quorum 队列基于 Raft，写入要提交到多数派副本之后才回 confirm，单机崩溃由其余副本兜底，给出 durable+persistent 让人误以为自己早已拥有的那种持久性。Raft 的细节留到 03 章 3.4，这里只需记住缺口和补法。

场景走查：一个对账系统把队列声明为 durable、消息设 delivery_mode=2、开了 publisher confirms，自认为"零丢失"。压测中给 broker 断电，复盘发现丢了最后约 80ms 的已 confirm 消息。根因不是配置错，而是 classic 队列的 fsync 窗口：那 80ms 的消息回了 confirm 但还在 OS 写缓冲里，断电时一起没了。把队列换成 quorum 队列后重测，同样断电零丢失——因为每条消息在回 confirm 前已写入多数派节点。

与下一节的关系：消息存住了，但如果某条消息本身有毒——每次处理都失败——nack 重回队列会变成无限循环。把毒消息引开，是下一个接缝。

2.4毒消息不死循环：dead-letter、TTL、重试上限

dead-letter exchange 把被拒绝、过期或超限的消息引到另一个 exchange，而不是丢弃或无限重投；delivery-limit 给重试次数封顶。

底层机制（比文档深一层）：一个队列可以声明 x-dead-letter-exchange 指向一个 DLX。三类事件会让消息被死信化（dead-lettered）而非留在原队列：① 被 nack/reject 且 requeue=false；② TTL 到期（x-message-ttl 设在队列上、或单条消息设 expiration）；③ 超过队列长度上限 x-max-length 被挤出。被死信化的消息按原 routing key（或 DLX 配置的覆盖 key）路由进 DLX 绑定的队列。每死信一次，broker 在消息的 x-death 头里累加一条记录（次数、原因、时间、来源队列）——这是排查"这条消息怎么进的死信队列"的取证依据。quorum 队列还有一个内建的 delivery-limit：4.0 起默认值为 20，一条消息被重投 20 次后自动死信化，从机制上掐断毒消息的无限循环，无需手工拼 DLX 计数逻辑。

场景走查：订单队列消费时，某条消息因下游一个字段 schema 不兼容而每次反序列化都抛异常。消费者对它 nack(requeue=false)，消息进 DLX。DLX 绑了两条路径：可重试错误（如下游瞬时 503）进"重试队列"，该队列设 30s TTL，过期后再死信回主队列重试，x-death 计数每轮 +1；不可重试错误（如这次的 schema 不兼容）直接进"死信队列"等人工。即便误把它当可重试，quorum 队列的 delivery-limit=20 也会在第 20 次后强制把它打入终态，不会无限打转。

{
  "queue": "orders",
  "arguments": {
    "x-queue-type": "quorum",
    "x-dead-letter-exchange": "orders.dlx",
    "x-message-ttl": 600000,
    "x-max-length": 100000,
    "x-delivery-limit": 20
  }
}

与下一节的关系：前四节都在补"消息不丢"的接缝。但可靠性本身有反作用力——队列无限堆积会触发 broker 的自我保护，反而把整个集群的发送端按下暂停键。

2.5可靠性的反作用力：内存/磁盘告警与背压

为了不让自己被撑爆，broker 在内存或磁盘逼近水位线时会阻塞所有生产者——看起来像 publish 卡住，其实是设计中的背压。

底层机制（比文档深一层）：触发内存告警时，broker 在连接层停止从所有发布连接读取数据——TCP 接收窗口不再推进，生产者的 basic.publish 因此阻塞（或在异步客户端里收到 channel 的 blocked 通知）。这里有一个和 1.1 呼应的细节：阻塞作用在连接层级，所以一条连接上的所有 channel 一起被卡，不是只卡发往满队列的那一个；而且告警是集群级的——任一节点触发，整个集群的发布全停。消费连接不受影响，继续放水。这造成一个极具迷惑性的现象：发送端集体"卡住"，消费端却一切正常。

队列实现也影响堆积时的内存行为：经典的 lazy 模式（消息尽量留在磁盘、不常驻内存）和 quorum 队列在大积压下对内存更友好，能延后撞上水位线的时刻；但它们只是推迟而非取消告警——根治还得给队列设上界。

场景走查：一次发布上线把某个消费者服务的镜像配错，消费者全挂，但生产者还在全速 publish。一条队列在十几分钟内堆到几百万条，broker 内存撞上 60% 高水位，触发告警，集群所有发布连接被阻塞。值班同学看到"所有服务 publish 超时"，先怀疑网络和 broker 宕机，排查许久才在 management UI 看到内存告警和那条暴涨的队列。修复消费者镜像、队列被消费排空后，内存回落，发布阻塞自动解除。事后给该队列补了 x-max-length 和 DLX——再发生时超量消息进死信而非无限堆积，不再拖垮全集群。