title: Redis 与数据库的一致性
date: 2021/05/26 17:00
首先，给缓存设置过期时间是可以保证最终一致性的解决方案，所以接下来的方案是保障缓存与数据库数据尽可能的更快一致。
方案主要分为以下四种情况：
- 先更新数据库，再更新缓存
- 先更新缓存，再更新数据库
- 先删除缓存，再更新数据库
- 先更新数据库，再删除缓存
更新缓存 VS 删除缓存
更新缓存: 数据不但写入数据库，还会写入缓存
删除缓存: 数据只会写入数据库，不会写入缓存，只会删除缓存
优点对比
- 更新缓存的优点: 缓存不会增加一次Miss，命中率高
- 删除缓存的优点: 操作简单，能防止更新出现的线程安全问题
那到底是选择更新缓存还是删除缓存呢，主要取决于更新缓存的复杂度，如果更新缓存的代价很小，此时我们应该更倾向于更新缓存，以保证更高的缓存命中率；如果更新缓存的代价很大，此时我们应该更倾向于删除缓存。
例如：
- 只是简单的更新一下用户余额，只操作一个字段，那就可以采用更新缓存
- 还有类似秒杀下商品库存数量这种并发下查询频繁的数据，也可以使用更新缓存
不过这种更新数值，要注意线程安全的问题，防止产生脏数据
主要还是要以业务场景为主进行选择。不过大部分场景下删除缓存操作简单，并且带来的副作用只是增加了一次Cache Miss，建议作为通用的处理方式。
先更新数据库，再更新缓存
这种方式就适合更新缓存的代价很小的数据，例如上面说的余额，库存数量这类数据，不过要注意线程安全的问题。
线程安全角度
同时有请求A和请求B进行更新操作，那么会出现
- 线程A更新了数据库
- 线程B更新了数据库
- 线程B更新了缓存
- 线程A更新了缓存
这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存，这就导致了脏数据
业务场景角度
有如下两种不适合场景
如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能；但是这种场景做啥缓存呢？
如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是也浪费性能的
先更新缓存，再更新数据库
本来这种情况应该是和第一种情况一样会存在线程安全问题的，但是这种情况是有人使用过的，根据书籍《淘宝技术这十年》里，多隆把商品详情页放入缓存，采取的正是先更新缓存，再将缓存中的数据异步更新到数据库这种方式，有兴趣了解的可以查看这篇博客: https://www.cnblogs.com/rjzheng/p/9240611.html
还有现在互联网常见的点赞功能，也可以采用这种方式，有兴趣了解的可以查看这篇文章: https://juejin.im/post/5bdc257e6fb9a049ba410098
先删除缓存，再更新数据库
简单的想一下，好像这种方式不错，就算是第一步删除缓存成功，第二步写数据库失败，则只会引发一次Cache Miss，对数据没有影响，其实仔细一想并发下也很容易导致了脏数据，例如
- 请求A进行写操作，删除缓存
- 请求B查询发现缓存不存在
- 请求B去数据库查询得到旧值
- 请求B将旧值写入缓存
- 请求A将新值写入数据库
那怎么解决呢，不着急，先看第四种情况，后面再统一说第三种和第四种的解决方案
先更新数据库，再删除缓存
这种方式也存在上面的问题，但是出现的概率比上面那种方式低，例如：
- 请求缓存刚好失效
- 请求A查询数据库，得一个旧值
- 请求B将新值写入数据库
- 请求B删除缓存
- 请求A将查到的旧值写入缓存
这样就出现脏数据了，然而，实际上出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作删除缓存，所有的这些条件都具备的概率基本并不大，但是还是会有出现的概率。
并且假如第一步写数据库成功，第二步删除缓存失败，这样也导致脏数据。
为了应对这种问题，所以提出了延时双删策略。
延时双删策略
第三种方案并发问题解决方案：
- 先删除(淘汰)缓存
- 再写数据库（这两步和原来一样）
- 休眠1秒，再次删除(淘汰)缓
第四种方案并发问题解决方案：
- 先写数据库
- 再删除(淘汰)缓存（这两步和原来一样）
- 休眠1秒，再次删除(淘汰)缓存
这个1秒应该看你的业务场景，应该自行评估自己的项目的读数据业务逻辑的耗时，然后写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可（以保证拿到旧数据的线程把数据保存到了 redis），这么做确保读请求结束，写请求可以删除读请求造成的缓存脏数据
