RabbitMQ 就是一个独立的、基于 AMQP 协议的消息服务器（Broker）。它接收生产者发来的消息，通过交换机（Exchange）根据路由规则将消息存入队列（Queue），再由消费者从队列中取出处理。它的核心价值是让服务之间实现异步、解耦、可靠的通信。
没有 RabbitMQ，MySQL 任务太多，一损俱损
RabbitMQ 就是用"独立的硬盘存储"+"异步确认机制"，把 MySQL 的慢写压力和 Tomcat 的宝贵线程隔离开，从而斩断了"一损俱损"的锁链。
以后面试官问：
"你项目里的 RabbitMQ 是怎么用的？"
不要说：
"我用了 RabbitMQ 做异步。"
太浅。
你应该说：
"在下单场景中，我把高并发请求和订单持久化进行了异步解耦。请求首先通过 Redis Lua 脚本完成库存预扣减，然后将订单消息发送到 RabbitMQ，接口快速返回；消费者异步完成订单和订单明细的持久化，从而利用消息队列削峰填谷，避免大量请求直接冲击 MySQL。同时针对 RabbitMQ 的消息确认和消费者重复消费问题，我分别设计了生产者 Confirm 机制和基于 orderNo 唯一索引的消费幂等。"
但是 Tracker 有一个很明显的工程缺陷
Claude Code 已经告诉你了：
应用重启 → Map 全没了。
例如：
submitOrder
↓
库存 -1
↓
Tracker.register()
↓
RabbitMQ发送
↓
服务器突然挂了重启：
Tracker = {}这时候如果消息最终真的没成功：
库存永久少1
订单不存在所以：
ConcurrentHashMap只能作为进程内临时状态，不能作为可靠消息存储。
这个你现在不用修。
但是一定要记住：
内存Map
≠
可靠消息表这以后是非常好的面试追问点。
以后面试官问：
"你这个方案有没有数据一致性风险？"
你反而可以回答：
"有。当前方案通过 Publisher Confirm、失败补偿和消费端幂等降低了风险，但由于 Redis、MySQL 和 RabbitMQ 不属于同一个分布式事务，极端情况下仍然存在消息确认与库存补偿之间的竞态。生产环境可以进一步采用 Outbox/本地消息表 + 定时补偿或者可靠消息最终一致性方案解决。"
"RabbitMQ发送失败之后，你怎么保证库存不会丢？"
你不能简单回答：
"我调用一个
restoreStock()把库存加回来。"
而应该回答：
"我区分同步发送异常和异步Confirm失败。同步异常发生在本地事务尚未提交时，MySQL库存由事务回滚恢复，只补偿Redis；Confirm NACK发生在本地事务提交之后，此时才通过独立事务补偿MySQL和Redis
"为什么要 RabbitMQ？"
你回答：
秒杀或者高并发下单场景中，大量请求同时到达，如果同步完成订单创建、订单明细、库存等数据库操作，会导致数据库连接和锁竞争压力过大。因此我在 Redis Lua 原子扣库存之后，将订单创建通过 RabbitMQ 异步化，让前端请求快速返回，同时利用 MQ 削峰填谷。
"那 MQ 发送失败怎么办？"
回答：
我区分同步发送异常和异步 Confirm 失败。同步发送异常发生在本地事务尚未提交时，MySQL 库存由事务回滚自动恢复，同时补偿 Redis；如果是 Confirm NACK 或消息 Return，此时本地事务已经提交，则通过独立事务同时补偿 Redis 和 MySQL。
"重复消费怎么办？"
回答：
RabbitMQ 本身是至少一次投递语义，所以消费者可能重复消费。我使用 orderNo 作为幂等键，同时在数据库建立唯一索引，并在消费前查询订单是否存在，最终通过数据库唯一约束作为兜底。