47GB内存，94%的缓存未命中率。这组数字来自一支把"全量缓存"当银弹的工程团队——他们花了三周时间，把数据库内容一股脑塞进Redis，结果系统比原来还慢。
这不是段子，是Stackademic技术博客上的真实复盘。作者用这段经历解释了为什么"缓存一切"是工程师最昂贵的幻觉。
数据冲击：47GB买来了什么
团队最初的逻辑很朴素：数据库查询慢，那把所有数据塞进内存不就行了？Redis号称能扛10万QPS，他们买了大内存实例，写了同步脚本，看着监控面板上的内存曲线一路飙到47GB，心里踏实了不少。
上线第一天，缓存命中率6%。换句话说，94%的请求穿透了缓存，直接砸向数据库。
作者算了笔账：他们缓存了用户表、订单表、商品表的全量数据，但真实业务里，90%的查询集中在最近7天的活跃数据。那些三年前注册却从未登录的用户记录，安静地躺在Redis里占着内存，从未被访问过。
更讽刺的是，为了维护这47GB的"冷数据"，他们还搭进去一套复杂的过期策略和同步机制，CPU开销比原来高了40%。
事件还原：三周踩完三个坑
复盘时间线，团队犯了三个递进式的错误。
第一坑：把缓存当数据库用。 他们缓存的不是"计算结果"，而是原始数据行。作者打了个比方：这就像为了不用去图书馆，把整栋楼的藏书复印一份堆在家里——你确实省下了借书的时间，但得先在一堆复印纸里翻找，还要操心这些纸发霉、过期。
Redis的设计初衷是加速热点访问，不是替代磁盘存储。当数据量超过物理内存的合理比例（通常建议70%），Redis开始频繁触发内存淘汰，CPU花在数据腾挪上的时间比服务请求还多。
第二坑：缓存键设计照搬表结构。 他们用`user:123`、`order:456`这种直白的键名，导致缓存粒度太细。一个页面请求需要拉取用户资料、最近订单、推荐商品，得发十几个Redis命令，网络往返时间累加起来，比直接查数据库还慢。
作者提到，他们后来改成按页面聚合缓存——比如`homepage:user:123`打包了该用户首页所需的全部数据，命令数降到1个，延迟从120ms降到15ms。
第三坑：没有失效策略的缓存是定时炸弹。 他们最初给所有键设置了24小时过期，以为这样很安全。结果每天凌晨，数百万键同时过期，Redis的过期删除线程跑满CPU，请求队列堆积，服务出现周期性雪崩。
解决方法是把过期时间打散：基础过期时间24小时，加上0-3600秒的随机偏移。峰值被削平，但作者承认，这只是治标不治本——根本问题还是缓存了不该缓存的东西。
关键节点：94%到6%的反转
真正的转折点来自一次生产事故。某天数据库主库CPU飙到95%，他们紧急扩容缓存实例到64GB，命中率却纹丝不动。
「我们盯着监控看了两小时，才发现问题，」作者在博客里写，「那些新扩容的内存，被用来缓存了更多没人访问的数据。」
团队被迫做了一次痛苦的清理：用Redis的`OBJECT FREQ`命令（需要4.0+版本和LFU策略）分析键的访问频率，删掉过去72小时零访问的键。47GB数据里，真正被频繁访问的不到800MB。
他们最终保留了这套"热数据识别"机制，配合应用层的本地缓存（Caffeine）做二级加速。Redis内存降到3GB，命中率反而爬到87%。
启示：缓存的隐藏成本
作者用了一个产品经理熟悉的类比：缓存和促销补贴一样，都是"看起来免费，实则贵得吓人"的东西。内存要钱，同步逻辑要维护成本，过期策略要脑力，缓存穿透和雪崩要预案。
他给了一个简单的决策框架：缓存之前，先问自己三个问题——这个数据被访问的频率有多高？计算成本有多大？失效后的一致性要求是什么？三个问题里有两个答不上来，就别急着上Redis。
文章最后贴了一张截图：优化后的监控面板，Redis内存曲线平稳在3GB，命中率绿线稳定在85%以上。配文是团队内部的一句调侃——「我们花了三周学会一件事：快，不等于把所有东西塞进内存。」
如果你的团队正在规划"全量缓存"方案，你会先缓存哪张表？
热门跟贴