大促活动前，缓存预热要提前规划热点数据、分批次加载，带宽峰值则靠限流、降级、扩容和CDN分流协同解决。单纯依赖临时加机器或手动刷缓存，往往撑不住流量洪峰，下面这套方法论，是我在多次大促实战中沉淀下来的完整路径。
大促活动缓存预热怎么做？先搞懂原理和时机
缓存预热不是简单地把数据塞进Redis,而是在流量到达之前，让缓存层提前持有高概率被访问的数据，核心目标只有一个：避免缓存击穿和缓存雪崩，让数据库扛得住瞬时压力。
预热时机的选择,比预热本身更重要，行业共识认为，预热窗口最好放在大促前30分钟到1小时，太早预热会让部分数据过期，太晚则来不及生效，具体分三步走：
- 提前一天导出热点数据清单,比如商品ID、库存状态、活动页配置。
- 大促前1小时启动第一轮预热,覆盖Top 20%的高频商品。
- 大促前10分钟做第二轮增量预热,把临时追加的库存和价格变化同步进缓存。
这里的难点在于,如何定义“热点数据”，别凭感觉拍脑袋，直接拉取最近7天线上日志，按请求频次排序即可，如果日志量太大，可以抽样统计，误差在可接受范围内。
缓存预热和CDN加速的区别：别把两件事混为一谈
很多人在大促规划时,把缓存预热和CDN加速混在一起讨论，两者解决的问题完全不同。
- 缓存预热发生在应用层，针对的是业务数据，比如商品详情、用户购物车，数据存储在Redis或本地内存中，由后端代码读写。
- CDN加速发生在网络层，针对的是静态资源，比如图片、CSS、JS文件，数据存储在边缘节点，由DNS调度和HTTP缓存控制。
简单说,缓存预热是让数据库少干活，CDN加速是让源站少传输，大促期间两者都需要，但规划思路要分开，如果你把商品价格这类动态数据放到CDN上，大概率会看到旧价格被用户截图投诉，反过来，如果你把App的启动图片塞进Redis，那才是暴殄天物。
预热哪些数据？别把所有内容都塞进缓存
缓存空间是有限的,尤其是本地缓存，容量更是捉襟见肘，预热时必须做取舍，优先放三类数据：
- 强一致性要求低但读量极大的数据：比如商品介绍、用户评价摘要，允许短暂延迟更新。
- 计算成本高的聚合数据：比如首页推荐列表、榜单，每次实时计算都消耗大量CPU。
- 依赖外部接口的数据：比如库存服务返回的剩余数量，在预热时先拉取一次，避免大促当天第三方接口超时。
不需要预热的数据也有两类：一是低频长尾商品，二是频繁变动的数据，比如实时库存余量，后者建议直接用Cache-Aside模式，等用户请求来了再回源查询并写入缓存。
缓存预热方案对比：本地缓存与分布式缓存的取舍
大促场景下,缓存方案的技术选型直接决定预热的执行效率，这里做一个实际对比，方便你按业务规模做判断。
| 维度 | 本地缓存 | 分布式缓存 |
|---|---|---|
| 部署方式 | 每台应用服务器内存中 | 独立缓存集群，如Redis Sentinel或Cluster |
| 访问延迟 | 极低，纳秒级 | 较低，毫秒级 |
| 容量上限 | 单机内存，通常几GB | 可以横向扩展，几十GB甚至TB级 |
| 数据一致性 | 各节点不一致，需要广播失效 | 集中存储，一致性更容易保障 |
| 预热方式 | 应用启动时加载，或定时任务推送 | 脚本批量写入，或数据迁移工具 |
| 适用规模 | 单机应用或小规模集群 | 中大型电商、高并发场景 |
本地缓存方案：适合单机小规模
如果你的大促活动只覆盖一个小型站点,QPS预期在几百以内，本地缓存完全够用，预热时可以直接在应用启动类里写一个@PostConstruct方法，从数据库查询热点数据放入ConcurrentHashMap，优点是简单直接，没有网络开销；缺点是每台服务器的缓存内容需要独立维护，一旦扩容新节点，新节点需要自己再拉一次数据。
分布式缓存方案：大促场景的标配
当预期QPS达到数千甚至上万,分布式缓存几乎是唯一选择，预热的常规操作是用一个脚本批量拉取数据库数据，通过Pipeline写入Redis，这里给一个可用的思路：
# 核心步骤
1. 从配置中心读取热点商品ID列表
2. 分批查询数据库，每批500个
3. 用Redis pipeline批量写入，设置过期时间
4. 执行完一批后，用RANDOM_KEY做采样验证注意,分布式缓存预热时一定要设置合理的过期时间，不要用永久有效，大促结束后，那些热点数据可能变成冷数据，留在缓存里只会浪费内存，推荐过期时间设为活动结束后2小时。
预热执行步骤参考
不管用哪种方案,正规的预热流程都包含以下动作：
- 制定数据清单,明确每个缓存key的命名规则和过期策略。
- 写一个可重复执行的预热脚本,支持幂等操作。
- 在预发环境先跑一遍,确认缓存命中率符合预期。
- 大促当天监控缓存命中率曲线,如果低于90%，立即检查是不是有漏掉的key。
大促带宽峰值如何应对？从网络层到应用层的四道防线
带宽峰值是比缓存击穿更棘手的问题,缓存没命中最多拖慢接口，带宽被打满直接导致整个站点不可访问，应对方案要分层设计，每一道防线都承担不同的职责。
第一道防线：带宽容量预估与扩容
大促前先做带宽预估,别等监控报警了才去升级，计算公式很简单：
带宽需求 = 预估并发用户数 × 单用户平均请求大小 ÷ 压缩比比如你预计每秒有5000个并发请求,每个响应体平均50KB，启用Gzip后压缩到15KB，那么峰值带宽大约需要 5000 × 15KB = 75MB/s，换算成带宽就是600Mbps，实际采购时还要留出30%的余量，避免突发流量直接占满，国内主流云厂商的带宽包价格差异较大，但按年付往往比按量付费省一半以上，如果预算有限，可以选购按95峰值计费的方案，适合大促这种波峰明显的场景。
第二道防线：CDN分流静态资源
静态资源的带宽消耗通常占据总量的70%以上，把图片、字体、公共JS/CSS全部切到CDN，源站的带宽压力会骤降，具体操作路径：
- 在CDN控制台添加加速域名,配置源站为对象存储或负载均衡。
- 设置缓存规则,对图片目录设置7天缓存，对HTML页面设置不缓存。
- 开启HTTP/2和TLS 1.3，减少握手开销。
- 大促前做一次全网URL预热,让CDN节点提前回源拉取热门图片。
这里特别提醒：CDN只解决静态资源，动态API请求仍然会穿透到源站，如果发现源站带宽依然很高，说明动态接口的响应体太大，需要做下一步优化。
第三道防线：限流和降级保护核心接口
当流量超过系统承载上限,限流是保护自身不宕机的手段，常见的限流算法有令牌桶和漏桶，分别在Guava RateLimiter和Sentinel中实现，大促期间的降级策略要提前预设开关，
- 关闭非核心的个性化推荐接口,返回默认列表。
- 将商品详情页的库存数量改为每隔5秒刷新一次。
- 搜索功能降级为简单的数据库LIKE查询。
这些操作虽然牺牲了一部分用户体验,但能确保下单、支付等核心链路不中断，业内专家指出，大促期间做有损服务比全站宕机更适合电商业务。
第四道防线：动态请求合并与压缩
动态API响应体的大小直接影响带宽消耗,常见做法包括：
- 开启Gzip/Brotli压缩，对JSON文本通常能减少60%体积。
- 合并多个接口,用
/batch端点一次返回商品信息、库存和配送时效。 - 去掉不必要的冗余字段,比如日志级别、调试信息。
- 用Protocol Buffers替代JSON，同样数据量减半。
这四道防线是层层递进的关系,每解决一层，下一层的压力就会小很多，如果四层全部上线，大多数业务场景的带宽峰值都能控制在预估范围内。
大促活动前系统压测与预案检查
预热方案和带宽策略都做好了,不能直接上线，还要通过压测验证，压测不是随便用JMeter跑几个线程组，而是要模拟真实的大促流量模型。
压测怎么测？别只测QPS
很多人关注QPS,但大促场景真正要测的是带宽、缓存命中率、数据库连接数三个指标，建议压测步骤：
- 录制线上真实请求,在测试环境回放，比例按日常、3倍峰值、5倍峰值分档。
- 压测过程中观察Redis内存使用率,确认没有超过预设阈值。
- 关注网络出口流量,对比CDN回源流量和源站带宽，确认分流比例合理。
- 压测结束后,检查缓存中是否有大量过期key同时失效，如果有，调整过期时间的随机抖动。
预案手册要写透
大促当天出问题,现场人员往往手忙脚乱，预案手册要把每个风险场景和对应的操作命令写清楚，
- Redis内存不足时：执行
redis-cli --bigkeys找出大key，然后删除或扩容。 - 带宽超限时：第一步开启CDN限速，第二步关闭图片压缩，第三步切换备用线路。
- 缓存击穿时：在接口层加互斥锁，或者使用
SETNX命令做重建缓存保护。
预案手册不是写给领导看的,是写给凌晨3点被电话叫醒的运维兄弟看的，所以每一条都要能直接执行，别写“适当优化”这种模糊描述。
关于缓存预热和带宽峰值的常见问题
缓存预热一般提前多久做？
预热时间没有固定值,主要取决于你的数据量和预热脚本执行耗时，如果数据量在百万级别，脚本跑完需要10分钟，那就提前1小时开始，留出充足的失败重试时间，预热完成后要立刻做一次随机key探测，确认缓存中确实有数据。
带宽峰值超过预估怎么办？
如果实际峰值比预估高出一倍以上,第一动作是检查是否存在CDN回源异常，比如缓存规则配置错误导致静态资源全部回源，其次查看是否有爬虫或恶意刷流量，如果是，立刻在WAF中添加拦截规则，最后一招是启用云厂商的限流策略，牺牲部分非核心请求保总体可用性。
缓存预热和数据库缓存有什么区别？
数据库缓存通常指MySQL的查询缓存或InnoDB缓冲池,它们由数据库引擎自己管理，主要加速SQL查询，而缓存预热特指应用层主动将业务数据写入Redis或本地内存，目的是减少对数据库的访问，两者层级不同，数据预热更主动，可以在流量到达前就完成数据加载，大促场景中，两层都需要调优，但预热策略主要针对应用层缓存。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/647007.html
