这是一个"东西凭空消失"的事故,而且消失得无声无息,直到用户投诉才暴露。我们用消息队列(MQ)做订单的异步后续处理——用户下完单,主流程往 MQ 里发一条消息,然后下游的消费者收到消息,去做那些不那么紧急的后续事(发短信通知、给用户加积分、同步给其它系统等)。这套"用 MQ 解耦异步"的架构很常见、也很优雅。可上线一段时间后,陆续有用户反馈:"我下了单,怎么没收到短信?""我买了东西,积分怎么没加?"——而去查,订单本身是好好的、下单成功了,可那些后续处理,有一部分,就像从来没发生过一样,凭空消失了。
排查这个"消失的消息",让我对消息队列的"可靠性"有了脱胎换骨的认识。我一开始想当然地以为:消息发进 MQ 了,那 MQ 就一定会可靠地把它送到消费者手里、被处理掉——MQ 不就是干这个的吗?可真相是:一条消息,从"生产者发出"到"被消费者成功处理完"的整条链路上,有好几个环节,每一个环节,都可能让消息"丢掉";而默认情况下,这些环节往往都没有做"丢了不丢"的可靠性保证。具体说,消息可能丢在三个地方:一是生产者发了消息,但因为网络问题,MQ 服务器(broker)根本没收到,而生产者没开确认机制,以为自己发成功了;二是 broker 收到了消息,但还没来得及把它存到磁盘上,broker 自己就宕机重启了,内存里那条消息就没了;三是消费者拿到了消息、还没处理完(或处理失败了),却已经提前"确认"(ack)了这条消息,于是 MQ 以为它处理好了、把它删了,可它其实没被真正处理——消息也就丢了。这篇文章,就从这次"MQ 消息凭空丢失"的事故讲起,把消息队列可靠性这个"看似简单、实则处处是坑"的话题,讲清楚。
故障现场:消息可能丢在哪三个环节
先把这条消息从生到死的完整链路,和它可能"丢"的三个环节,理清楚:
一条消息的完整链路, 以及它可能丢失的三个环节:
[生产者] --①发送--> [MQ Broker] --③投递--> [消费者]
(②存储)
环节①: 生产者 → Broker (发送时丢)
生产者把消息发出去了, 但网络抖动/Broker故障, Broker没收到。
而生产者如果"发完就不管了"(没开确认), 它以为发成功了 → 消息丢了。
环节②: Broker 内部 (存储时丢)
Broker 收到了消息, 但消息只在内存里、还没落盘, Broker就宕机重启了。
重启后内存清空 → 那条没落盘的消息, 没了。
环节③: Broker → 消费者 (消费时丢)
消费者拿到了消息, 但"自动确认(auto-ack)"——它一拿到就告诉Broker"我收到了, 你删吧",
可它还没真正处理完(或处理时崩了), 消息已被Broker删除、不会重投 → 丢了。
核心: 消息的可靠, 是"端到端"的 —— 这三个环节, 任何一个不做保证, 消息都可能丢。
看明白这条消息可能"半路夭折"的三个地方了吗?我们最初的错误,是把"消息队列"想象成了一个"只要我把消息扔进去,它就一定能可靠送达"的黑盒;可实际上,消息的可靠传递,是一个"端到端"的工程——它需要"生产者、Broker、消费者"这三方,每一方都做好自己那一环的可靠性保证,缺了任何一环,消息都可能在那一环悄悄丢掉。而 MQ 的默认配置,出于性能考虑,这三个环节往往都"不那么可靠":生产者默认可能"发完不确认"、Broker 默认可能"不持久化"、消费者默认可能"自动确认"——于是,一条消息在这三道关里,处处都有丢失的风险。
而它最可怕的特征,和我之前遇到的好几个坑一样,是"静默":消息丢了,不报错、不抛异常、不崩溃——生产者以为自己发成功了,消费者那边只是"少收到了一条",一切看起来风平浪静。于是,那些丢失的后续处理(没发的短信、没加的积分),就这么悄无声息地"没发生",没有任何系统会主动告诉你"嘿,有条消息丢了"。直到用户那头发现"我怎么没收到短信",这个静默的损失才被动地暴露出来——而那时,你甚至很难知道,到底丢了多少、丢在了哪一环。这种"静默地丢数据"的事故,在所有 bug 里,都是最危险、最该被警惕的一类。
第一件事:理解消息可靠性是"端到端"的,三方都要保证
要避开这个坑,核心是建立一个根本认知:"消息不丢",不是 MQ 单方面就能保证的,而是需要"生产者、Broker、消费者"这三方协同保证的一个"端到端"的特性。就像一场接力赛,棒(消息)要顺利地从起点传到终点,需要每一个交接环节都不掉棒——任何一棒掉了,整场就废了。
消息可靠 = 三个环节都做好各自的保证(缺一不可):
环节①(生产者保证发到Broker): 用"发送确认(confirm/ack)机制"
生产者发完消息后, 要等 Broker 回一个"我收到了"的确认, 才算发成功;
没收到确认就重发 → 保证消息一定到达了 Broker。
环节②(Broker保证不丢): 开启"持久化"
Broker 收到消息后, 先把它落盘(存到磁盘)、再返回确认;
这样即便 Broker 宕机重启, 落盘的消息也还在 → 保证 Broker 不弄丢。
环节③(消费者保证处理完才算数): 用"手动确认(manual-ack)"
消费者别一拿到就自动确认; 而是【真正处理成功后】, 才手动 ack;
处理失败/没处理完就崩了 → 没ack → Broker会重新投递 → 保证消息被处理。
三环相扣: ①保证到Broker, ②保证Broker不丢, ③保证被处理 —— 缺一环都会丢。
关键认知是:消息队列的"可靠投递"(消息不丢),是一个需要生产者、Broker、消费者三方共同配合才能达成的、端到端的属性;它不是 MQ 默认就帮你做好了的"免费午餐",而是需要你在这三个环节,都显式地做好相应的可靠性配置。我那次的坑,根源就是把它当成了"免费午餐"——以为消息扔进 MQ 就万事大吉,完全没意识到这三个环节,每一个默认都可能丢消息、每一个都需要我去做保证。所以,用 MQ 时,要在脑子里清晰地装着这条"端到端"的链路:我的消息,从生产者到 Broker 到消费者,这三段路,每一段我都做好"不丢"的保证了吗?——只有这三段路都铺好了,你的消息,才能真正可靠地、不丢一条地,从起点送达终点。下面,就来逐一看这三个环节的具体保证措施。
第二件事:正解——三个环节,逐一上保险
知道了消息会丢在三个环节,解法就是给这三个环节逐一上保险:生产者用"发送确认"、Broker 开"持久化"、消费者用"手动确认"。三道保险都上齐,消息才能可靠。
// 环节①: 生产者 —— 开启发送确认, 确保消息真的到了 Broker
// (以 RabbitMQ 为例, 各 MQ 都有对应机制: Kafka 的 acks=all, RocketMQ 的同步发送+确认)
rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {
if (!ack) {
// Broker 没确认收到! 记录下来、重发, 别当它发成功了
log.error("消息未到达Broker, 重发: {}", cause);
resend(correlationData);
}
});
// 环节②: Broker / 队列 / 消息 —— 都设为持久化, 宕机重启也不丢
// 队列持久化 + 消息持久化(deliveryMode=2), Broker落盘后才算数
channel.queueDeclare("order.queue", /*durable*/ true, false, false, null);
// 发送时标记消息持久化:
new MessageProperties().setDeliveryMode(MessageDeliveryMode.PERSISTENT);
// 环节③: 消费者 —— 关闭自动确认, 改手动确认, 处理成功后才 ack
channel.basicConsume("order.queue", /*autoAck*/ false, (tag, msg) -> {
try {
process(msg); // 真正处理消息
channel.basicAck(msg.getDeliveryTag(), false); // 处理成功了, 才确认
} catch (Exception e) {
// 处理失败: 不 ack(或 nack), 让消息重新投递(或进死信队列)
channel.basicNack(msg.getDeliveryTag(), false, true);
}
});
这三道保险,分别堵住了那三个漏消息的环节:生产者的"发送确认"(RabbitMQ 的 confirm、Kafka 的 acks=all、RocketMQ 的同步发送)——它让生产者发完消息后,必须收到 Broker 回的"我收到并存好了"的确认,才认为发送成功;没收到确认就重发,从而堵住"环节①:发了但 Broker 没收到"的漏洞。Broker 的"持久化"——让队列和消息都落盘存储,Broker 收到消息先存磁盘再确认,这样即便它宕机重启,消息也还在,堵住"环节②:Broker 没存就宕机"的漏洞。消费者的"手动确认"——关闭"自动确认",改成"真正处理成功后才手动 ack";如果处理失败或还没处理完就崩了,因为没 ack,Broker 会把这条消息重新投递给别的(或重启后的)消费者,从而堵住"环节③:没处理完就被确认删除"的漏洞。三道保险全部上齐,这条消息从生产者到被消费者成功处理,每一步都有了"确认"和"持久化"的兜底,才能做到真正的"不丢"。我把这"三道保险"画成图:
这张图清晰地展示了"三道保险接力护送一条消息"的过程:发送确认保证它到 Broker、持久化保证 Broker 不弄丢、手动确认保证它被真正处理完——三道关层层把守,消息才能一条不少地、可靠地走完全程。任何一道关松了,消息就可能在那里悄悄溜走。
第三件事:可靠性的代价——它不是免费的
但这"三道保险"不是免费的,它们都有代价。可靠性,是用"性能"换来的——而这正是为什么 MQ 默认往往不开这些保险(默认追求性能)。理解这个权衡,才能做出适合自己业务的选择。
可靠性的代价: 每一道保险, 都牺牲一点性能/吞吐:
发送确认: 生产者要等 Broker 确认才算发成功 → 发送变慢(多一次往返)
持久化: Broker 收消息要先落盘(写磁盘)再确认 → 比纯内存慢得多
手动确认: 消费要处理完才确认 → 消息在Broker停留更久, 吞吐受影响
所以这是一个权衡:
要"高可靠"(消息绝不丢): 三道保险全开 → 性能/吞吐下降
要"高吞吐"(快, 但容忍偶尔丢一条): 适当关掉一些保险 → 快, 但有丢失风险
关键: 根据"业务对消息的重要程度", 来选择可靠性等级 ——
- 订单、支付、扣款类(绝不能丢): 三道保险全开, 宁可慢, 也要可靠
- 日志、监控、行为埋点类(丢一两条无所谓): 可以为了吞吐, 放松可靠性
这里的核心,是要认识到"可靠"和"性能/吞吐"之间存在一个权衡:那三道保险(确认、持久化),每一道都要付出额外的开销(多一次网络往返、多一次磁盘写),所以全部开启,会让 MQ 的吞吐和延迟都变差。这就是为什么 MQ 的默认配置往往偏向性能(不开或少开这些保险)——它假设你"如果需要可靠,会自己去开"。而做出正确选择的关键,是根据"你的消息有多重要、丢了的后果有多严重",来决定可靠性的等级:对于订单、支付、扣款这类"丢一条都是事故"的关键消息,就该把三道保险全部开满,宁可牺牲一些性能,也要保证它绝对不丢;而对于日志、监控、行为埋点这类"丢一两条无伤大雅"的消息,则完全可以为了更高的吞吐,适当地放松可靠性。不要一刀切——既不要为了追求极致性能,把关键消息的可靠性也牺牲了(像我那次);也不要为了"以防万一",给那些根本不重要的消息也全开保险、白白拖累性能。根据消息的重要程度,匹配恰当的可靠性等级,才是成熟的工程取舍。
第四件事:保证"不丢"的代价之一——可能"重复",所以要幂等
开了那三道保险,消息是"不丢"了,但带来了一个孪生问题:消息可能"重复"。因为"重发"和"重新投递"这两个保证"不丢"的机制,本身就可能让同一条消息被投递、被处理不止一次——比如消费者处理成功了、但 ack 还没发出去就崩了,Broker 没收到 ack,就会把这条消息再投一次,于是被处理两次。
// 保证"不丢"的机制(重发/重投), 会带来"重复" —— 所以消费端必须幂等
public void process(Message msg) {
String msgId = msg.getMessageId(); // 每条消息有唯一ID
// 用唯一ID去重: 这条消息处理过没?
if (processedLog.exists(msgId)) {
return; // 已处理过, 直接跳过, 不重复处理(防重复扣款/重复发短信)
}
doBusiness(msg); // 真正处理
processedLog.record(msgId); // 记一笔"已处理"
}
// 核心: 消息可靠投递的现实, 是"至少一次(at-least-once)" ——
// 保证不丢(至少送达一次), 但可能重复; 所以消费端必须做幂等, 来对付重复。
这里要建立一个对消息队列至关重要的认知——消息投递的几种语义:"最多一次(at-most-once,可能丢、不会重)"、"至少一次(at-least-once,不会丢、可能重)"、"恰好一次(exactly-once,不丢不重,理想但代价极高、难做到)"。而我们通过那三道保险实现的"不丢",本质上是"至少一次"——它保证消息至少被成功处理一次(不丢),但代价是它可能被处理不止一次(重复)。所以,"保证不丢"和"可能重复"是一对相伴而生的现实:你为了不丢消息而引入的重发、重投机制,恰恰是重复的来源。因此,一个可靠的消息消费端,在做到"不丢"(三道保险)的同时,还必须做到"幂等"——让同一条消息即便被处理多次,也只产生一次效果(用唯一消息ID去重),来对付那些不可避免的重复投递。(这又一次呼应了我之前反复强调的"幂等"——它真是分布式系统里的万金油。)记住这个组合拳:可靠的消息处理 = "三道保险保证不丢" + "消费端幂等容忍重复"——前者解决"少了",后者解决"多了",两者合起来,才是真正健壮的消息处理。把这三个环节的保险措施汇总成一张表:
| 环节 | 怎么会丢 | 保险措施 |
|---|---|---|
| 生产者→Broker | 发了但Broker没收到 | 发送确认(confirm/acks=all) |
| Broker存储 | 没落盘就宕机 | 队列+消息持久化 |
| Broker→消费者 | 没处理完就被确认删除 | 手动确认(处理成功才ack) |
| (副作用)重复投递 | 重发/重投导致处理多次 | 消费端幂等(唯一ID去重) |
| 处理一直失败 | 反复重投, 卡住队列 | 死信队列 + 告警人工处理 |
第五件事:还要兜底——死信队列与监控
三道保险加幂等,解决了"丢"和"重"。但还有两个工程上的兜底要做:处理"反复失败的消息"(死信队列),以及"主动发现问题"(监控)。
# 兜底1: 死信队列(Dead Letter Queue) —— 处理"反复失败"的消息
如果一条消息因为某种原因(数据有问题/下游一直挂)反复处理失败、反复重投,
它会一直卡在队列里, 还可能阻塞后面的消息。
→ 设一个"重试上限": 重投N次还失败, 就把它扔进"死信队列",
不再阻塞正常消息; 死信队列里的消息, 由人工/专门逻辑去排查处理。
# 兜底2: 监控 —— 让"积压"和"丢失"看得见
- 监控队列积压量: 消息进得多、出得少 → 积压, 说明消费跟不上, 要告警
- 监控消费失败率 / 死信队列堆积: 失败多说明处理有问题
- 对账机制: 定期核对"该处理的"和"实际处理的"是否一致, 发现静默丢失
(比如: 当天的订单数, 和当天加了积分的数, 对得上吗?)
# 关键: 别等用户投诉才知道消息出了问题, 要让问题主动暴露。
这两个兜底,补全了消息可靠的最后一块拼图:"死信队列"解决"反复失败的毒消息"——总有些消息因为数据本身有问题、或下游持续故障而反复处理失败,如果让它无限重投,它会一直卡在队列里、甚至阻塞后面正常的消息;所以要设一个重试上限,超过就把它转入"死信队列"隔离起来,既不阻塞正常流程,又保留下来供人工排查。"监控"则解决"静默问题主动暴露"——前面说过,消息丢失最可怕的是"静默",所以必须用监控这双眼睛盯着它:监控队列积压(消费跟不上)、监控消费失败率和死信堆积(处理出问题),尤其要做"对账"——定期核对"上游产生了多少该处理的事"和"下游实际处理了多少",两个数字对不上,就说明有消息静默丢失或没处理。这个"对账"机制特别重要,它是揪出"静默丢失"的终极防线——因为无论你前面的保险做得多好,在分布式的世界里都难保万无一失,而一个定期对账,能让任何漏网的静默丢失,都无所遁形地暴露出来,而不是等用户投诉。把"三道保险 + 幂等 + 死信队列 + 监控对账"都做齐,你的消息处理,才算真正构筑起了一套完整、健壮的可靠性体系。
一张"用 MQ 怎么保证消息可靠"的决策图
把这次踩坑沉淀成一张图。每当你用消息队列处理重要业务时,照着它把可靠性建好:
这张图的主线是:先按"消息重要程度"定可靠性等级;重要的就三道保险全开 + 消费端幂等 + 死信队列 + 监控对账。把这套体系搭齐,消息既不会丢(三道保险)、重复了也无害(幂等)、毒消息能隔离(死信队列)、出了问题能及时发现(监控对账)——这才是一套生产级的、健壮的消息可靠性方案。
我立下的几条 MQ 可靠性规矩
这次"消息凭空丢失"的事故后,团队用 MQ 的规范里加了这么几条:
- 消息可靠是端到端的:别以为扔进 MQ 就万事大吉,生产者、Broker、消费者三个环节都要做可靠性保证。
- 重要消息三道保险全开:订单支付等关键消息,生产者发送确认 + Broker 持久化 + 消费者手动确认,一个不能少。
- 消费端必须幂等:保证不丢的代价是可能重复,消费端用唯一消息ID去重,容忍重复投递。
- 按重要程度配可靠性:关键消息宁可慢也要可靠;日志埋点类可放松可靠性换吞吐,别一刀切。
- 配死信队列:设重试上限,反复失败的消息转入死信队列隔离,别让它阻塞正常消息。
- 监控积压与对账:监控队列积压、消费失败率,并定期对账"该处理的"和"实际处理的",揪出静默丢失。
- 警惕静默丢失:消息丢了不报错,最危险;主动用对账和监控让它暴露,别等用户投诉。
把消息可靠性的各种保证措施按"它防住什么"再归一张表,方便落地时逐项对照:
| 措施 | 防住什么问题 | 代价 |
|---|---|---|
| 发送确认 | 消息没到 Broker | 发送变慢 |
| 持久化 | Broker 宕机丢消息 | 写磁盘, 吞吐降 |
| 手动确认 | 没处理完就丢 | 消息停留久, 吞吐降 |
| 消费幂等 | 重复投递重复处理 | 需维护去重记录 |
| 死信队列 | 毒消息阻塞队列 | 需人工处理死信 |
| 监控对账 | 静默丢失无人知 | 需建对账机制 |
这几条规矩里,第一条"消息可靠是端到端的"是总纲,而我最深的体会是第七条背后的那份警觉。我这次的坑,和我之前踩过的好几个坑(批处理假完成、对账差一分钱、缓存返回旧值……)一样,本质都是"静默地出错"——系统不报错、不崩溃,只是悄悄地少做了、做错了一点什么,然后让这个错误,无声无息地流向远方。这类静默错误,是软件世界里最危险的敌人,因为它绕过了我们所有"等它报错就去修"的被动防御,只能靠我们主动地去验证、去对账、去核实,才能把它揪出来。所以,凡是涉及"重要数据、关键流程"的地方(消息、金额、订单……),都不能只依赖"它出错会报警"这种被动防御,而要主动地建立"对账、核验"机制——主动地去问一句:'我以为做成了的这件事,真的、完整地做成了吗?'——这种主动的较真,是对付一切静默错误的终极武器。
写在最后:可靠,从来不是默认的,而是设计出来的
这次消息丢失的经历,纠正了我一个根深蒂固的、对各种"中间件、基础设施"的天真期待。在那之前,我下意识里觉得:消息队列、数据库、缓存这些成熟的、大家都在用的基础设施,它们应该是"默认就很可靠"的——我用它,它就该帮我把事办得稳稳妥妥。可这次事故让我明白:这些基础设施,默认给你的,往往是"高性能"而非"高可靠"——因为可靠是有代价的(性能),而它们不知道你的业务需不需要为这份可靠付出这个代价,所以它们把选择权留给了你,默认选了性能。"可靠",不是它们白送你的赠品,而是需要你根据自己的业务、主动地去配置、去设计、去争取的东西。
想通这一点,我对"用好基础设施"有了更成熟的认识:用任何一个中间件,都不能想当然地假设它"默认就帮我处理好了一切",而要主动地去了解——它的默认行为是什么?在可靠性、一致性、性能这些维度上,它默认做了怎样的取舍?而我的业务,需要的是怎样的取舍?然后,显式地去配置它,让它的行为,匹配上我业务真正的需求。 MQ 默认不保证不丢(我得自己开三道保险);数据库默认的隔离级别可能不是我要的(我得自己调);缓存默认的过期策略可能引发雪崩(我得自己加抖动)……这些基础设施,都像一套功能强大、但需要你按需调校的精密仪器——它们给了你达成各种目标(高性能、高可靠、强一致)的能力,但具体要达成哪个目标、为它付出什么代价,需要你这个使用者,基于对业务的理解,亲手去设定。
所以,如果你也在用消息队列、或任何一个基础设施,我想把这次踩坑最想说的话送给你:请放下"它默认就很可靠"的天真假设,主动地去搞懂它的默认行为和各种配置选项,然后根据你业务的真实需求,显式地把它配置成你想要的样子。你的消息绝不能丢吗?那就把三道保险开满。你的数据要求强一致吗?那就调对隔离级别。可靠性、一致性这些至关重要的属性,从来不是基础设施"默认"白送给你的,而是需要你清醒地认识到它们的代价、并主动地为它们做出设计和取舍,才能真正拥有的。那些凭空消失的消息,最终教给我的,正是这份"可靠是设计出来的、不是默认就有的"的清醒——它让我明白,一个成熟的工程师,不会盲目地信任任何基础设施"默认就好",而会主动地去理解它、调校它,让它在自己的业务里,呈现出恰如其分的、可靠的样子。愿你我都能成为这样的工程师:不把可靠寄托于默认,而把可靠,亲手设计进系统的每一个环节里。
—— 别看了 · 2026