GreedyAbyss搞分布式系统的朋友，迟早会撞上这么一个问题：服务拆了，数据库也分了，但一个业务动作往往要跨好几个服务配合完成，这时候同步调用根本撑不住。订单系统要扣库存、走支付、发通知，每个环节都同步等结果，只要最慢的那个服务抖动一下，整条链路就跟着卡死。消息投递和异步通信就是为了解决这类问题而存在的，它可以帮我们把服务之间的耦合彻底打散。但这篇文章不是来给你背概念的，我想从实际构建的角度出发，把分布式系统里"消息可靠地从A到B"这件事讲透，包括中间件怎么选、ACK怎么确认、重试和幂等怎么设计、消息堆积怎么排查，以及和分布式事务怎么配合。如果你是正在做微服务改造、或者刚接手消息队列相关系统的开发，这篇应该能给你不少可直接落地的思路。
1. 异步通信的初衷：分布式系统里同步调用的天花板
1.1 同步调用为什么会成为瓶颈
我在不少团队里见过同一种架构演进路径：一开始所有逻辑写在一个单体应用里，一个函数调另一个函数，简单直接。后来业务复杂了，开始拆服务，服务之间用 HTTP 或 RPC 同步调用，看起来也还行。直到某个大促或者流量高峰来临，问题就集体爆发。
首先受冲击的是调用链的尾部服务。比如一个创建订单接口，要调库存服务、优惠券服务、用户积分服务、消息通知服务，每一个都是同步请求。假设每个服务本身的响应时间都在 50ms 左右，四个服务串下来就是 200ms。这只是理想情况，一旦某个服务因为数据库慢查询涨到 1 秒，整个接口就卡在 1 秒以上，用户直接超时。
更麻烦的是线程池线程被阻塞后，会像雪崩一样传染。Tomcat 默认开启 200 个线程，如果这 200 个线程全部阻塞在等待下游响应上，新的请求只能排队，而排队的请求又会占用更多资源，最终导致整个容器假死。
我带你算笔账：一个支付回调服务，QPS 峰值 1000，下游通知服务平均耗时 300ms。为了保证不丢请求，至少需要同时有 300 个线程在等待下游返回。如果是纯同步模型，这 300 个线程就是硬性成本，不仅吃内存，还得在代码里疯狂调连接池和超时时间，稍微调不好就是连锁故障。同步调用的天花板，本质就是"所有服务的实时可用性相乘"这个约束，任何一个环节掉链子，整体就掉链子。
1.2 消息队列插进来之后发生了什么
引入消息队列之后，生产者和消费者的生命周期解耦了。订单服务创建订单后，只需要把"订单已创建"这个消息投递到 Broker，然后立刻返回成功，耗时可以降到 10ms 以内。至于库存、积分、通知这些环节，各自去消费消息，谁快谁慢互不影响。
这里的关键是，消息队列成了中间的缓冲区，它不仅解耦了服务的依赖，还消峰了流量的波动。比如秒杀场景，瞬间涌入的 10 万请求全打到数据库肯定挂了，但通过队列做个缓冲，消费者按自己的处理能力慢慢消费，系统就不会被瞬时流量击穿。
不过，把同步调用改成异步消息，不是简单地换一个 HTTP 客户端那么简单。它引入了一组新的复杂度：消息会不会丢？会不会重复？消费者挂了怎么办？消息投递的语义到底该如何保证？这就是整篇文章要展开的东西。
1.3 异步和并发的本质区别
很多刚接触分布式的同学会混淆异步和并发。并发是我同时发起 5 个同步调用，然后等它们全部返回，依然是"同步等待"的模型，只是等待的时间从串行叠加变成最慢的那一个。异步则是发起方完全不等待结果，它把"要不要处理、什么时候处理"的决定权交给了消费者。
打个比方，同步调用就像你在柜台办业务，一直排着队等柜员处理完才走；并发是你同时排了五个窗口，但依然要等五个窗口全部办完；异步则是你把材料投进信箱，信箱什么时候被开、谁来处理，跟你没有关系了，你只需要保证材料投递成功即可。
投递成功了就够了吗？当然不够。被投递的消息可能会在运输途中遗落、可能被重复投递、可能在消费者手里处理失败。这正好引出消息投递语义这个话题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 消息投递的三种语义：从 At-most-once 到 Exactly-once 的取舍逻辑
2.1 三类投递语义的定义与适用场景
在做任何消息系统的方案讨论之前，必须先统一概念。消息投递语义通常分三种：
| 投递语义 | 含义 | 丢失风险 | 重复风险 | 典型场景 |
|---|---|---|---|---|
| At-most-once（至多一次） | 消息可能丢失，但不会重复 | 高 | 无 | 非关键日志、监控指标采集 |
| At-least-once（至少一次） | 消息不会丢失，但可能重复 | 低 | 高 | 订单状态变更、积分变更、库存扣减 |
| Exactly-once（恰好一次） | 消息不丢且不重 | 极低 | 极低 | 金融转账、支付对账 |
At-most-once 是"尽力而为"，发出去就不管了，网络一抖消息可能就没了。适合对数据完整性不敏感的场景，比如采集某个页面访问量的日志，少几条统计无伤大雅。
At-least-once 是大多数消息中间件的默认保证。Broker 收到消息后先落盘，再给生产者回 ACK；消费者消费完再给 Broker 回 ACK，Broker 收到 ACK 才确认这条消息可以被删除。如果 ACK 在网络传输中丢失，Broker 就会重新把消息发给消费者，于是出现重复消费。
Exactly-once 是理论上的"完美语义"，但在分布式环境下，真正做到的成本极高。它不仅要求消息系统本身可靠，还需要消费者端配合做幂等处理，或者引入分布式事务协调器。下文我会详细展开。
2.2 重复消息是从哪冒出来的
很多人第一次遇到重复消费会很困惑：我明明在消费者里加了日志，发现同一条消息被消费了两次。这实际上不是"做了两次"，而是"投递了两次"。消息中间件的重复投递通常有三种来源：
第一，生产者重试。生产者在发送消息时，如果迟迟没有收到 Broker 的 ACK，它不能确定是消息丢了还是 ACK 丢了，于是会重发。如果 ACK 其实已经到了，只是网络延迟，Broker 就会收到两条一模一样的消息。
第二，消费者提交 ACK 失败。消费者处理完业务逻辑之后，向 Broker 提交 ACK 时网络断了、进程重启了，Broker 以为消费失败，就会重新投递这条消息。
第三，分区再均衡。Kafka 里一个消费者挂掉或新消费者加入，会触发 Rebalance，正在处理的那些消息可能没来得及提交 offset，Rebalance 之后，别的消费者会重新消费这些分区。
所以，与其追求"系统保证不重复"，不如在设计之初就默认"消息一定会重复"，把幂等处理做进消费逻辑里。这也是业界普遍的实践原则。
2.3 为什么"至少一次+幂等"是默认方案
你可能会问，既然 Exactly-once 最完美，为什么大家默认用 At-least-once 加幂等，而不是直接选 Exactly-once？
关键在于成本和收益不对等。真正实现 Exactly-once，需要在消息生产端、Broker 端、消费端三方都引入强一致机制。比如 Kafka 的 EOS（Exactly-once Semantics）依赖事务协调器和幂等生产者，它保证了在同一事务内的多个分区写入要么全部成功要么全部失败，但代价是吞吐量明显下降，而且限制非常多。对于大部分业务系统来说，数据不能丢、但网络或进程异常导致的极小概率重复，完全可以通过消费者做幂等来兜住，成本低、可控性强。
以最常见的订单取消场景为例：用户取消订单，订单系统发一条"取消通知"消息，积分服务消费它并返还积分。如果这条消息重复投递了两遍，积分返还逻辑就必须保证第二遍执行不产生二次返还。怎么保证？还是那句老话：在消费端把"重复消费但幂等安全"当成默认假设来设计。
3. 构建可靠投递的关键环节：ACK、重试、幂等与死信队列
3.1 消费者确认机制的正确配置
消费者确认方式，是消息可靠性设计里最容易踩坑的地带。以 Kafka 为例，消费者消费消息后要提交 offset，告诉 Broker"我处理完了，可以继续了"。如果使用自动提交 enable.auto.commit=true，消费者会在后台周期性提交 offset，一旦消费者在业务逻辑执行到一半时崩溃，offset 可能已经提交了，但消息实际没处理完，这条消息就"丢了"。
所以生产环境里，我极其不建议开启自动提交，除非你的业务根本不在乎丢消息。更稳的方式是手动提交：在消息处理成功之后再调用 commitSync() 或者 commitAsync()，让消息处理和 offset 提交之间建立明确的因果关系。
手动提交也要区分时机。如果你的业务里，消息本身要写入数据库，那么更好的做法不是"先处理业务再提交 offset"，而是采用"业务写入和 offset 提交在同一事务里"的模式。但 Kafka 的 offset 存储在内部 topic，没法直接和业务数据库事务绑定，就需要靠消费者自己做补偿。
RabbitMQ 里也有类似的机制，它用的是 BasicAck 确认。值得注意的是，RabbitMQ 的消费者如果在没有 ack 的情况下退出，那个 unacked 消息会被重新投递到队列；如果你开着 autoAck=false 但处理完忘了 ack，消息就会在队列里越积越多，直到内存被 unacked 消息吃满。
这里我总结了几个必须注意确认配置的点：
- 关闭消费者自动提交/自动 ACK，改为业务处理成功后手动提交。
- 提交失败要有重试和告警，不能静默失败。
- 如果消息处理和数据库写入混合，优先考虑"先写业务库，提交标记入库，再提交 offset"的三段式流程。
- 消费逻辑必须保证幂等，不能依赖"只投递一次"的假设。
3.2 重试策略怎么设计才不"致命"
消息消费失败后，直接丢弃是不可能的，至少要给几次重试机会。但重试不是无脑循环，很多线上事故就是"重试风暴"引发的：一条消息处理失败，消费者立刻重试，重试又失败，再重试，把下游服务彻底打垮。
合理的设计是"有限次重试 + 退避间隔 + 最终进死信队列"。所谓退避间隔，是指重试时间间隔指数增长，比如第一次失败后等 1 秒，第二次等 2 秒，第三次等 4 秒，最多重试 5 次，之后就不要再折磨下游了。
具体到代码层面，Kafka 的消费者需要自己实现重试调度，RocketMQ 则内置了重试队列，消息消费失败后会进入 %RETRY% 开头的重试主题，支持按次数和延迟级别重试。RabbitMQ 需要通过死信交换机和延迟插件配合实现有限重试。
我在实际项目里更常用的一种模式是"本地重试 + 延迟重试"两层：第一层，消息拉取后，在消费者进程内部做最多 3 次快速重试，每次都带固定间隔，适用于偶发性的数据库连接抖动；第二层，超过 3 次后把消息重新投递给一个延迟队列，让它过 10 分钟后再进入主消费流程，这时候下游服务大概率已经恢复。
3.3 幂等设计：重复消息的最终防线
幂等是消息消费设计的核心，设计得好不好直接决定数据一致性。常见手段有三种。
第一种，基于数据库唯一约束。比如消费消息要插入一条"积分流水"，可以把业务订单号设成唯一索引。第一条消息插入成功，第二条重复消息插入时触发唯一键冲突，直接捕获这个异常，当作"已消费"跳过即可。这套方案简单可靠，前提是业务表能被改造出唯一键。
第二种，基于 Redis 和状态标记。比如在消费前先查 Redis，如果 key 已经存在且值为 processed，直接返回；否则执行业务逻辑，执行完成后写入 key。但这里有个陷阱：查 Redis 和执行业务逻辑不是原子的，两个消费者并发处理同一条消息时，可能同时查到"未处理"，然后重复执行。所以更好的做法是用 Redis 的 SETNX 或者 Lua 脚本来保证"标记-执行"的原子性。
第三种，基于数据库状态机。比如订单状态只有合法的迁移路径：待支付→已支付→已取消。如果一条重复消息试图把"已支付"的订单改成"已支付"，状态机校验不通过，自然就拦截了。这套方案比唯一索引更优雅，因为它不依赖业务字段，但需要状态机框架支持。
下面放一段简单的幂等消费伪代码，用 Redis 做处理记录，同时用数据库唯一索引做兜底：
java复制public void consume(OrderMessage message) {
String key = "order:processed:" + message.getOrderNo();
// 原子设置，避免并发重复消费
boolean first = redisTemplate.opsForValue()
.setIfAbsent(key, "1", Duration.ofHours(24));
if (!first) {
// 已经处理过，直接确认
log.info("duplicate order message ignored, orderNo={}", message.getOrderNo());
return;
}
try {
orderService.processFromMessage(message);
} catch (Exception e) {
// 业务失败要回滚 Redis 标记，否则后续不再重试
redisTemplate.delete(key);
throw e;
}
}
这里注意，setIfAbsent 成功之后，业务执行失败必须把标记删掉，否则消息重试的时候会被误判为"已处理"而直接跳过，造成真实数据丢失。我在生产环境里见过不少这种坑，一删就全局雪崩。
3.4 死信队列与消费失败兜底
重试次数用完仍然失败的消息，不应该被无限重试折磨，也不应该直接丢弃，而是进入死信队列（Dead Letter Queue）。死信队列本质上是"重试后的告警区"，它把那些"我怎么都处理不了的消息"单独存起来，等待人工介入。
Kafka 里通常需要自己实现死信主题，消费者在重试依然失败后，把消息重新发送到一个 xxx-dlq 主题，同时记录原始消息头里带的业务 ID。RabbitMQ 原生支持死信交换器，通过 x-dead-letter-exchange 和 x-message-ttl 可以非常方便地把消费失败的过期消息路由到 DLQ。RocketMQ 则是消费失败消息在达到最大重试次数后，自动进入死信队列。
死信队列不只是"放着"就够了，需要配套监控。我的习惯是给死信主题配置一条小时级消费任务，统计死信量并做趋势告警，同时提供一个管理后台可以查看死信消息内容、手动重放或人工修复后投递。没有监控的死信队列，最终会变成无人问津的"垃圾场"，等到数据对账才发现大量消息悄悄消失了。
4. 主流消息中间件的可靠性机制对比：Kafka、RabbitMQ 与 RocketMQ 的落地差异
4.1 Kafka 的日志语义与 ISR 机制
Kafka 的核心模型是分区日志，消息按 offset 顺序追加。它的可靠性设计围绕两个层面展开：生产端通过 acks 参数控制写入副本的确认策略，消费端通过 offset 管理控制消费进度。
acks=0 表示生产端不等任何副本确认，消息发出去就当成功，吞吐最高但可能丢消息；acks=1 表示 leader 副本写入就确认，如果 leader 宕机且数据没来得及同步到 follower，消息会丢；acks=all 表示等待所有 ISR（In-Sync Replicas）写入成功后再确认，此时还得配合 min.insync.replicas 参数，比如设置成 2，表示至少有两个副本写入成功才算成功，这样才能真正降低消息丢失的风险。
很多人以为 acks=all 就万无一失，其实还有一个前提：Broker 的 unclean.leader.election.enable=false，这个参数如果不关，当 leader 宕机时，Kafka 可能会选举一个数据落后很多的 ISR 之外的副本成为新 leader，那些还没同步过来的消息就永久丢失了。这部分配置在生产环境里必须一起调整，不能只调 acks。
4.2 RabbitMQ 的确认模型与镜像队列
RabbitMQ 是面向队列和路由的传统消息中间件。它通过生产端的 publisher confirm 机制和消费端的 manual ack 机制来保证可靠性。
生产端设置 publisher-confirms=true 后，生产者发送消息可以异步等待 Broker 回执，Broker 在消息落盘成功后返回 basic.ack，如果投递失败则返回 basic.nack。消费端和 Kafka 类似，手动确认模式下消费者处理完消息后必须调用 basicAck 通知 Broker 删除消息。
RabbitMQ 的问题在于它默认不是分布式架构，单节点故障会导致整个队列不可用。虽然有镜像队列和仲裁队列来提供高可用，但跟 Kafka 的原生分区多副本机制相比，它在应对大规模集群时的扩展性还是偏弱。所以 RabbitMQ 更适合企业内部服务数量中等、流量可控、路由规则复杂的业务，不太适合做海量日志或超大吞吐的管道。
4.3 RocketMQ 的事务消息与重试队列
RocketMQ 是阿里巴巴开源的消息中间件，它在业务系统各种极端场景下打磨得相当完善。RocketMQ 在可靠性方面最有特色的两个设计是事务消息和延迟消息。
事务消息的典型流程是这样：生产者先发送一条"half message"到 Broker，这条消息此时不可被消费者看到；然后生产者执行本地数据库事务；本地事务成功，就向 Broker 提交 commit 状态，消息变为可消费状态；本地事务失败，就回滚消息。如果生产者执行完本地事务但没来得及提交状态就崩溃了，Broker 会通过"事务反查"接口回查生产者的本地事务结果，从而决定消息最终是提交还是回滚。
RocketMQ 的消费端重试也做得比较完善，消费失败的消息会进入重试主题，按照预设的时间梯度（比如 1s、5s、10s、30s、1m...）逐步重试，超过最大次数后自动进入死信队列。在业务消息领域，RocketMQ 是很多团队的首选，因为它的业务语义比 Kafka 直接得多。
4.4 选型思路与我的实践经验
选型从来不是选最好，而是选最契合场景的。我用一张表帮你理一下：
| 维度 | Kafka | RabbitMQ | RocketMQ |
|---|---|---|---|
| 核心优势 | 高吞吐、水平扩展、日志型流处理 | 功能丰富、路由灵活、易上手 | 事务消息、延迟消息、业务语义完善 |
| 可靠性机制 | ISR 副本、acks、offset | 发布确认、消费者确认、镜像队列 | 事务消息、重试队列、死信队列 |
| 吞吐量 | 百万级/秒 | 万级/秒 | 十万级/秒 |
| 典型场景 | 日志采集、实时计算、事件流 | 企业内部服务解耦、任务分发 | 交易消息、订单业务、最终一致性场景 |
| 运维复杂度 | 中等（依赖 ZooKeeper/KRaft） | 低 | 中等 |
我的实践体会是：如果业务场景是标准的"服务 A 发消息给服务 B 去消费"，而且消息量在每秒几万条以内，RabbitMQ 完全够用，没必要上 Kafka 增加运维复杂度；如果核心诉求是海量吞吐、流式计算、日志管道，Kafka 是绕不开的选择；如果业务涉及订单、支付、积分等跨服务状态变更，又需要事务消息来保证最终一致性，RocketMQ 的产消体验最好。
5. 从生产实践看消息乱序、堆积与重复消费的排查链路
5.1 消息乱序的根源与排队策略
消息乱序这个问题，很多团队是上线之后才发现的。比如一个订单的"创建"消息和"取消"消息被先后投递，消费端却先处理了"取消"，再去处理"创建"，最后订单状态错乱。
乱序的根源通常有三个：
第一，同一业务 Key 的消息被发送到不同的分区。Kafka 中只有同一个分区内的消息才有顺序保证，如果生产者没有把同一订单号的消息路由到同一个分区，消费端自然无法保证顺序。解决方法是设置消息 Key，比如按订单号取哈希，保证同一订单的消息进入同一个分区。
第二，消费端多线程并发消费。即使消息在同一个分区，如果你开了多线程去消费，仍然可能乱序。因为线程调度是不确定的，先到的不一定先执行完。这时候需要引入"按 Key 串行化"的机制，比如使用线程池时按 Key 哈希分配到固定线程。
第三，重试导致顺序错位。消息 A 消费失败进入重试队列，消息 B 正常消费完成，等 A 重试成功后，处理顺序就反了。对这种场景，需要业务上做取舍，比如取消消息晚到后，要先判断当前订单状态是否还允许执行"创建"操作，不允许就跳过，这本质上又回归到了状态机幂等。
5.2 消息堆积：消费能力是瓶颈
消息堆积是最容易发现、也最考验排查功力的问题。堆积的直接表现是消费延迟 (Consumer Lag) 不断上涨，Kafka 里可以通过 kafka-consumer-groups --describe --group xxx 看到每个分区的 lag，RocketMQ 控制台也有消费进度查询。
排查堆积，我一般按这个链路走：
第一步，先确认是单个消费者堆积还是所有消费者堆积。如果是单个消费者堆积，极大概率是这个消费者的分区分配不均，或者它消费的那一批消息里有一条"毒消息"卡住了整个消费流程，导致后续消息全部排队。这种情况要重点检查消费代码里有没有未捕获的异常或死循环。
第二步，看下游服务的响应耗时。消息消费缓慢，本质上是下游处理能力不足。比如消费者每处理一条消息都要调用一次第三方 HTTP 接口，而这个接口响应从 100ms 涨到 2s，消费能力就会下降 20 倍。用 APM 工具看消费链路每个环节的耗时占比，问题一目了然。
第三步，扩容消费者。Kafka 的消费者数量不能超过分区数量，否则多出来的消费者会闲置，所以如果分区数不够，先增加分区，再增加消费者。RocketMQ 对消费者数量的约束相对宽松一些，但队列数依然是瓶颈。扩容前要评估下游能否扛住压力，否则堆积可能从消息系统转移到数据库。
还有一种临时方案：如果堆积量级极大（比如积压了上亿条消息），就不要执着于按原逻辑一条条消费了，可以把堆积的消息先转存到临时存储或临时 Topic，分流一部分到独立的消费集群慢慢处理，先把核心链路的数据消费恢复到实时状态。
5.3 重复消费：最隐蔽的数据不一致来源
我用一个亲身踩过的坑来聊重复消费。当时我们有一个库存扣减服务，消费订单消息时先查库存，如果足够就执行扣减。某次运维重启了消费者，恰好有一批消息在处理中但没来得及提交 offset，重启后这些消息被重新拉取消费。结果库存被扣减了两次，直到对账才发现数据对不上。
排查这类问题，重要的不是找到"为什么重复"，而是找到"为什么重复会导致数据错"。因为重复消费无法完全避免，我们只能让数据在重复消费时保持安全。
我总结了一套排查重复消费问题的三步法：
- 打开消费日志，看同一业务 ID 是否被消费两次。通过 traceId 或者 messageId 建立消费链路日志，在每次消费时打印入库前的关键数据快照。
- 检查消费业务是否有对应的唯一约束或状态校验。如果没有，那就不是"偶发问题"，而是设计缺陷。
- 确认幂等逻辑的覆盖范围。注意，很多人只在"主业务处理"里做了幂等，但漏掉了旁边的附属操作，比如发短信、扣积分、调用外部接口。一条消息重复消费时，附属操作执行两遍同样会造成脏数据。
处理完线上问题后，我通常会把重复消费场景做成压力测试用例，集成到 CI 流程里，防止后续重构时把幂等逻辑弄丢。
6. 消息系统与分布式事务的配合：本地消息表与事务消息的实用边界
6.1 本地消息表实现最终一致性
聊分布式事务之前，得先承认一个前提：消息队列本身不是分布式事务解决方案，它只是实现最终一致性的"搬运工"。真正要保证"业务数据更新"和"消息发送"这两个动作的一致性，常见的轻量方案是本地消息表。
本地消息表的思路非常朴素：在业务数据库里建一张 message_record 表，把"业务操作"和"写消息记录"放进同一个数据库事务。比如订单服务创建订单时，同时向 message_record 插入一条"待发送"的消息记录，这两个操作要么都成功，要么都失败。然后由一个后台任务定时扫描消息表，把状态为"待发送"的消息投递到 MQ，投递成功后再更新消息状态为"已发送"。
这个方案的优点是简单可靠，不依赖任何特殊中间件，普通 MySQL 就能搞定。缺点是消息表会随着业务量增长而膨胀，且定时扫描存在延迟，不是实时投递。适用于业务对消息实时性要求不高的场景，比如每日定时报表、对账通知。
6.2 事务消息：把可靠性上移到 Broker
RocketMQ 的事务消息把"本地事务"和"消息投递"的一致性逻辑从业务层上移到了 Broker 管理。它通过两阶段提交思想，让 Broker 在确认生产者本地事务成功之后，才把消息释放给消费者。
具体流程是：生产者发送 half message，Broker 存储消息但不暴露给消费者；生产者执行本地业务事务；事务成功则提交，失败则回滚。如果生产者本地事务执行完了但进程挂了，没有回传结果，Broker 会在一定时间内主动回查生产者的本地事务状态，这叫事务状态反查机制。
这套机制比本地消息表优雅得多，因为它把"扫描消息表"的活交给了 Broker，且消息是实时触发的，延迟更低。但它也有限制：只适用于同一个本地事务里的操作；如果需要跨多个数据库或跨多个服务做事务，它依然不够用。
6.3 什么场景需要"跨服务强一致"
最后讨论一下边界问题。很多人会问，既然有事务消息，那是不是就可以实现跨服务强一致性了？答案是远远不够。
消息队列能保证的是"消息不丢、最终被消费"，但它没法保证"多个服务的数据变更在同一瞬间对所有读操作可见"。比如订单支付成功后，消息通知库存服务和消息通知积分服务，库存服务减库存、积分服务加积分，这两个操作之间没有原子性：库存已经减了，积分还没加上，中间有一段时间数据是不一致的，只是最终会收敛一致。
如果你的业务必须做到强一致，比如跨行转账这种，那么真正需要的是 TCC（Try-Confirm-Cancel）或者 Saga 模式，而不是单纯靠消息队列。消息队列适合的是"最终一致性可接受、但消息绝对不能丢"的场景，这覆盖了绝大多数微服务业务。
我常用的一个判断标准是：如果某个操作做一半失败了，你可以接受稍后通过重试或补偿把它执行完，那就用消息 + 幂等；如果某个操作做一半失败了，会导致立刻不可逆的数据错误，那你应该用带事务协调器的强一致方案，别硬拿消息系统去凑。
最后说一个我自己的经验：把消息系统做稳定的关键，不在于选哪个中间件，也不在于调多少参数，而在于你写完消费代码之后，有没有认真问自己一句——如果这条消息被投递了三次，我的业务还能保持正确吗？如果答案是否，那就说明你还没准备好把它放到生产环境。把"至少一次投递 + 幂等消费 + 死信兜底 + 监控告警"这四条底线守住，大多数分布式系统的消息问题都会从"事故"退化成"日常告警"。