上个月帮江宁做生鲜电商的朋友救火。
大促当天接口超时率冲到42%，运维小哥凌晨两点被电话炸醒，排查了俩小时才找到根因——为了图省事，所有接口返回数据统统配了10分钟的缓存过期时间，连实时库存也没落下。结果用户下了单付了钱，系统才提示库存不足，客诉通道直接被刷爆。
这种事真的见太多了。
别把所有数据都塞进同一个过期时间桶
很多团队刚上缓存的时候，总想着一劳永逸，写个AOP切面，把所有接口的返回值都自动存到Redis，过期时间统一设个30分钟，上线之前觉得自己效率拉满，殊不知埋的雷能把整个业务炸穿。
商品详情页的静态图文，缓存2小时都不会有问题。但用户的实时可用余额、仓库的动态库存、直播间的在线人数，别说缓存10分钟，就算缓存30秒都可能出乱子。强实时的动态数据根本不适合长缓存，硬塞进去就是给自己找事。
真的，这种低级错误每次复盘都拍大腿，可真到赶项目上线的节点，所有人都在催进度，谁有空给你逐类拆解不同数据的过期规则啊。快上线了。能跑就行。
很多人都知道要给缓存过期时间加随机偏移，避免同一时间大量key同时失效造成雪崩，这个操作没错，但前提是你先把数据分类的事儿做对。不然就算你把偏移范围拉到半小时，把强实时数据跟静态资源堆在同一个过期桶里，该出的问题半分不会少。
缓存命中率不是越高越好
不少团队的KPI里明明白白写着，缓存命中率要冲到99%，觉得这个数字越高，技术架构越牛。
上次碰到一个做内容社区的团队，为了把命中率从92%硬拉到99.5%，把用户最近3天的浏览历史全给塞进了Redis缓存。结果内存占用直接翻了3倍，每个月的云成本多花了快两万，最后扒数据算下来，那部分缓存的实际访问率连1%都不到。
图啥啊？
缓存的本质是拿内存换数据库的性能损耗，但你换的必须是真的被频繁访问的内容。你把一个半年没人看的老帖子缓存进去，数字上的命中率是好看了，可这块占的内存，可能够存上百个热门爆款帖子的缓存。
我一般给合作团队的建议是，命中率落在85%到95%之间就够舒服了。超过这个区间，就得停下来算一笔账：你多花出去的内存成本，能不能抵上数据库省下来的性能开销？很多时候算完就会发现，硬刷上去的那几个百分点，全是赔本买卖。
还有个常见的操作误区，就是缓存预热的时候恨不得把全量数据都塞进Redis，结果服务刚启动就因为内存打满触发OOM。真没必要，预热就把访问量靠前的前20%的热门数据塞进去就行，剩下的等用户真访问了再慢慢加载，急啥？
写场景的坑比读场景多得多
大部分缓存教程都在讲读场景的优化，可真出大事故的，往往是写链路的配置错了。
最经典的问题：更新数据的时候，是先改数据库再删缓存，还是先改缓存再更数据库？很多人上来就背标准答案，读远多于写的场景，当然是先更库再删缓存。
这话没错，但不是万能的。
比如你做实时弹幕、直播间在线人数这种写频率极高的场景，要是每次数据变更都触发一次缓存删除，那Redis的压力比数据库还大。之前帮一个做直播的团队排查性能问题，峰值每秒2万条弹幕，一开始照着通用教程，每发一条弹幕就更新一次数据库，然后删一次对应的缓存key，结果Redis的删除QPS直接冲到10万，CPU占满，整个实例直接崩了。后来改成写的时候直接更新Redis里的弹幕列表，每10秒批量同步一次到数据库，QPS直接掉了90%，啥问题都没有。
写场景的缓存策略从来没有标准答案，读多写少的链路可以严格按照缓存旁路模式来，写多的场景就得灵活调整，该异步就异步，该合并就合并，别拿着教程当万能药方硬套。
做缓存这事儿，从来没有什么银弹。
别总想着搞一套策略打天下，先把自己的业务数据摸清楚，哪些是热的，哪些是冷的，哪些是不能等的，比啥都强。
下次上线前花俩小时把缓存规则捋一遍，能少熬好几个通宵。