)
业内最主流的缓存方案90%互联网项目在用又叫懒加载缓存核心数据库是权威数据源应用程序全权管控缓存缓存游离在数据库读写主链路之外旁路Redis/Memcached只做辅助加速不会自动读写DB。一、标准读写流程1. 读流程先查缓存缺了查库回填应用先查缓存命中→直接返回缓存数据未命中缓存无数据→查询数据库→把DB结果写入缓存→返回数据只有被访问过的数据才进缓存不浪费内存2. 写流程先改库、后删缓存不更新缓存第一步优先更新数据库DB落新数据第二步删除对应缓存key让旧缓存失效不做「更新缓存」只删缓存下次读自动从DB拉新数据回填// 伪代码// 查询publicObjectget(Stringkey){Objectvalcache.get(key);if(valnull){valdb.query(key);cache.set(key,val);}returnval;}// 更新publicvoidupdate(Stringkey,ObjectnewVal){db.update(key,newVal);// 先改库cache.del(key);// 再删缓存}二、为什么写操作「删缓存不更新缓存」并发场景下更新缓存极易出现时序错乱、缓存存旧数据A改DB10B改DB20B抢先更新缓存20A后更新缓存10 → DB20、缓存10脏数据删除缓存就算删失败顶多下次读穿透DB重新加载最新值一致性更稳三、优缺点✅ 优点实现简单、低侵入缓存和DB解耦缓存宕机业务降级查DB即可不会整体雪崩内存利用率高按需加载只缓存热点访问数据冷数据不入缓存通用性强适配Redis、本地缓存等任意中间件读多写少场景首选商品、用户、资讯❌ 缺点短暂数据不一致DB更新成功→删缓存前新读请求命中旧缓存极短窗口期缓存穿透不存在的数据频繁查询每次都穿透到DB用布隆过滤器/缓存空值解决缓存雪崩大量key同时过期批量请求打满DB过期时间加随机偏移四、一致性优化延迟双删解决短时脏读更新DB → 立刻删缓存延时50~500ms再次删缓存干掉删缓存间隙中并发读写入的旧缓存大幅降低不一致概率五、对比另外两种缓存模式面试常考模式管控方写逻辑适用场景旁路CA应用改库删缓存读多写少绝大多数业务读写穿透缓存中间件读写都先走缓存缓存自动同步DB写频繁、要求强一致写回WriteBehind缓存异步只更缓存异步批量刷DB超高吞吐、可容忍丢少量数据六、适用场景商品详情、用户基础信息、配置数据、首页资讯等读远大于写业务是Java后端面试高频考点。