选型先看场景RabbitMQ适合业务解耦延迟低路由灵活。Kafka吞吐高适合日志、埋点、流处理。RocketMQ事务消息强电商场景用得多。Spring Boot对RabbitMQ和Kafka的支持都成熟spring-boot-starter-amqp和spring-boot-starter-kafka开箱即用。中小项目从RabbitMQ起步学习曲线平缓管理界面直观。整合RabbitMQ三件事引入依赖后application.yml里配好连接信息。队列、交换机、绑定关系用Bean声明项目启动自动创建。发送用RabbitTemplate消费用RabbitListener。代码不复杂坑都在细节里。java复制下载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); } }发送端注入RabbitTemplateconvertAndSend把对象序列化后投递。消费端加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时设requeuefalse消息进死信队列。人工介入排查或者定时任务重新投递。死信队列是系统的安全气囊平时用不上出事时能救命。异步解耦的架构收益主流程只发消息响应时间从几百毫秒降到几毫秒。下游系统宕机消息堆在队列里恢复后继续消费主流程不受影响。新增业务方订阅同一个交换机加个队列绑定就行不用改发送端代码。解耦的代价是复杂度上升收益是弹性和吞吐量。监控不能省RabbitMQ管理界面看队列积压、消费者数量、消息速率。Spring Boot Actuator暴露/actuator/healthMicrometer接PrometheusGrafana配告警。队列积压超过阈值短信通知值班。没有监控的异步系统等于蒙眼开车。异步解耦不是银弹。引入消息队列系统多了一个中间件要维护消息丢失、重复、顺序问题都要处理。但订单、支付、通知这类场景同步调用扛不住流量异步化是必经之路。Spring Boot把整合门槛降得很低剩下的功夫花在可靠性设计和监控上。把消息当成一等公民对待系统才稳。
