上个月帮杭州一个做私域电商的朋友擦屁股。
他们大促前为了扛流量临时在网关层加了一层Redis缓存，把商品详情页的接口响应从200ms压到了20ms，本来以为稳了，结果大促开场10分钟，数据库直接被打挂，整个站卡了40分钟，算下来光投流的钱就打了水漂，更别说那些等不及退出去的用户攒下的不满。亏了快两百万。
查了半天才发现问题。
你以为的缓存，根本不是缓存
说实话，我见过80%的中小团队做缓存，都是走的歪路。上来就把热数据往内存里一塞，设个统一的TTL，就觉得万事大吉，根本没考虑数据本身的变化频率。
他们当时就是把商品详情的缓存TTL设成了1小时，结果大促的时候商品价格、库存每10秒就会变一次，运营改了价格之后根本没触发缓存主动删除，用户刷到的全是几小时前的旧价格旧库存。等用户真要下单的时候，系统发现对不上数，又把所有请求打回数据库查真实库存，等于之前搭的缓存层完全白做。
缓存最核心的矛盾从来不是“存什么”，而是“什么时候删”。好多人上来就能背熟缓存穿透、击穿、雪崩的全套定义，真落地的时候连个数据变更后主动清缓存的钩子都没写。出了问题就怪Redis性能不好，换更大的内存实例，纯纯南辕北辙。
别拿统一模板套所有业务
还有个更常见的毛病，不管什么数据类型，全用同一套缓存规则。
比如用户的浏览足迹，存个7天TTL完全没问题，没人会盯着自己的历史浏览看实时变化，就算慢个几百毫秒加载，根本没人在意。但商品的实时库存，你要是敢加10秒以上的缓存，分分钟超卖赔到哭。之前我们做生鲜配送系统的时候，要是把配送员的实时位置缓存10秒，用户看着骑手在离自己500米的地方卡了10秒，早就打电话来投诉了，但要是把菜品的分类列表缓存10分钟，根本没人会发现有什么异常。
不过话说回来，好多人觉得搞缓存就是要追求100%的命中率，其实根本没必要。你为了多凑那5%的命中率，把本来半年都没人访问一次的冷数据也塞进去，最后占了内存不说，还要花精力维护失效逻辑，算下来的机器成本和运维成本，比那点接口省的钱还多。之前有个团队，把用户三年前的浏览记录全缓存到Redis里，占了200G内存，最后统计下来，这些冷数据的访问量连总请求的0.1%都不到，纯纯浪费钱。
最后要留的那点“不完美”
真的。别信那些说什么要扛住缓存全挂的屁话。
好多人做缓存设计，总觉得要把所有异常情况都考虑到，比如缓存节点挂了怎么办，网络断了怎么办，结果写了一堆复杂的降级逻辑，最后反而因为逻辑太复杂出了新问题。我们现在的做法很简单，缓存集群全挂的时候，直接返回“当前系统繁忙，请稍后再试”，而不是硬扛着把所有请求打去数据库。你一个中小规模的业务，数据库最多扛个几千QPS，缓存全挂的时候就算写再多降级逻辑，该挂还是挂，不如直接给用户个友好提示，等个30秒缓存重连了再让大家进来，比硬扛着把数据库搞到彻底宕机强一百倍。
缓存策略的本质从来不是追求技术上的完美，而是在业务损失和技术成本之间找那个最划算的平衡点。不用追着网上的最佳实践抄，也不用羡慕大厂搞的那些复杂的多级缓存，你自己的业务什么场景能扛住多少延迟，什么情况丢点缓存用户根本不在意，摸清楚这些，比看十本架构书都有用。