rabbitmq秒杀削峰核心在于三端协同：生产端毫秒级发消息并持久化，队列端设限+持久化+死信兜底，消费端限速+幂等+状态闭环，配合前置限流与最终一致性校验。
直接用 RabbitMQ 做秒杀削峰，核心不是“能不能发消息”，而是“怎么让消息不丢、不积压、不拖垮下游、还能准确反馈结果”。关键在三块：生产端轻量化、队列有容量有保护、消费端可控可重试。
生产端：快进快出，拒绝阻塞
用户点“抢购”那一刻，Web 层必须在毫秒级完成两件事：校验基础参数（如用户登录态、活动时间）、发消息到 RabbitMQ。其余所有逻辑——查库存、扣库存、建订单、发通知——全部后置。
- 用 RabbitTemplate.convertAndSend() 发送，不等响应；设置消息 deliveryMode=PERSISTENT，防止 Broker 重启丢失
- 避免在发送前做 DB 查询或远程调用，否则线程卡住，反而成为瓶颈
- 返回前端统一提示：“请求已接收，请稍候查看结果”，不承诺“秒杀成功”
队列端：设限+持久化+死信兜底
队列不是越大越好，而是要匹配业务容忍度和运维能力。比如 10 万并发请求，系统每秒最多处理 2000 单，那队列最大长度设为 10 万，超了就拒绝，比堆满内存 OOM 更可控。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 声明队列时指定 x-max-length=100000 和 x-overflow=reject-publish，新消息直接被拒，避免无限堆积
- 开启 queue.durable=true，确保消息落盘；配合生产者 confirm 模式，确认投递成功再返回
- 配置死信交换机（DLX），消费失败且重试 3 次后转入死信队列，人工或定时任务核查异常单
消费端：限速+幂等+状态闭环
消费者不是越多越好，而是要和数据库、缓存的实际吞吐匹配。比如 MySQL 单实例写入极限约 2000 TPS，那消费者并发数设为 4～6 个，每个线程每秒拉取 300～500 条，比盲目开 20 个线程更稳。
- 用 @RabbitListener + concurrency="4-6" 控制并发；配合 prefetch=10 防止消息预取过多压垮消费者
- 每条消息处理前先查 Redis 缓存判断是否已处理（用订单号或用户+商品组合做 key），避免重复下单
- 处理完成后更新订单状态，并触发一条“结果通知”消息到另一个 exchange，由推送服务异步触达用户（微信/APP）
配套保障：不能只靠 MQ
RabbitMQ 是缓冲中枢，但不是万能解药。它前面要有前置拦截，后面要有最终一致性校验。
- 接入层用 Nginx 限流（limit_req）或网关（Spring Cloud Gateway）做第一道漏斗，过滤明显恶意刷量
- 库存扣减必须走 Redis 预减（decrby）+ MySQL 最终落地，RabbitMQ 消费时只做“确认扣减”和“建单”，不参与库存决策
- 定时任务每 5 分钟扫描“待支付且超时未处理”的消息 ID，对长时间卡在队列中的订单主动告警或补偿
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
