大促削峰核心是将突发请求转为可控任务流，手段包括：消息队列缓冲、前置过滤拦截、异步化与状态分离、资源隔离及弹性伸缩。
大促场景下，Linux系统最常遇到的不是“慢”，而是“瞬间压垮”——流量洪峰远超系统承载能力，导致服务不可用、数据库写爆、响应超时甚至雪崩。削峰填谷不是让系统变快，而是让压力变得“可消化”。核心思路是：把突发的、不可控的请求，变成平滑的、可控的任务流。
消息队列做缓冲带
这是大促削峰最直接有效的手段。用户点击下单/秒杀按钮后，业务层不立刻查库存、扣余额、写订单，而是快速校验基础参数（如用户登录态、商品ID有效性），然后把请求封装成轻量消息，投递到Kafka或RocketMQ等高吞吐消息队列中。
- 前端可立即返回“已提交，排队中”，用户体验不卡顿
- 后端消费服务按自身节奏拉取消息，控制每秒处理量（例如限流1000单/秒）
- 避免瞬时千万级并发直冲数据库，把“尖峰”拉成一条有坡度的曲线
前置过滤与分层拦截
不是所有请求都值得进后端。在流量入口处层层设防，越早拦截，系统损耗越小：
- Nginx层做IP限流、接口频次限制（limit_req）、非法参数过滤（geo+map防刷）
- 接入网关（如Spring Cloud Gateway）校验Token、权限、活动资格，失败请求不发往后端
- 静态资源（图片、JS、CSS）全部走CDN，释放源站带宽和连接数
异步化 + 状态分离
把“必须同步完成”的操作拆开，把耗时动作挪到后台，前台只管状态流转：
- 下单成功 ≠ 订单创建完成，而是生成预订单（轻量DB写入），后续由异步任务完成库存扣减、支付回调、物流单生成等
- 使用Redis记录各环节状态（如“预下单→库存锁定→支付中→已完成”），前端轮询或WebSocket推送状态
- 避免长事务阻塞数据库，也防止用户反复刷新重提请求
资源隔离与弹性伸缩
保障核心链路不被非关键请求拖垮，同时让系统具备应对波动的能力：
- 用cgroups或K8s namespace对秒杀服务、查询服务、日志服务做CPU/内存硬隔离
- 关键服务（如库存服务）单独部署，禁用非必要中间件（如全链路追踪采样率调低）
- 配合云平台配置HPA（水平Pod自动伸缩），根据QPS或CPU使用率动态扩容计算节点
