rabbitmq消息可靠传递需四步：①选对exchange类型（direct/fanout/topic）确保精准路由；②队列与消息双重持久化+发布确认和手动ack保障不丢失；③消费者幂等处理、队列限长防堆积；④spring boot三步快速集成。
使用 RabbitMQ 处理消息队列，核心是围绕“生产者 → 交换机 → 队列 → 消费者”这条链路展开，关键不在“能不能发收”，而在于“怎么发得准、存得稳、收得可靠”。下面从实际落地角度讲清楚最关键的四个环节。
明确消息流向：先选对 Exchange 类型
消息不是直接进队列的，必须经过 Exchange 路由。选错类型，消息就可能丢失或错投：
- Direct（直连）：适合点对点精准投递，比如“订单支付成功”只发给库存服务。要求 routing key 和 binding key 完全一致。
- Fanout（广播）：不看 routing key，所有绑定队列都会收到同一份消息。适合通知类场景，如用户注册后同时触发发短信、写日志、更新推荐缓存。
-
Topic（主题）：支持通配符（* 匹配单个词，# 匹配零或多个词），适合多级分类路由。例如 routing key 是
order.payment.success，绑定order.#或order.*.success的队列都能收到。 - Headers 类型极少用，一般用 Topic 就够覆盖大部分模糊匹配需求。
保障消息不丢：持久化 + 确认机制双保险
默认配置下，RabbitMQ 重启或崩溃会导致消息丢失。要真正可靠，必须两步都做：
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
-
队列和消息都要声明为持久化：创建队列时设
durable=true；发送消息时用MessageProperties.PERSISTENT_TEXT_PLAIN标记消息本身可落盘。 -
开启发布确认（Publisher Confirm）和消费确认（Manual ACK）：生产者端启用 confirm 模式，确保消息已进入 Broker；消费者端关闭 autoAck，处理完业务逻辑再显式调用
channel.basicAck()，失败时可拒绝并重入队列或进死信队列。
避免重复消费与消息堆积
网络抖动、消费者宕机、处理超时都可能导致消息被重复投递或积压：
- 消费者需实现幂等性——比如用订单 ID 做数据库唯一索引，或 Redis SETNX 记录已处理 ID。
- 给队列设置
x-max-length（最大长度）和x-overflow=reject-publish或drop-head，防止无限制堆积拖垮内存。 - 监控队列长度和消费者未确认消息数（unack），及时扩容消费者或排查慢消费逻辑。
快速上手一个可用示例
以 Java + Spring Boot 为例，三步就能跑通基础流程：
- 引入
spring-boot-starter-amqp依赖； - 配置文件中指定 host、port、username、password 和 virtual-host；
- 用
@RabbitListener(queues = "my.queue")注解标记消费方法，用RabbitTemplate.convertAndSend()发送消息。
不需要手动建 Exchange 和 Queue——Spring AMQP 可自动声明，但正式环境建议显式定义并复用，避免因命名差异导致路由失效。
