消息队列投递语义

可视化演示

展示At-most-once、At-least-once、Exactly-once三种投递语义对比、ACK确认重传机制与幂等性去重设计，支持模式切换。

投递语义总览

邮局送信要过两个关卡：发件人把信交给邮局，邮局再把信送到收件人手里。消息队列也一样，生产者将消息发给 MQ，MQ 再投递给消费者。消息在两端之间奔波时，网络可能抖动、机器可能宕机，这封信就可能“丢”在半路。我们用字母 p 表示一次投递的丢失率，那么一次投递成功的概率就是 1 减去 p。

MQ 的可靠性承诺，本质上就是在回答两个问题：信丢了怎么办？信重复了怎么办？ 平信（At-most-once）对这两个问题都不管不顾；挂号信（At-least-once）选择“丢了就补发”，代价是收件人可能收到多封；带编号的挂号信（Exactly-once）在补发的基础上增加一本登记簿，重复的信直接扔掉。三种语义各有代价：保护得越周全，消耗的资源就越多。

回到邮局场景：如果平信在途丢失的概率是 30%，那么 100 封信里大约有 30 封会石沉大海。后面你会看到，三种语义本质上都是在 p 不变的条件下，通过“是否重试”和“是否去重”来改变最终的可靠结果。

At-most-once：平信的洒脱

你寄出一封平信，邮局盖上邮戳就完事。信丢了？不知道，不补发，不追究。这就是 At-most-once 的世界观：消息最多被投递一次，发出去了就不再管结果。生产者把消息发给 MQ 后，既不等待确认，也不保存副本；MQ 把消息推给消费者，消费者处理完也不回执——整条链路“尽力而为”，任何一环失败，消息就悄无声息地消失了。

这种语义最典型的实现是“即发即弃”：生产者调用发送接口后立刻返回，MQ 尝试一次投递，无论消费者是否收到，流程都宣告结束。它不需要维护投递状态，不需要重试队列，内存占用极低，吞吐量极高。也正因如此，它的期望投递次数总是小于 1——每次发送都有一批消息注定奔赴“火葬场”。

哪些业务能接受这种“洒脱”？日志埋点、用户行为上报、监控指标采集。这些数据量巨大，偶尔丢几条无关痛痒——就像你不会为了一张广告传单的丢失而投诉邮局。用 At-most-once 换取极致的吞吐和极低的资源消耗，是性价比最优的选择。

At-least-once：挂号信的执着

挂号信服务在投递失败后会自动补发，直到收件人签收。但问题来了：如果第一封信其实送到了，只是签收单在回传途中弄丢了，邮局就会补发第二封——收件人不得不拆开两封一模一样的信。At-least-once 正是如此：消费者成功处理消息后，必须向 MQ 返回确认 ACK；若 MQ 在超时时间内没收到 ACK，就判定投递失败并重新发送。

这里的关键在于，MQ 无法区分“消息没送到”和“处理结果没传回来”。它只能基于确认超时做重试，因此重复投递成为必然的副作用。重试 n 次内至少成功一次的概率随着重试次数迅速趋近 1——这就是“至少一次”的数学底气。

At-least-once 支撑了绝大多数核心业务：订单状态通知、任务调度、短信/邮件推送。这些场景中，消息丢失的代价远高于消息重复——漏发一条订单超时提醒可能导致客户投诉，而重复提醒顶多让用户觉得“这系统有点啰嗦”。选择挂号信，就是选择“宁可多送，不可漏送”。

Exactly-once：唯一编号挂号信的魔法

现在邮局推出最高档服务：挂号信上印着唯一编号，收件人手里有一本登记簿。信到了先查编号——咦，这封信之前收到过？直接扔进垃圾箱；新编号？签收、登记、收下。于是无论邮局补发多少次，收件人实际打开的信恰好一次。这就是 Exactly-once 的全部秘密：它不是一种独立的传输机制，而是“At-least-once 投递 + 消费端幂等去重”的组合。

