核心是让MQ成为可控缓冲带而非简单中转站：前置Redis库存预减校验、网关按商品限流、分区有序消费、固定线程池+动态扩缩容、消息轻量化与traceId可追溯、死信兜底及堆积超阈值自动降级。
Java消息队列在秒杀场景下的高并发削峰，核心不是“能不能用MQ”，而是“怎么让MQ真正扛住峰值、不丢不积压、结果可预期”。关键在于把MQ变成可控的缓冲带，而不是简单的异步中转站。
分层缓冲 + 速率可控消费
不能让所有请求一股脑涌进MQ再靠消费者硬扛。要前置控制写入节奏：
- 网关层按商品维度限流（比如每秒最多1万请求进MQ），避免MQ本身被打爆
- Kafka/RocketMQ按商品ID做分区（如 seckill_order_{itemId}），保证同一商品请求落在同一分区，便于顺序消费和库存校验
- 消费者端采用固定线程池+动态扩缩容机制：初始启动5个消费者实例，监控堆积量（lag），超阈值自动拉起新实例（K8s下可基于Prometheus指标触发）
- 每个消费者单次批量拉取≤100条消息，处理完再拉取，避免长事务阻塞
库存预校验必须在入队前完成
MQ只负责“下单指令”，不负责“能不能买”。超卖风险必须卡在入队之前：
- 用户请求到达应用层后，先查Redis缓存中的库存（如 seckill:stock:{itemId}），原子减1（DECR）
- 若返回值 ≥ 0，说明还有库存，才封装消息发往MQ；否则直接返回“已售罄”
- Redis库存需设合理过期时间（如活动结束时间+10分钟），并配合后台定时任务对账补偿
消息体轻量化 + 状态可追溯
消息不是越全越好，而是越精简、越可追踪越好：
立即学习“Java免费学习笔记（深入）”；
- 消息内容只含必要字段：userId、itemId、orderId（服务端生成）、timestamp
- 不传用户信息、收货地址等冗余数据，这些由订单服务异步查库补充
- 每条消息带唯一traceId，写入MQ时记录日志；消费者处理成功后，更新MySQL订单表状态，并落库traceId与处理耗时，便于问题定位和延迟分析
失败兜底与快速降级
MQ不是万能保险丝，要有熔断和逃生通道：
- RabbitMQ/Kafka开启消息持久化，消费者启用手动ACK，防止进程崩溃丢消息
- 设置死信队列（DLQ）捕获3次重试失败的消息，人工介入或自动归档
- 当MQ堆积量持续超过5万条且处理延迟超10秒，前端自动切到“排队中”页面，并返回预估等待时间（基于当前积压量/平均TPS计算）
- 极端情况下，可关闭MQ写入，直接返回“系统繁忙”，保护数据库不被击穿
