RabbitMQ消息可靠性需四层保障：①启用生产者确认机制（confirmSelect+waitForConfirms或ConfirmListener）；②交换机、队列、消息三者均设为持久化；③消费者关闭autoAck，手动调用basicAck；④应用层引入消息状态表与定时补偿机制。
开启生产者确认机制（publisher-confirm）
RabbitMQ 默认不保证消息一定到达交换机，网络抖动、Broker 重启、连接中断都可能导致 basicPublish 调用成功但消息实际未送达。必须显式启用发布确认：
channel.confirmSelect(); // 启用确认模式
channel.basicPublish("exchange", "routingKey", MessageProperties.PERSISTENT_TEXT_PLAIN, "data".getBytes());
if (!channel.waitForConfirms(5000)) { // 等待 ACK，超时抛异常
throw new RuntimeException("消息未被交换机接收");
}常见错误是只调用 basicPublish 就认为“发出去了”，没等 waitForConfirms 或忽略返回值。更稳妥的做法是配合异步回调（addConfirmListener），尤其在高并发场景下避免阻塞线程。
强制消息与队列持久化
即使消息到了交换机，若未正确路由或未落盘，仍可能丢失。三个环节必须同时持久化：
- 交换机声明时设
durable=true - 队列声明时设
durable=true - 发送消息时使用
MessageProperties.PERSISTENT_TEXT_PLAIN（即 deliveryMode=2）
缺一不可。例如只设队列持久化但消息是非持久的，Broker 内存压力大时会丢弃该消息；又或者交换机非持久，Broker 重启后交换机消失，后续消息直接被丢弃且无报错。
立即学习“Java免费学习笔记（深入）”；
消费者手动 ACK + 关闭 autoAck
消费者端最容易踩的坑是依赖默认的 autoAck=true。一旦消息投递后消费者进程崩溃（如 OOM、kill -9），消息就永久丢失——Broker 认为它已被“自动签收”。
必须配置：
channel.basicConsume("queue", false, consumer); // 第二个参数为 false并在业务逻辑完全执行成功后，再调用：
channel.basicAck(deliveryTag, false);
注意：如果处理逻辑涉及数据库写入，要确保 DB 提交成功后再发 basicAck；否则 DB 回滚但消息已标记为消费，造成数据不一致。
兜底方案：消息状态表 + 定时补偿
RabbitMQ 自身机制能覆盖绝大多数异常，但无法应对极端情况：比如生产者写完 DB 后、发消息前宕机；或消费者处理成功、发 ACK 前网络断开。
这时需要应用层兜底：
- 发送方先插入一条记录到
msg_status表，字段含msg_id、content、status='pending'、send_time - 再调用
basicPublish - 消费方处理完，通过 HTTP/Feign 回调发送方接口，将对应
msg_id的状态更新为'consumed' - 后台定时任务扫描
status='pending'且send_time超过 5 分钟的消息，重新投递
这个表不是可选优化，而是金融、订单类场景的硬性要求。很多人以为“开了持久化+确认就够了”，却在灰度发布时因一次磁盘故障发现几百条订单消息石沉大海——那正是没做状态对账的代价。
