缓存与数据库一致性：先更库还是先删缓存

更新数据时，缓存是跟着改、还是先删掉，这个顺序问题几乎每个用缓存的团队都会碰到。多数业务记住一个结论就够：先更新数据库，再删除缓存，也就是常说的 Cache Aside（旁路缓存）模式，其余做法基本是在给它打补丁。 为什么是这个顺序 先删缓存再更库有个明显空窗：删除之后、更新完成之前，读请求会把旧值从数据库重新灌回缓存，随后新值写入库，缓存里却一直是旧值，不一致会长期存在。 先更库再删缓存理论上也有不一致窗口，但要求"读请求恰好查到旧值、又恰好在写库和删缓存之间完成回填"这种苛刻时序，概率低得多，而且缓存自带过期时间兜底。权衡下来，这个顺序是默认正确答案。 延迟双删处理什么场景 读写分离架构下有个额外的麻烦：库更新完、缓存也删了，读请求却从从库拿到还没同步过来的旧数据，又回填进缓存。这时用延迟双删：更新库、删缓存之后，隔几百毫秒再删一次： DEL cache:key # 延迟 500ms DEL cache:key 第二次删除负责清掉可能的旧值回填，延迟时长按实测的主从延迟来定。 删除失败怎么办 删缓存这步可能因网络抖动失败，处理办法是异步重试：把失败的 key 丢进消息队列，消费端再删一遍直到成功。别在请求路径里同步死循环重试，拖住业务得不偿失。 强一致场景别用缓存硬扛 库存扣减、账户余额这类必须强一致的数据，不要指望缓存方案兜住，直接读写数据库，用行锁或乐观并发控制保证正确性；缓存只放展示类、能容忍短暂不一致的数据。先把数据按一致性要求分好类，再谈方案，是这件事的第一步。