1. 旁路缓存 Cache-Aside
旁路缓存模式，它的提出是为了尽可能地解决缓存与数据库的数据不一致问题。
读请求：
- 读的时候，先读缓存，缓存命中的话，直接返回数据
- 缓存没有命中的话，就去读数据库，从数据库取出数据，放入缓存后，同时返回响应。
写请求：
写的的时候，先更新数据库，然后再删除缓存。
2. 删除缓存
为什么是删除缓存而不是更新缓存呢？
- 线程A先发起一个写操作，第一步先更新数据库
- 线程B再发起一个写操作，第二步更新了数据库
- 由于网络等原因，线程B先更新了缓存
- 线程A更新缓存。
这时候，缓存保存的是A的数据（老数据），数据库保存的是B的数据（新数据），数据不一致了，脏数据出现啦。如果是删除缓存取代更新缓存则不会出现这个脏数据问题。
更新缓存相对于删除缓存还有两点劣势：
- 如果你写入的缓存值，是经过复杂计算才得到的话。更新缓存频率高的话，就浪费性能啦。
- 在写数据库场景多，读数据场景少的情况下，数据很多时候还没被读取到，又被更新了，这也浪费了性能呢(实际上，写多的场景，用缓存也不是很划算了)
3. 先更新数据库，后删除缓存
无论先操作db还是cache，都会有各自的问题，根本原因是cache和db的更新不是一个原子操作，因此总会有不一致的问题。
场景1：先删缓存，再更新数据库
- 线程 A 要更新 X = 2（原值 X = 1）
- 线程 A 先删除缓存
- 线程 B 读缓存，发现不存在，从数据库中读取到旧值（X = 1）
- 线程 A 将新值写入数据库（X = 2）
- 线程 B 将旧值写入缓存（X = 1）
最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），发生不一致。
可见，先删除缓存，后更新数据库，当发生「读+写」并发时，还是存在数据不一致的情况。
场景2：先更新数据库，再删缓存(✓)
- 缓存中 X 不存在（数据库 X = 1）
- 线程 A 读取数据库，得到旧值（X = 1）
- 线程 B 更新数据库（X = 2)
- 线程 B 删除缓存
- 线程 A 将旧值写入缓存（X = 1）
最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），也发生不一致。
其实概率「很低」，这是因为它必须满足 3 个条件：
- 缓存刚好已失效
- 读请求 + 写请求并发
- 更新数据库 + 删除缓存的时间（步骤 3-4），要比读数据库 + 写缓存时间短（步骤 2 和 5）
仔细想一下，条件 3 发生的概率其实是非常低的。所以在大多数情况下，在不想做过多设计，增加太大工作量的情况下，请先更新数据库，再删缓存!
4. 头脑风暴
- 先更新数据库，再删除缓存。
- 另外一个八股文方案：延时双删。先删除缓存，再更新数据库，延迟几百毫秒再删除缓存数据。
- 缓存删除失败考虑重试机制，和缓存设置过期策略。