在 MQ 层面，Exactly-once 通常依然采用“发送 + ACK + 重试”的 At-least-once 模式，保证不丢；在消费者层面，业务系统通过幂等键去重，保证重复消息不会重复执行。真正让“恰好一次”成立的，不是 MQ 的某种神奇开关，而是那条贯穿投递路径的业务唯一标识——它像登记簿上的编号，把重复的洪水拦在业务门外。

支付扣款、红包发放、库存扣减、积分入账——这些场景中，重复执行的后果是资金损失和用户投诉，丢失同样不可接受。只有“恰好一次”能同时满足“不能少”和“不能多”两个苛刻要求。不过要记住：这份魔法不免费，它的成本就在下一节——你要亲手维护那本登记簿。

幂等消费设计：那本登记簿怎么做

收件人打开信箱，发现又来了一封编号为 “2024001“ 的信。他翻翻登记簿，上面已经写过这个编号，于是直接扔掉。幂等消费设计的核心，就是维护这样一本”编号登记簿”，用唯一的业务键识别每条重复消息。这个业务键可以是订单号、支付流水号、用户操作 ID，或者 MQ 消息自带的 MessageID——总之，它是那条消息指纹性的东西。

最常见的实现方法有三种。第一，数据库唯一索引：在业务表中为幂等键建立唯一约束，重复插入直接报错或返回 0 行影响，天然具备原子性。第二，Redis SETNX 原子操作：以幂等键为 Key，首次设置成功才执行业务，命令本身是原子的，高并发下不会出现两个线程同时通过判定。第三，状态机前置查询：处理前先查业务状态，若已是“已处理”则直接返回成功。无论哪种方案，都必须保证“检查”与“执行”之间的原子性——否则两个线程可能同时通过检查，同时执行业务。

需要注意的是，Redis 去重表的过期时间要大于消息最大重试周期，否则登记簿上的编号被擦除后，重复消息又会漏进来；数据库唯一索引则不存在这个问题，所以资金类操作建议以数据库唯一索引为主、Redis 为辅。登记簿做得越扎实，“恰好一次”的承诺就越值得信赖。

事务消息机制：发信前的“押金”

如果发件人想保证“钱扣了，信一定发出去”或者“钱没扣，信绝不发出”，该怎么办？普通平信和挂号信都不够用——它们只管投递，不管发件人的业务一致性。此时需要引入事务消息。它的玩法类似“押金模式”：发件人先向邮局交一笔押金（发送半消息），邮局将信暂存在仓库，暂不投递；紧接着发件人执行本地业务事务，比如扣款。本地事务成功后，通知邮局“可以送信了”，信才真正寄出；本地事务回滚，则通知邮局“取消寄送”，仓库里的信作废。

这中间有个精妙的设计：半消息。它在本地事务提交前不可见，消费者永远消费不到“未提交”的消息。如果发件人提交本地事务后忘记通知邮局了呢？邮局会主动回查发件人的事务状态——问一句“你那边到底成功没有？”以此兜底，避免消息永久滞留仓库。这样，本地事务与消息发送就绑成了原子操作。

事务消息解决的是生产端的原子性问题：比如电商下单时“扣库存 + 发消息通知仓库”必须同生共死。它常与 At-least-once 搭配——MQ 投递阶段仍靠重试保证不丢，消费端再靠幂等保证不重。这样从生产端到消费端，整条链路的可靠性才算闭环。

投递语义选型：按信的价值选服务

给朋友寄生日贺卡，用平信就够；寄房产过户文件，你恨不得用带卫星定位的保险箱。投递语义的选型没有银弹，一切都取决于消息背后的业务价值。当消息丢失带来的损失远大于重复处理的开销时，选 At-least-once；当重复执行的后果同样不可接受时，选 Exactly-once；当数据量大且对丢失不敏感时，At-most-once 是省钱的智慧。

