上周三跟在软件大道做电商的老朋友在珠江路撸串，他拍着大腿说上个月大促前一周，自己连续三个半夜被运维电话叫起来改线上配置，就因为缓存没跟上业务更新节奏，差点被运营团队追着扣绩效。
很多人聊起缓存策略，张嘴就是背得滚瓜烂熟的三个经典问题：穿透、击穿、雪崩。好像把布隆过滤器、互斥锁、随机TTL这几个套话搬出来，就算把缓存搞懂了。可真到了实际业务里，大多数团队踩的最大的坑，根本不是这些教科书里列的场景。
踩过最多的坑从来不是教科书上的三大问题
他上次踩的坑说出来特别简单。整个团队的商品详情页缓存，不管是日销千单的爆款，还是半年卖不出一件的冷门类目，TTL全统一设成了30分钟。大促前10分钟，运营临时调整了12个核心爆款的到手价，结果缓存里存的还是半小时前的旧价格。有用户拿着刷出来的旧价格截图找客服退差价，一晚上光补差就赔了快两万。
说实话，我见过太多团队的缓存策略文档，写了满满三页布隆过滤器的参数调优细节，结果连“什么触发场景要主动删缓存”的基本逻辑都没写清楚，纯粹是本末倒置。你花了一周时间把缓存穿透的拦截率做到99%，结果核心商品的价格更新不及时，给用户造成的直接损失，比一万个无效请求打穿数据库的影响大得多。
更有意思的是，很多人把缓存的作用理解成“给数据库挡流量”，却忘了缓存最核心的价值，是让用户看到的数据和业务侧的预期保持一致。你哪怕把数据库的压力降为0，用户刷出来的全是过期的旧信息，这套缓存策略就是完全失败的。
别上来就追求看起来高大上的架构
刚入行的时候我也总觉得，搞缓存就得搞全套：本地Caffeine缓存挡热点，Redis集群扛全量，消息队列同步更新，再整个热点自动探测的组件，才能叫专业。后来见的团队多了才发现，对大多数中小规模的业务来说，这些花里胡哨的组件带来的维护成本，远大于它能创造的价值。
别上来就追求什么高可用。先把最基础的逻辑捋顺，比什么都强。
比如第一点，不要给全量数据设置统一的固定TTL。爆款商品的访问量高，对价格变动的敏感度也高，TTL设成1-2分钟足够，既能扛住数据库的压力，也不会因为缓存存太久的旧数据出问题。那些半年没几个人看的冷数据，TTL设成2小时甚至直接存成静态资源，都不会有任何影响。
再比如第二点，核心业务数据的缓存更新不能完全依赖过期时间兜底。后台改了商品价格、调整了商家营业时间、更新了活动规则，只要是用户会直接感知到的写操作，都要在操作完成后主动删掉对应的缓存key，别等个半小时一小时的，让用户自己刷出来旧数据。这事儿真不难。
适合自己团队的才是真的好策略
之前接触过一个做本地生活的小团队，一共就4个后端开发，之前跟风抄大厂的作业，搞了Caffeine+Redis的两级缓存架构，觉得这样能把缓存命中率拉到99%。结果上线之后才发现，每次商家修改门店信息，要同时删本地和Redis两层的缓存，经常因为网络抖动漏删某一层，导致用户看到的门店营业时间是错的，一上午能收到十几个投诉。
后来他们干脆把所有的本地缓存全砍了，所有读请求直接打Redis。最开始大家还担心Redis扛不住流量，结果测下来，整体的缓存命中率从之前的95%掉到了82%，数据库的QPS只涨了不到20%，完全在可承受的范围内。反而因为去掉了复杂的两层同步逻辑，线上的一致性问题少了90%，开发维护的时间直接省了一半。算下来，这笔账太值了。
很多人总觉得缓存策略是越复杂越好，参数调得越细越专业。可实际上，你团队一共就那么几个人，日常迭代的需求都排不过来，哪有精力去维护一套需要几十个组件配合的复杂缓存架构？能把最核心的几个场景覆盖到，少出线上故障，比什么都强。
上周跟那个撸串的朋友聊完，他回去就把所有爆款商品的缓存TTL从30分钟改成了2分钟，给后台改价的接口加了主动删缓存的逻辑。这周六他们做了个小范围的促销，线上因为价格不一致产生的投诉直接降到了0。你看，根本不需要什么惊天动地的架构调整，把最基础的逻辑捋顺了，比什么花里胡哨的策略都管用。