去年双十一下午三点，运营部的群直接炸了。
商品详情页加载要8秒。
技术群里翻了半小时日志才搞明白——之前为了压成本，把全量商品静态信息的缓存过期时间设成了24小时，结果运营临时改了一千多个商品的促销价，缓存根本没主动失效，用户看到的还是原价，点进结算页才跳成新价格，投诉通道半小时塞了三百多条消息。
先搞懂缓存到底是给谁挡枪的
很多人聊缓存策略上来就列LRU、LFU、FIFO的算法区别，背得比课本还熟，真到落地的时候全错。
缓存的本质从来不是为了“让系统更快”这种空泛的目标。
它是个挡箭牌。
把那些你算一遍就要消耗大量数据库资源、而且短时间内会被重复几十上百次读的请求，全挡在数据库前面。我之前见过刚入职的实习生，为了炫技把所有接口的返回结果全塞Redis，32G的内存占得满满当当，结果真正占数据库80%负载的热点用户基础信息，反而因为淘汰策略设成了allkeys-lru，被挤得频繁回源。
图什么啊。
别硬套网上的通用模板
网上的教程写得特别全。防穿透要上布隆过滤器，防击穿要加互斥锁，防雪崩要给过期时间加随机偏移，一套套的，背熟了好像就能当高级架构师了。
不过话说回来，你要是做个内部用的小OA系统，全公司加起来两百多号人用，日峰值请求量连数据库的零头都到不了，你花一周时间搭这套复杂的缓存体系，光后续维护的成本，比直接把数据全查出来放内存里还高。
真的没必要。
策略从来没有好坏，只看和你业务的匹配度。读多写少的场景，比如公开的商品详情、历史文章内容，你就把过期时间拉长，用户改了内容、运营调了价格的时候，主动触发缓存删除就行，不用纠结什么强一致。要是读写频次差不多的场景，比如用户的实时积分、临时的活动参与状态，你就别搞长缓存了，设个10秒的短过期时间，哪怕偶尔出现几秒的数据不一致，用户刷新一下就对上了，总比你为了追求100%一致，搞一套复杂的分布式事务把系统拖得半死强。
之前有个创业团队的技术负责人跟我吐槽，说照着大厂的方案做了双写一致性保障，靠消息队列同步缓存更新，结果大促的时候消息队列堵了，缓存更新延迟了40秒，用户反复刷新看到三个不同的积分值，闹到产品那边，最后还是把策略改回了10秒短过期才解决。
折腾半天，绕了个大弯。
没人会写在教程里的落地细节
缓存这东西，真没什么玄乎的架构设计，大部分线上问题，全是细节没做到位。
第一个，内存阈值的告警一定要比实际上限早设20%。别等Redis把内存吃满了，自己启动随机淘汰策略删key的时候才反应过来。上次我遇到的那次全链路故障，就是运维忘了设告警，Redis到了最大内存限制，直接把几个热点商品的key全清了，瞬间几千个并发请求打去数据库，直接把从库打挂，整个服务瘫了12分钟。
第二个，所有key的过期时间千万别设成同一个固定值。比如你所有的商品缓存都设成凌晨1点过期，到了点所有请求一起回源，数据库不崩才怪。这个解决方法简单到离谱，在你原本的过期时间基础上，加个0到300秒的随机数，把过期时间点打散，成本为零，能挡掉80%的雪崩风险。
还有，别让那些半年都没人访问一次的冷key占着内存。我们去年清过一次Redis里的历史数据，里面存了一堆2022年的线下活动配置、早就下线的旧版接口返回值，没人删，占了快三分之一的内存，清完之后直接省了一台4核8G的云主机钱，一年大几千呢。
哦对，还有个容易被忽略的点。那些真正的热点key，别光靠被动过期更新。比如大家都在抢的限量款商品库存，你就算设了再长的过期时间，一旦热点打过来，缓存失效的那一瞬间，所有请求全挤去数据库，根本扛不住。这种key你就单独拿出来，做个本地的内存缓存，过期时间设短一点，主动更新就行。
说穿了。
99%的中小团队，根本不需要那种百万级QPS的复杂缓存架构。
把这些基础细节做扎实，比你照着大厂的PPT抄一套看起来很厉害的体系，靠谱多了。