多个因素需要综合权衡：业务容忍度（丢了是否致命？重复是否致命）、性能预算（重试和幂等会消耗 CPU、存储和网络）、下游能力（消费者是否方便实现幂等）、端到端延迟（At-most 延迟最低，Exactly 因重试和幂等开销最高）。我们可以用一个小模型来描述这个决策：设 λ 为业务权重，R 为可靠性收益，C_loss 为丢失成本，C_dup 为重复成本，则选择使总效用最大化的语义。

最终落地时，成熟系统通常采用混合策略：日志走 At-most-once，任务与通知走 At-least-once，资金与库存走 Exactly-once。这就像一家邮局同时提供平信、挂号信和带编号的挂号信——不同类型的邮件，选择不同的服务，用最合理的成本达成最可靠的投递。

AI 应用场景

Python 演示

import random  class Message:    def __init__(self, mid, payload):        self.mid = mid        self.payload = payload  class FakeMQ:    """模拟一个会丢消息、会丢 ACK 的消息队列"""     def __init__(self, loss_rate=0.15, ack_loss_rate=0.1, max_retry=5):        self.loss_rate = loss_rate        self.ack_loss_rate = ack_loss_rate        self.max_retry = max_retry        self.attempts = 0     def _try_send(self):        self.attempts += 1        return random.random() >= self.loss_rate     def at_most_once(self, msg, service):        if self._try_send():            service.handle(msg)     def at_least_once(self, msg, service):        for _ in range(self.max_retry):            if self._try_send():                service.handle(msg)                if random.random() >= self.ack_loss_rate:                    return                # ack 丢失, broker 误以为投递失败, 继续重发  class PlainService:    """无幂等保护: 消息到一次, 业务执行一次"""     def __init__(self):        self.count = 0     def handle(self, msg):        self.count += 1  class DedupService:    """带去重表: 同一订单号只执行业务一次"""     def __init__(self):        self.done = set()        self.count = 0        self.repeat = 0     def handle(self, msg):        if msg.mid in self.done:            self.repeat += 1            return        self.done.add(msg.mid)        self.count += 1  def run(trials=100, loss=0.15, ack_loss=0.1):    random.seed(7)    msgs = [Message(i, "扣款") for i in range(trials)]     mq0 = FakeMQ(loss, ack_loss)    s0 = PlainService()    for m in msgs:        mq0.at_most_once(m, s0)     mq1 = FakeMQ(loss, ack_loss)    s1 = PlainService()    for m in msgs:        mq1.at_least_once(m, s1)     mq2 = FakeMQ(loss, ack_loss)    s2 = DedupService()    for m in msgs:        mq2.at_least_once(m, s2)     print("订单总数: %d" % trials)    print("At-most-once 业务执行: %d 次 (丢失 %d 笔订单)" % (s0.count, trials - s0.count))    print("At-least-once 业务执行: %d 次 (多执行 %d 次)" % (s1.count, s1.count - trials))    print("Exactly-once  业务执行: %d 次 (重复消息 %d 条被拦截)" % (s2.count, s2.repeat))    print("MQ 发送尝试次数: at-most=%d at-least=%d exactly=%d"          % (mq0.attempts, mq1.attempts, mq2.attempts))  if __name__ == "__main__":    run(trials=100, loss=0.15, ack_loss=0.1)

1. def _try_send(self):底层发送函数，以 loss_rate 概率随机丢件，真实 MQ 中对应网络故障或节点宕机。
2. if random.random() >= self.ack_loss_rate:模拟消费者处理成功但 ACK 回传丢失的场景，这是 At-least-once 重复投递的根源。
3. self.attempts += 1统计 MQ 的总发送尝试次数，用于对比三种语义对网络资源的消耗差异。
4. if msg.mid in self.done:去重表的判重逻辑，同一业务键已处理过，直接拦截重复消息。
5. self.done.add(msg.mid)处理前先登记业务键，确保“检查”与“登记”在单线程下保持原子性。

常见误区

面试题