SpringBoot+消息队列，异步解耦最佳实践

选型别拿Kafka当RabbitMQ用RabbitMQ轻量延迟低适合业务解耦、任务分发。Kafka吞吐高持久化强适合日志、流处理。RocketMQ折中支持事务消息适合电商场景。选错队列等于用卡车送快递用摩托拉集装箱。SpringBoot对三者都有starter集成成本相近但运维和模型差异大。小团队从RabbitMQ起步大流量再考虑Kafka。选型看场景不看热度。消息设计给每条消息一张身份证消息体别只塞业务数据。加消息ID用于幂等和追踪。加时间戳用于延迟和过期判断。加重试次数用于死信决策。加版本号用于格式演进。没有元数据的消息是黑箱出了问题只能猜。用JSON足够Avro适合强schema场景。保持消息精简大对象存对象存储消息里只放引用。生产者确认别让消息悄悄消失SpringBoot的RabbitTemplate默认不保证送达。开启publisher-confirm和publisher-return确保消息到达broker。生产者确认是消息不丢的第一道闸。Kafka用acksallRocketMQ用同步发送。别为了吞吐牺牲可靠性异步发送加回调也能兜底。确认失败要重发重发要幂等否则重复消息比丢消息更麻烦。消费者幂等重复消费是常态不是异常网络抖动、确认丢失、重平衡都会导致消息重投。消费者必须幂等。幂等不是可选项是分布式系统的必修课。用唯一键去重Redis记录消息ID数据库唯一索引状态机判断。别用“查一下再插入”并发下照样重复。幂等做在业务层别指望队列替你解决。死信队列给失败消息一个归宿消息重试三次仍失败别无限循环。配置死信交换机把失败消息路由到死信队列。死信队列不是垃圾堆是问题仓库。人工介入分析原因修复后重投。SpringBoot里用RabbitListener的errorHandler或RetryTemplate控制重试次数。重试间隔用指数退避避免雪崩。事务消息最终一致性的利器跨服务写库又发消息用本地消息表或RocketMQ事务消息。本地消息表业务库同事务写消息表定时任务扫描发送。事务消息半消息确认回查本地事务。强一致难求最终一致可期。别用两阶段提交太重。接受短暂不一致换来系统可用性。监控告警看不见的队列最危险消息堆积、消费延迟、死信增长每个指标都要监控。SpringBoot Actuator暴露队列指标对接Prometheus和Grafana。队列不监控等于闭眼开车。堆积超阈值告警延迟超预期排查。消费者扩容是临时解根因可能是下游慢或逻辑重。常见坑顺序、重复、丢失顺序消息只在单分区单消费者有效全局顺序代价高。重复消费靠幂等丢失靠确认和持久化。异步解耦不是银弹它把同步的复杂度换成了分布式的复杂度。简单业务别硬上队列同步加超时和熔断也能扛。架构是权衡不是堆砌。SpringBoot加消息队列写起来几行代码跑起来一堆门道。把确认、幂等、死信、监控做扎实异步解耦才真正解耦。否则你只是把同步的坑搬到了异步里。