选型先看场景

RabbitMQ适合业务解耦，延迟低，路由灵活。Kafka吞吐高，适合日志、埋点、流处理。RocketMQ事务消息强，电商场景用得多。Spring Boot对RabbitMQ和Kafka的支持都成熟，spring-boot-starter-amqp和spring-boot-starter-kafka开箱即用。中小项目从RabbitMQ起步，学习曲线平缓，管理界面直观。

整合RabbitMQ：三件事

引入依赖后，application.yml里配好连接信息。队列、交换机、绑定关系用@Bean声明，项目启动自动创建。发送用RabbitTemplate，消费用@RabbitListener。代码不复杂，坑都在细节里。

@Configuration public class RabbitConfig { @Bean public Queue orderQueue() { return QueueBuilder.durable("order.queue") .withArgument("x-dead-letter-exchange", "dlx.exchange") .build(); } @Bean public DirectExchange orderExchange() { return new DirectExchange("order.exchange"); } @Bean public Binding orderBinding() { return BindingBuilder.bind(orderQueue()) .to(orderExchange()).with("order.create"); } }

发送端注入RabbitTemplate，convertAndSend把对象序列化后投递。消费端加@RabbitListener(queues = "order.queue")，方法参数接消息体。

消息不丢，靠三层保险

生产者确认。publisher-confirm-type: correlated开启后，消息到达broker会回调确认，没到达触发return回调。配合本地消息表，能兜住发送失败。

队列和消息持久化。QueueBuilder.durable声明持久化队列，发送时MessageProperties设DeliveryMode.PERSISTENT。broker重启，消息还在。

消费者手动ACK。acknowledge-mode: manual，业务处理成功调basicAck，失败调basicNack。自动ACK模式下，消息一到消费者就确认，业务还没跑完就宕机，消息就丢了。

重复消费，用幂等性兜底

消息队列保证至少一次投递，重复不可避免。消费端拿业务唯一键去重，比如订单号加事件类型。Redis的setnx设过期时间，或者数据库唯一索引插入失败就忽略。幂等性不是可选项，是消费端的必修课。

死信队列，给失败留退路

消息重试多次仍失败，不能无限循环。队列声明时绑死信交换机，basicNack时设requeue=false，消息进死信队列。人工介入排查，或者定时任务重新投递。死信队列是系统的安全气囊，平时用不上，出事时能救命。

异步解耦的架构收益

主流程只发消息，响应时间从几百毫秒降到几毫秒。下游系统宕机，消息堆在队列里，恢复后继续消费，主流程不受影响。新增业务方，订阅同一个交换机，加个队列绑定就行，不用改发送端代码。解耦的代价是复杂度上升，收益是弹性和吞吐量。

监控不能省

RabbitMQ管理界面看队列积压、消费者数量、消息速率。Spring Boot Actuator暴露/actuator/health，Micrometer接Prometheus，Grafana配告警。队列积压超过阈值，短信通知值班。没有监控的异步系统，等于蒙眼开车。

异步解耦不是银弹。引入消息队列，系统多了一个中间件要维护，消息丢失、重复、顺序问题都要处理。但订单、支付、通知这类场景，同步调用扛不住流量，异步化是必经之路。Spring Boot把整合门槛降得很低，剩下的功夫，花在可靠性设计和监控上。把消息当成一等公民对待，系统才稳。