削峰填谷策略核心是拉平瞬时洪峰为数据库可承受的持续流量，通过消息队列缓冲、异步消费、批量写入、前置过滤、读写分离与缓存兜底实现。
高并发系统中设计削峰填谷策略，核心目标不是完全避免高峰，而是把瞬时洪峰“拉平”成数据库可稳定消化的持续流量。关键在于分层缓冲、异步解耦和可控延迟，让数据库只承担它真正能扛住的写入压力。
用消息队列做第一道缓冲坝
把用户请求（如预约、下单、秒杀）不直接落库，而是先发到 Kafka 或 RocketMQ 等消息队列中。队列就像水库，上游洪水来了先拦住，下游按设定速率慢慢放水。
- 前端响应用户“已提交，请稍候”，立即释放连接和线程资源
- 后台用固定数量的消费者（比如 8～12 个 worker）从队列拉取消息，逐条校验、扣库存、写订单
- 消费者并发数要根据数据库单次写入耗时反推：若单条处理 200ms，1000 个请求需 200s；部署 5 个消费者，平均等待约 40s，用户可接受
- 监控队列积压量，超阈值自动扩容消费者或告警人工介入
写操作批量合并与延迟提交
高频小写入（如用户行为日志、积分变动）不必每条都立刻入库，可聚合后批量提交。
- 应用层缓存变更数据（如内存队列或本地 RingBuffer），每 100ms 或每满 100 条触发一次批量 INSERT
- 使用 MySQL 的 INSERT INTO ... VALUES (...), (...), (...) 语法，比单条插入快 5～10 倍
- 对非强实时场景（如通知发送、报表生成），直接投递到延时队列，按分钟级调度执行
前置过滤与限流，不让无效请求进队列
削峰不只是“接住”，更要“筛掉”。越早拦截无效或非法请求，后端压力越小。
- 在网关层（如 Nginx 或 Spring Cloud Gateway）做令牌桶限流，按用户 ID 或 IP 限制每秒请求数
- 用 Redis 预校验库存/资格：秒杀前先查 Redis 中剩余库存，为 0 直接返回失败，不发消息
- 对重复提交、过期请求（如带时间戳参数且超时 2s）直接拒绝，不进入业务链路
- 静态资源、图片、JS/CSS 全部走 CDN，避免请求打到应用服务器
读写分离 + 缓存兜底，减轻主库负担
写压力降下来后，还要防止读请求反向拖垮主库——尤其在写后立即读的场景。
- 主库只负责写，所有读请求路由到从库；用半同步复制降低主从延迟
- 热点数据（如商品详情、用户资料）优先从 Redis 读，设置合理过期时间+主动更新机制
- 对“写后读”一致性要求不高的场景，允许短暂读从库或缓存，避免强制读主库造成锁竞争
- 冷热分离：历史订单归档到单独库表，主库只保留近 3 个月活跃数据
