前言：
今天继续我们的Redis学习，主要讲解一下Cache Aside Pattern（旁路缓存模式）
概念：
Cache Aside Pattern ，又称 Lazy Loading （懒加载）模式，是一种典型的 应用程序主动去操作缓存 的策略。
核心思想是：应用程序先从缓存中读取数据，如果缓存中没有，再去数据库加载，并把数据写入缓存。
换句话说，缓存是"旁路"式的，数据的来源仍然是数据库，缓存只是辅助，应用程序负责管理缓存。
工作原理
读取数据流程：
-
应用程序尝试从缓存中读取数据。
-
如果缓存命中（cache hit），直接返回数据。
-
如果缓存未命中（cache miss）：
-
从数据库中读取数据。
-
将数据写入缓存（可设置 TTL，防止缓存永久存在）。
-
返回数据给客户端。
-
写入数据流程：
-
当数据更新时，先更新数据库。
-
再删除缓存中对应的数据（或直接更新缓存）。
-
下次读取时，会重新加载最新数据到缓存。
关键点：应用程序负责控制缓存和数据库的数据一致性。
重点：
前面这些可以看到都非常简单易懂，那么我的问题来了：
为什么要先操作数据库，再操作缓存？
答：
场景设定：高并发下的数据更新
- 数据 X ：初始值
X=10(保存在数据库和缓存中)。 - 请求 A (写请求) ：要将
X更新为20。 - 请求 B (读请求) ：在 A 的更新操作过程中读取
X。 - 目标状态 ：数据库
X=20，缓存X=20(或缓存无X，下次读时回填)。
分类讨论一下：
错误顺序剖析：先删缓存，再更新数据库 (删除Cache -> 更新DB)
关键步骤解读（错误顺序）：
- A (写) 删缓存： 请求 A 成功删除了缓存中的
X。此时缓存为空。 - A (写) 开始更新DB（慢）： 请求 A 开始执行数据库更新操作（这通常涉及网络I/O、磁盘I/O、事务处理等，相对较慢）。
- B (读) 读缓存（未命中）： 在 A 的数据库更新完成之前 ，请求 B 来读取
X。发现缓存中没有X（因为被 A 删了）。 - B (读) 读DB（读到旧值）： 请求 B 转而查询数据库。关键点来了：此时请求 A 的
UPDATE操作可能还在进行中（未提交事务），或者虽然开始了但还没执行到X所在的记录。因此，数据库返回给 B 的仍然是旧值X=10。 - B (读) 回填缓存（写入旧值！）： 请求 B 遵循"读未命中则回填缓存"的原则，将从数据库读到的旧值
X=10写入了缓存。 - A (写) 完成DB更新： 请求 A 终于完成了数据库更新，将
X成功设置为20。 - 最终状态：
- 数据库：
X=20（新值，正确）。 - 缓存：
X=10（旧值！严重错误！）。
- 数据库：
- 严重后果： 缓存中的旧数据
X=10会一直存在 ，直到这个缓存项因为过期(TTL)被清除，或者下次有成功 的写操作再次触发删除缓存（或下一次写操作再次触发删除缓存（或下一次读请求在缓存过期后触发回填）。在这段时间内，所有读取X的请求都会拿到错误的旧值10！这就是脏数据长期驻留缓存问题。缓存完全失去了意义，甚至起到了反作用。
正确顺序剖析：先更新数据库，再删除缓存 (更新DB -> 删除Cache)
关键步骤解读（正确顺序）：
- A (写) 更新DB（慢）： 请求 A 开始执行数据库更新操作（慢）。
- B (读) 读缓存（命中旧值）： 在 A 的数据库更新完成之前 ，请求 B 读取
X。此时缓存中还有未被删除的旧值X=10，B 直接命中缓存拿到旧值。这是一个短暂的（通常只有几毫秒到几十毫秒）不一致窗口。 - A (写) 完成DB更新： 请求 A 成功将数据库中的
X更新为20。 - A (写) 删除缓存： 请求 A 立刻 删除缓存中的
X。这是最关键的一步！ - 处理并发读 (B)：
- 情况1 (B在A删缓存前读取完毕)： B 已拿到旧值
10，流程结束。缓存随后被A删除。下次读会触发回填新值20。 - 情况2 (最常见 - B已读完旧值)： 缓存中可能还有B读过的旧值
10，但被A在第4步强制删除掉了！ - 情况3 (罕见 - B在DB更新后、缓存删除前读)：
- B读缓存未命中（可能刚好被其他操作清掉，或TTL到期）。
- B读数据库，此时DB已是新值
20（因为A的更新已经完成）。 - B将**新值
20**回填到缓存。 - 紧接着 ，A执行第4步删除缓存的操作，将B刚写入的新值
20也删除了！
- 情况1 (B在A删缓存前读取完毕)： B 已拿到旧值
最终状态&自我修复
- 无论B在A的操作过程中做了什么，在A成功执行完第4步
删除缓存之后，缓存中关于X的数据一定是不存在的（被删除了）。 - 数据库的状态是确定的新值
X=20。 - 后续 任何一个读请求过来：
- 读缓存：未命中（因为X已被删除）。
- 读数据库：拿到新值
20。 - 回填缓存 ：将新值
20写入缓存。
- 系统达成最终一致： 数据库
X=20，缓存X=20。之前的短暂不一致（B读到旧值）或缓存短暂存放新值后被删除，都被后续的正常读流程自动修复了。不会出现旧数据长期污染缓存的情况！
为什么正确顺序更好？核心优势总结表
| 特性 | 错误顺序：删缓存 -> 更新DB |
正确顺序：更新DB -> 删缓存 |
优势说明 |
|---|---|---|---|
| 脏数据驻留缓存风险 | 极高 | 极低 | 错误顺序导致旧数据被读请求回填并长期留存；正确顺序通过后续删除和读回填确保缓存最终是新数据或空。 |
| 不一致持续时间 | 长 (直到下次写/缓存过期) | 短 (通常毫秒级，直到下次读请求回填) | 正确顺序下不一致窗口仅限于并发读写重叠且读在DB更新后、缓存删除前的极短时间 + 下次读请求的处理时间。 |
| 操作失败后果 | 严重 (删缓存成功+更新DB失败：缓存空+DB旧值) | 相对可控 (更新DB成功+删缓存失败：DB新值+缓存旧值) | DB有正确的新值是底线。缓存旧值可通过重试删除、TTL过期或下次触发删除修复。缓存空+DB旧值会导致数据丢失错觉。 |
| 设计理念符合度 | 低 (直接干预缓存作为写入口) | 高 (缓存是副本，写只操作数据源DB，失效缓存副本) | 逻辑更清晰，职责分离。 |
| 并发写影响 | 可能导致缓存与DB都错乱 | 无额外影响 | 正确顺序只涉及DB并发写（DB自身事务保证）和独立的缓存删除。 |
如果最后缓存中还是有旧数据，可以怎么继续进行优化？
答：
常见优化方案（按复杂度递增）
-
双删（Double Delete）
-
做法：事务提交后删一次缓存，稍微
sleep几十毫秒，再删一次。 -
作用：避免并发线程把旧值写回缓存。
-
缺点：依赖
sleep，效果不稳定，算是"土办法"。
-
-
更新缓存（而不是删除）
-
在 DB 提交成功后，直接
set(key, newValue)。 -
优点：减少旧值回写缓存的机会。
-
缺点：需要处理并发写入的覆盖问题（可能要用版本号/CAS 机制）。
-
-
版本号 / 时间戳机制
-
缓存中存储一个
version字段，每次更新时带上版本号。 -
写缓存时只在
newVersion > oldVersion时才覆盖。 -
优点：能有效防止旧值覆盖新值。
-
缺点：实现复杂度稍高。
-
-
分布式锁（针对热点 Key）
-
在回填缓存时对 Key 加分布式锁（如 Redis 的
SETNX）。 -
确保同一时刻只有一个线程能写入缓存，避免并发覆盖。
-
缺点：增加延迟，适合少量热点 Key，不适合全局使用。
-
-
事件驱动（消息队列同步）
-
DB 更新成功后，发消息到 MQ，各个服务节点订阅并失效本地缓存。
-
优点：在分布式场景下保持多实例缓存一致性。
-
缺点：引入 MQ，系统架构更复杂。
-
总结：
-
基本原则：
-
先写数据库，再操作缓存（删除或更新），因为数据库是权威数据源。
-
这样可以避免缓存中长期存在脏数据。
-
-
仍然可能的问题：
- 在高并发下，缓存中仍可能被旧数据覆盖（短暂不一致）。
-
常见优化手段：
-
双删（double delete）：DB 提交后删一次缓存，再延迟一小段时间再删一次。
-
更新缓存而不是删除：直接把新值写入缓存，减少 cache miss。
-
版本号 / 时间戳：缓存数据携带版本，只有新版本才能覆盖旧版本。
-
分布式锁：对热点 key 加锁，避免多个线程同时写缓存。
-
事件驱动（消息队列）：DB 更新后发事件，多个服务节点订阅，统一删除/更新缓存。
-
-
取舍建议：
-
大部分业务：用「先 DB → 再删缓存」足够。
-
高并发热点场景：结合版本号/锁/事件驱动，保证缓存更强一致性。
-
最后非常感谢大家的关注和支持，有任何问题都可以在评论区提出，我一定会认真解答！