Redis 在业务系统里最常见的角色是缓存。于是一个经典问题反复出现：更新数据时，到底先删缓存还是先写数据库？
这个问题没有脱离场景的标准答案。旁路缓存里常见选择是先更新数据库，再删除缓存；但并发读、删除失败、主从延迟和回填时序都会制造短暂不一致。
先把机制边界说清楚
这一篇讨论缓存与数据库之间的最终一致性，不承诺 Redis 能提供强一致缓存。强一致读写应回到数据库事务、锁或专门的一致性协议。
整体路径
上面这张图先把主线铺开：推荐路径降低旧值回填概率，但不能消除所有并发窗口。读 Redis 这类系统，最重要的是别只停在命令接口，要继续追问它在内存里是什么形状、在主线程上走多远、失败时会留下什么状态。
底层机制
- Cache Aside 模式通常读缓存，miss 后读 DB 并回填缓存。
- 更新时先写 DB 再删缓存，可以避免缓存先删后被旧值回填的常见窗口。
- 删除缓存失败需要重试、消息补偿或 binlog 订阅兜底。
- 延迟双删能降低部分并发窗口，但不是强一致保证。
这些机制放在一起看，就能把「这个命令能不能用」改成「这个命令在当前数据规模下还便不便宜」。Redis 的很多坑，不是命令本身错了，而是数据规模和访问方式已经越过了它的舒适区。
取舍与边界
缓存一致性本质是用短暂不一致换取读性能。你要先定义业务能容忍的脏读时间，再选择策略。
典型问题：用机制化例子排查
- 读多写少场景优先 Cache Aside，并把删除缓存做成可重试动作。
- 价格、库存、权限等敏感读要区分强一致路径和缓存路径。
- 缓存重建要加互斥或逻辑过期，避免击穿时旧值和新值互相覆盖。
- 用 binlog 订阅或事务消息做最终兜底，而不是靠代码里随手双删。
收束：一句判断
缓存一致性的目标不是永远不错，而是把错误窗口设计到业务可接受。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
