RabbitMQ 是什么

RabbitMQ 是开源 AMQP 消息代理：Producer 把消息交给 Exchange，经 Binding 路由到 Queue，Consumer 从队列取走并 ack。CodeRoadMap 主栈是 MySQL + 可选 Redis；RabbitMQ 作为 任务队列 lab，与 kafka-intro 对照理解「队列型 vs 日志型」MQ。

学习目标

• 说出 AMQP 0-9-1 里 Broker、Exchange、Queue 各管什么
• 区分「任务队列」与「事件流」两类业务诉求
• 对比 RabbitMQ、Kafka、redis-pubsub 的适用边界

核心内容

为什么需要 RabbitMQ

同步 HTTP 调用链路过长时，下单 API 还要等发邮件、算积分。更稳妥的做法：订单写入 MySQL 并提交事务（见 sb-transaction），再投递「订单已创建」消息，后台 Worker 慢慢处理。

[Spring Boot API] --publish--> [Exchange: order.events]
                                      |
                                      v
                               [Queue: notify.email]
                                      |
                                      v
                               [邮件 Worker 消费 + ack]

RabbitMQ 擅长 领任务、确认删除、灵活路由；Kafka 擅长 录日志、多组重放（kafka-vs-mq）。

与 Redis、Kafka 对照

场景	Redis	RabbitMQ	Kafka
缓存失效广播	✅ Pub/Sub	可以 fanout	过重
异步发邮件/导出	❌ 无持久队列语义	✅ 工作队列	可以但偏流
审计事件多订阅重放	❌	一般	✅
延迟/死信路由	有限	✅ DLX	靠时间戳 topic

本站 缓存与 Session 仍走 redis-essentials；跨服务任务 用 RabbitMQ lab 练手；行为埋点、事件溯源实验 见 Kafka track。

CodeRoadMap 中的位置

主 API 仍是 spring-boot-essentials REST + JPA。RabbitMQ 以 Docker 本地 Profile 接入，不替代 MySQL 真相源；消息体宜带 orderId 等快照字段，消费失败可 nack 重试。

练习