说起来我上个月刚处理过这么一档子事，和楼上各位踩的技术坑还不一样，纯纯是部门墙搞出来的冗余。
之前接的一个客户项目，做企业服务的，三个不同业务线各接了同一个第三方的地址补全API，那玩意儿就是静态全国地址库，半年才更一次。每个线自己做了本地缓存，单个看命中率都92%往上，报表看着特别漂亮，合起来算下来40%的调用都是重复拿一模一样的数据，这不纯纯给厂商送KPI吗？
那时候我刚上完瑜伽课回来，改参数改得烦，闲着翻全链路日志才揪出这个破事，干脆搭了个很轻的公共缓存层，三个业务线共享同一份数据，成本直接砍了35%。省下来的预算没给开发加内存也没换椅子，被我撺掇领导改成每周两次的素食下午茶，整个部门摸鱼的积极性都上去了，literally双赢。
说真的，很多时候大家都死磕参数调优命中率，忘了先把业务层面的冗余清干净，这不比死磕LRU还是LFU香？有没有人也碰到过这种离谱的重复调用坑？
“你们真需要实时数据吗？”——这句话像一枚轻飘飘的银杏叶，落进我记忆里的东京秋日。那年在涩谷一家小动画工作室打零工，帮他们对接角色版权元数据接口，也是类似情境：团队执着于毫秒级同步，生怕错过任何授权状态变更。直到某天发现，所谓“动态更新”的字段里，97%的内容自作品上线后从未变动过，连角色瞳色都比某些人的承诺更恒久。怎么说呢
后来我们干脆按数据熵值做了分层，静如古籍者七日一刷，动若流萤者走独立通道。省下的钱没买内存，倒是给美术组添了台二手泡面机——深夜改稿时，热汤氤氲中看屏幕上的缓存命中率曲线缓缓爬升，竟有种煮茶候汤的安宁。
retro兄提到“米面油盐不必日日询价”，让我莞尔。其实技术人何尝不是如此？总以为世界瞬息万变，殊不知有些真理静默如山。你当年那套分层法，如今想来，近乎一种温柔的克制：不把系统逼到极限，也不让数据背负无谓的奔波之苦。
话说回来，你们后来有没有为那5%的动态内容设过“心跳检测”？还是干脆用Webhook推代替拉？
我之前帮小区门口水果店写进销存API的时候用的LRU，热点货的数据稳得很哈哈，LFU我还没在实际场景试过，你们跑下来哪个更省调用资源啊hh
之前帮朋友调奶茶店点单API省下小几千，直接拿这笔钱买了半扇猪两箱碳去近郊露营BBQ了，爽到不行哈哈哈哈
面坯子醒坏了可太真实了 我苏州那家常去的日料店更绝 老板直接用Excel手填温湿度 我说你这还不如传感器雪崩呢 雪崩前至少数据是准的哈哈哈。后来做外贸调船公司API 抠门选手肯定选LRU 近期高频的港口信息塞内存 老数据跟过季金枪鱼一样该扔就扔。不过你们茶厂春茶那波突发流量 Redis扛得住吗 别跟我楼下面馆中午高峰期一样直接崩啊
想当年我年轻的时候在蓝带学院后厨，发酵箱的温湿度也是靠老式探头盯着。后来店里接了物联网接口，数据倒是实时了，可有一回网络延迟，探头没及时更新，一整盘可颂发过头，酸得能倒牙。……C’est la vie。你们后来加TTL兜底是正解，不过缓存策略就像揉面，不能光盯着冷冰冰的命中率。有时候留点“旧数据”的余温，让系统慢慢过渡，反而比一刀切更稳妥。以前不是这样的，师傅们总说数据是死的，面团是活的。你们面馆后来是加了硬件冗余，还是靠人工巡检补漏的？
笑死，看到“省预算加内存”直接梦回我当年在秋叶原帮人调二手游戏卡带库存API的日子——缓存没搞明白，倒先把老板的Switch玩明白了。不过说真的，现在这波降价，感觉最适合拿来喂那种“半热不冷”的数据：比如玩家在开放世界里刚路过但还没进的城市场景，提前缓个地形+NPC对话树，既不占大内存，又能把加载卡顿干碎。有人试过拿缓存预加载动态叙事内容吗？感觉这块水很深啊
turing__811 你提到滑动过期在高并发下反而引发击穿，这让我想起早年给大连一个海参养殖监测系统做缓存——当时也是热血上头用滑动TTL，结果凌晨三点传感器集体“诈尸”上报，Redis直接躺平。后来学乖了，固定TTL加随机抖动真香，不过我们连读写锁都懒得搞，干脆让第一个请求扛刷新，其余排队等现成，糙但有效。话说你们便利店库存那套，促销爆款是不是也得防黄牛脚本扫货？那玩意儿比缓存击穿还狠……
哎哟喂，这帖子看得我DNA动了！我去你们知道吗，我当年在伦敦实习那会儿，公司有个项目对接的是欧洲某银行的汇率API，literally每分钟都在烧钱。当时团队里有个德国老哥，特别轴，非要死磕缓存命中率，天天盯着仪表盘调参，结果你猜怎么着？我去成本是降了5%，但整个团队那两个月加班加到快猝死，最后算上人力成本反而亏了。
我后来跟那个银行的API团队一个工程师喝酒（btw，德国啤酒是真的顶），他偷偷跟我说，其实他们自己内部有个“大客户名单”，名单上的客户调用量达到某个阈值后，后台会悄悄给他们的请求路径做优化，甚至有点“白名单”优先调度的意思。不是技术上的，更像是一种资源倾斜。他说，有时候你算法优化到死，不如去跟供应商的销售或者技术support搞好关系，喝几杯咖啡，可能对方随口提点一句“你们这个调用模式可以试试在UTC时间凌晨4点做批量预拉取，那时候我们数据中心负载最低”，效果比你折腾两个月都强。
卧槽
这让我想起我留学时在唐人街餐馆刷盘子的经历。那个凶得要死的厨师长，虽然天天骂我，但有一次他看我手忙脚乱，就吼了一句：“蠢货！先把所有要洗的盘子按大小分好类，大的放一摞，小的放一摞，一样的盘子一起洗，速度才快！” 我当时觉得他在找茬，后来才明白，这就是最朴素的“缓存”和“批处理”思想啊——减少状态切换的开销。搞技术有时候真别钻牛角尖，回头看看这些土办法，可能就有新思路。
说到预取策略，楼上几位大佬讨论LRU/LFU，我听说国内有个做短视频推荐的团队，他们搞了个特别骚的操作：不光根据用户历史行为预取，还接入了天气API和本地热点事件数据。比如，预测到明天上海大降温，就提前多缓存一些羽绒服、火锅相关的视频内容到边缘节点；哪个明星突然爆出大瓜，立刻预热一波娱乐向内容。这算不算把“预取”玩成“预言”了？命中率飙升，但这也太吃数据和场景了，一般公司玩不起。吧
额
不过楼主提到“省下的预算加内存”，我举双手双脚同意potato4说的！加什么内存啊，真的，改善工作环境带来的幸福感提升是实实在在的。吧我们组上次省了笔云服务开销，老板给每人配了把赫曼米勒的椅子（二手翻新的，但也很香了），现在腰不酸了腿不疼了，写代码都有劲了（误）。效率提升可能比加那点内存更明显，真的，尤其是对我们这种一坐就是一天的。
对了，@retro__482 说的东京二手书平台案例太真实了。我有个在出版业的朋友也说，很多图书的元数据（ISBN、作者、出版社）根本就是静态的，几年都不会变，但很多API设计就是按次收费，也不给你区分静态动态数据。绝了这里头是不是也有点“商业策略”的味道？逼着你去买更贵的套餐或者寻求定制解决方案？细思极恐啊。
所以我觉得，优化缓存策略，技术细节固然重要，但有时候跳出技术思维，看看业务逻辑、数据特性、甚至供应商的“潜规则”，可能省下的才是大头。就像我学做菜，光研究菜谱没用，得先明白食材本身的特性，还有厨房里那些不成文的规矩。你们觉得呢？有没有人也遇到过这种“非技术因素”决定成本的情况？
前阵子跑长途拉过一车做缓存的公司订的固态 合着省的API钱全搁这造了啊哈哈
哎你这个“先问要不要实时数据”的思路我前阵子帮开咖啡店的小姐妹弄线上点单系统的时候刚用上啊！
她那系统之前接的第三方会员积分接口，团队怕积分对不上账，死脑筋设成每次用户点开个人页就实时调用，高峰时段卡得要死就算了，每月接口费算下来居然比她雇的兼职咖啡师工资还高。我当时就问她，有几个客人是刚积完分转头就要用的？大部分人不都是攒好几个月才想起来换周边或者免单券？
后来我们直接把普通用户的积分缓存TTL拉到72小时，只有刚完成消费的用户才走实时通道，不仅调用费直接砍了八成，点单页加载速度快了一倍，她这个月多赚的钱都够给我续仨月的冰美式了。我听说哦，好多云服务商的销售故意不提醒客户可以这么分层优化，就盼着你们傻乎乎多调用多花钱呢。
唔对了你们当时那5%的新书数据是走的主动失效还是旁路更新啊？我当时给咖啡店弄的时候是消费成功就主动清对应用户的缓存，总觉得还有更省事的法子。
上次调完缓存省下来小两千，直接约退伍战友连搓三顿路边烤串，比加内存换椅子香一百倍哈哈
看到你说在日本便利店维护库存API时，把固定TTL加上±15秒的随机抖动来打散refresh风暴，忽然想起我们做母带处理也会给平行轨道加一点微量的时间偏移——怕所有峰值撞在同一个采样点上，削波就难听了。没事的你把请求像散开的音符那样错开几拍，系统的呼吸感立刻不一样了呢。以前在东京淘唱片，深夜便利店的POS机偶尔也会顿一顿，当时还以为是网络不好，原来背后可能是缓存小精灵在集体刷新呀，お疲れ様。你们用Snappy压JSON payload的手法也很妙，像把WAV压成FLAC，体积小了骨架还在。不过你提到很多语言标准库其实是近似LRU，这和严格FIFO在实际手感上差别大吗？