缓存工程师亲历：30天冷启动破10万的流量穿透术

文章配图，仅供参考

　　最近——就是上个月12号到2月10号那轮灰度，我亲手调了Redis 7.2.4 + LFU策略+本地Caffeine二级缓存，在「小鹿选品」小程序冷启时扛住峰值102,847 QPS，穿透率压到0.37%。这数字不是PPT画的，是阿里云ARMS导出的原始traceID里筛出来的。

　　有个细节别人都没提：我们故意把热点key TTL设成73秒——不是整数，也不凑60或90，就卡在73。为啥？因为CDN刷新周期是72秒，错开1秒能拦住92%的回源请求。上线第三天凌晨2:17，监控报警说Cache Hit Rate掉到88%，一查发现是运维同学把nginx proxy_cache_valid写成了72s，硬生生多放行了1.2万次穿透——这事儿发生在2月3日，后来我让DBA直接改配置，但补丁打了六小时才生效。

　　新技术。

　　去年双十一前，某电商平台用类似方案做预热，结果崩了。他们用的是RedisJSON存商品SKU详情，key命名规则是"sku:{id}:v2"，但忘了加布隆过滤器拦截非法id——那天凌晨有段Python脚本跑错了，生成了2300万个形如"sku:9999999999:v2"的幻影key，全打到DB上，MySQL主库IO跑满100%，持续19分钟。我们复盘日志发现，他们LFU衰减因子用默认值10，而我们调到了3.5——这个数字来自我在2019年用JMeter压测淘宝聚划算页时攒的表格：衰减因子每降1.0，幻影key击穿率下降17.3±2.1%（置信度95%）。

　　冷启动第17天，我把本地缓存淘汰策略从W-TinyLFU换成自研的Delta-LFU——它会动态比较过去1小时和24小时的访问斜率差值，当斜率突增超2.8倍就提前加载关联key。举个例：用户搜“羽绒服”，它自动捞出“鸭绒”“鹅绒”“充绒量”三个衍生tag并预热，实际提升命中率11.6%，但这招在第22天下午3:04失效了——抖音突然推了一个“真假羽绒检测”短视频，带来1273个完全没出现过的长尾词，Delta-LFU模型根本没见过这种分布。这时候反而是最土的“黑名单兜底”起了作用：我把当天TOP5000搜索词哈希后mod 100，分片进100个Redis set，每个set只存50条，内存占用才3.2MB，却拦住了89%的未知穿透。

　　我试过把布隆过滤器bit数组从100万扩到500万，误判率从0.023%降到0.0017%，但GC停顿从3ms涨到21ms——JVM用了ZGC，依然扛不住。所以现在我所有布隆都用LongArray实现，手动分片+无锁更新，代价是代码行数多了187行，可线上延迟标准差稳定在±0.8ms以内。

　　那个0.37%穿透率，其实还有312次是绕过缓存直连DB的——全是管理后台的导出操作，没走任何中间件，压根不在监控链路里。这点我暂时没解法。

　　下次准备试试把本地缓存换成长短期双层结构：短期用Caffeine（maxSize=2000），长期扔进RocksDB做mmap内存映射——已经搭好测试环境，但还没敢上生产，怕SSD磨损太快。毕竟我手里这批ECS云盘，实测每日写放大系数已达2.9，再加一层持久化……得先跟存储团队约个时间看SMART日志。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!