在企业级应用中，“消息不丢失、处理不重复、系统抗故障”是核心诉求。RabbitMQ提供了一系列高级特性，保障消息传输的可靠性和系统的稳定性。
1、消息可靠性保障
要确保消息不丢失，需同时开启“持久化三件套”和“双重确认机制”，形成全链路可靠保障。
还需要避免消息乱序和重复。
1.1、 持久化
持久化的核心是将数据写入硬盘，避免服务器重启后数据丢失。需同时配置以下三点：
- 交换机持久化：声明交换机时设置durable=true，重启后交换机仍存在。
- 队列持久化：声明队列时设置durable=true，重启后队列仍存在（但队列中的消息需额外配置持久化）。
- 消息持久化：发送消息时设置delivery_mode=2（AMQP协议规定），消息会被写入硬盘。
注意：三个步骤缺一不可。例如仅持久化队列而未持久化消息，重启后队列存在但消息丢失。
1.2、 双重确认机制
通过“生产者确认”和“消费者确认”，确保消息从发送到处理的全链路可靠。
- 生产者确认（Publisher Confirm）：生产者发送消息后，RabbitMQ会通过信道返回ACK（消息已接收并持久化）或NACK（消息接收失败）。生产者可通过监听确认信号，实现失败重试或日志记录。 示例逻辑：开启确认模式后，发送消息时添加确认监听器，若收到NACK则间隔1秒重试，重试3次失败后记录到错误日志。
- 消费者确认（Consumer Ack）：消费者处理消息后需显式发送ACK信号，RabbitMQ收到后才删除消息；若未发送ACK（如消费者宕机），消息会重新入队（这里可能导致消息重复）；若处理失败，可发送NACK并指定是否重新入队。 注意：避免使用自动ACK（AutoAck=true），否则消费者拿到消息后立即确认，若后续处理失败，消息已被删除，导致数据丢失。
1.3、消息避免乱序
原因：生产者把顺序相关的消息发到同一个队列，但消费者是多线程并发消费，处理速度不同导致顺序错乱。
解决方案：
强制串行：只启动一个消费者单线程消费，消息按入队顺序逐个处理。吞吐量低。
分区顺序：使用它内置插件，根据请求的特征（如用户ID）计算哈希值，让相同特征消息进入同一队列。队列绑定的每个消费者内部存ID做分组排队，让相同ID的消息串行处理，不同ID的并行。
业务层排序：每条消息带一个序号，消费者收到后先检查序号，如果序号等于当前序号则处理，小于则丢弃，大于则等待，直到按顺序补齐。
1.4、消息避免重复
原因：消费者因为处理超时或者网络中断等导致没有发ACK确认，导致RabbitMQ认为消费失败，重新投递消息。
解决方案：
数据库唯一约束：比如订单消息，用消息id作为唯一键插入消息表，处理前检查消息id是否存在。
业务状态机，比如订单状态从1→2，更新时加条件：update...set status=2 where status=1。
Redis分布式锁：消费前用SETNX加锁，加锁成功才设置redis标记位并处理业务，过期时间设长一些。重复消息来时如果标记存在就不处理。
2 死信队列（DLX）
死信队列（Dead Letter Exchange）是专门处理“异常消息”的队列，当消息满足以下条件时，会被标记为“死信”并路由到死信队列：
- 消息被消费者拒绝（basicReject/basicNack）且未设置重新入队（requeue=false）；
- 消息在队列中存活时间超过TTL（消息超时时间）；
- 队列达到最大长度，新消息无法入队。
死信队列配置步骤：
- 声明死信交换机（如dlx-exchange，类型可任意，常用Direct）；
- 声明死信队列（如dlx-queue），并绑定到死信交换机；
- 给正常队列设置死信参数：
x-dead-letter-exchange：死信交换机名称；
x-dead-letter-routing-key：死信路由键；
x-message-ttl：消息超时时间（如30分钟，单位毫秒）。
由于死信队列可以配置交换机并绑定不同队列，因此可以让不同类型的死信进入不同的队列。
适用场景：
电商订单30分钟未支付自动取消、物流轨迹超时未更新告警、异常消息人工复盘等。
3 延迟队列
RabbitMQ本身不直接支持延迟队列，但可通过“TTL+死信队列”间接实现：给消息设置TTL，到期后成为死信，自动路由到死信队列，消费者监听死信队列即可实现定时任务。
适用场景：
- 订单30分钟未支付自动取消；
- 用户注册后24小时未登录发送召回通知；
- 物流包裹超时未签收触发客服跟进。
4、镜像队列与集群
单节点RabbitMQ存在单点故障风险，企业级部署需构建集群并配置镜像队列，确保节点宕机后服务不中断。
4.1、 镜像队列
将队列数据同步到多个节点（副本），主节点处理消息，从节点实时同步数据。当主节点宕机，从节点自动升级为主节点，继续提供服务。
核心配置（通过CLI命令）：
# 给所有order开头的队列配置镜像队列，复制到所有节点，自动同步
rabbitmqctl set_policy ha-all "^order-" '{"ha-mode":"all","ha-sync-mode":"automatic"}'
4.2、分布式集群
多节点组成逻辑集群，通过Erlang分布式协议同步元数据（队列、绑定关系等），结合负载均衡分摊消息处理压力。在K8s环境中，可通过RabbitMQ Operator实现集群自动扩缩容和故障转移。
5 流量控制：避免消费者过载
当生产者发送消息速度超过消费者处理速度时，会导致队列积压。RabbitMQ通过以下机制实现流量控制：
- basicQos限流：消费者通过basicQos(prefetchCount=N)设置每次预取的消息数量，即消费者同时处理N条消息，处理完并确认后再获取下一批，避免同时处理过多消息导致过载。
- 背压机制：当队列积压过多或消费者处理过慢时，RabbitMQ会暂停向消费者发送新消息，直至消费者确认部分消息，缓解消费者压力。
注意：这里的流量控制只是为了保护消费者端，如果生产者端消息来临的速度大于消费者处理速度，队列会持续积压，多的消息要么ttl到期进入死信、要么占满磁盘触发系统保护。
