rabbitmq单独无法保障最终一致性，必须搭配redis状态快照与本地消息表：redis用setnx+ex原子标记message_id→"done"实现生产者确认与消费者幂等校验，本地消息表保证业务落库与消息记录同事务，再辅以confirm机制、manual ack和持久化构建可靠链路。
靠 RabbitMQ 单独做分布式事务，撑不住最终一致性。它能保证消息不丢、不漏，但管不了业务是否真成功——比如订单创建了，库存服务却失败了，消息已 ACK，数据就错位了。必须搭配状态协同机制，用 Redis 做轻量级“业务快照中心”，再配合本地消息表或事务协调表，才能稳住大并发下的最终一致。
用 Redis 记录消息执行状态，原子判重
核心不是存消息体，而是用 message_id → "done" 这种极简映射，靠 SETNX+EX 一条命令完成“首次设置即生效”：
- 生产者发消息前，先尝试
jedis.set(messageId, "done", SetParams.setParams().nx().ex(3600))； - 返回 "OK" 表示首次写入成功，说明业务逻辑刚确认完成，此时才发 MQ；
- 返回 null 表示已存在，跳过发送，天然防重复；
- 过期时间设为略大于最大业务耗时（如 1 小时），避免脏状态长期滞留。
本地消息表保障“业务落库 + 消息记录”原子性
在订单服务数据库里建一张 trans_message 表，和订单操作同事务提交：
- 字段至少含：id（UUID）、service_name、exchange、routing_key、payload（JSON 或序列化字符串）、status（如 'pending'/'sent'/'failed'）、retry_count；
- 下单成功的同时，插入一条 status='pending' 的记录；
- 再由定时任务扫描 status='pending' 的记录，调用 RabbitMQ 发送，并更新为 'sent'；
- 发送失败则更新 status='failed'，触发重试逻辑（比如指数退避 + 最大 3 次）。
消费者端严格幂等 + 状态校验
收到消息后不能直接执行，要分三步走：
- 第一步：查 Redis ——
jedis.get(messageId)； - 若返回 null 或非 "done"，说明生产者还没确认业务完成，直接 nack 并延迟重试（如 5 秒后）；
- 若返回 "done"，再执行本地业务（如扣库存），成功后可删 Redis key 或不做处理（靠过期自动清理）；
- 全程不依赖消息体内容判断是否重复，只认 Redis 中这个原子标记。
补充可靠链路：confirm + manual ack + 持久化
这些是基础防线，不能少，但也不能指望它们解决业务一致性：
- 生产者开启 publisher confirms，配合回调监听 handleAck/handleNack；
- RabbitMQ 队列、交换机、消息都设 durable=true；
- 消费者用 manual ack，只在业务逻辑真正完成后才 channel.basicAck；
- 消费失败时走 nack + requeue=false，进死信队列，再由补偿服务兜底处理。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
