by shihang.mai
注意贯穿全文：引入缓存的目的就是提速
注意贯穿全文：引入缓存的目的就是提速
注意贯穿全文：引入缓存的目的就是提速
重要事情说3遍！！！！
1. 引入缓存导致的问题
引入redis确实能提速，但是也引入了一个数据库-缓存数据一致性的问题。这正是本文讨论的焦点
我们大可以这样做:
- 将数据库数据全部放到redis，并且不设置ttl,这样可以做到redis全部命中
- 写请求还是操作库，保持库是最新的数据
- 然后启动一个定时任务，定时将库最新的数据刷新到redis
但是这个方案也有明显的缺点
- redis利用率低，因为不经常访问的数据都在redis中了
- 缓存和数据库的一致性有一定延时
2. 同时更新缓存和数据库方案
2.1 缓存利用低
我们可以这么做
- 写请求还是操作库，保持库是最新的数据
- 读请求先读redis，如果redis不存在，则从数据库读取，并重建redis
同时，写入redis中的数据，都设置ttl
这样就可以做到redis中的数据都是热数据，缓存利用率提高。
2.2 一致性延迟
在1中的方案的延时，取决于定时任务的频率。那么我们就不用定时任务了。我们可以这么做，当更新数据时，同时更新数据库和缓存即可。但问题来了，更新两者的先后问题。
- 先更新缓存，后更新数据库
- 先更新数据库，后更新缓存
其实，在没异常和没并发的情况下，两个顺序都没问题
2.3 (异常、并发)和顺序的关系
2.3.1 异常和顺序的关系
1. 先更新缓存，后更新数据库
or
2. 先更新数据库，后更新缓存
因为有异常，那么会导致第一步成功，第二部失败的情况
2.3.1.1 先更新缓存，后更新数据库
如果缓存更新成功了，但数据库更新失败
那么此时缓存中是最新值，但数据库中是旧值
虽然此时读请求可以命中缓存，拿到正确的值，但是，一旦ttl失效，然后请求从数据库中读取到旧值，重建缓存也是这个旧值。
这时Clinet会发现自己之前修改的数据又「变回去」了，对业务造成影响
2.3.1.2 先更新数据库，后更新缓存
如果数据库更新成功了，但缓存更新失败
那么此时数据库中是最新值，缓存中是旧值。
之后的读请求读到的都是旧数据，只有当ttl失效后，才能从数据库中得到正确的值。
这时Clinet会发现，自己刚刚修改了数据，但却看不到最新数据，一段时间过后，数据才变更过来，对业务也会有影响
一句话总结: 无论哪个顺序都有问题
2.3.2 并发和顺序的关系
这里先说，在并发情况下，无论哪个顺序都一样有问题，我就选个
先更新数据库，后更新缓存来说明问题吧
有线程 A 和线程 B 两个线程，需要更新同一条数据。A线程将age = 18，B线程将age= 28
1. 线程 A 更新数据库 age = 18
2. 线程 B 更新数据库 age = 28
3. 线程 B 更新缓存 age = 28
4. 线程 A 更新缓存 age = 18
结果明显了,数据库age = 28 缓存age = 18
3. 删除缓存方案
这个方案也会有顺序。
1. 先更新数据库，后删除缓存
or
2. 先删除缓存，后更新数据库
3.1 (异常、并发)和顺序的关系
3.1.1 异常和顺序的关系
1. 先更新数据库，后删除缓存
or
2. 先删除缓存，后更新数据库
因为有异常，那么会导致第一步成功，第二部失败的情况
3.1.1.1 先更新数据库，后删除缓存
略了，自己分析吧，你们行的
3.1.1.2 先删除缓存，后更新数据库
略了，自己分析吧，你们行的
3.2.1 并发和顺序的关系
这里先说，在并发情况下，这次例子是读写并发，无论哪个顺序都一样有问题。只是概率问题
3.2.1.1 先删除缓存，后更新数据库
有线程 A 和线程 B 两个线程，同时针对同一条数据，原值age = 28，A线程将age = 18，B线程读数据
1. A线程删除缓存
2. B线程读取缓存，发现没，直接读数据库age = 28
3. A线程将数据库age = 18
4. B线程重建缓存，缓存age = 28
结果明显了,数据库age = 18 缓存age = 28
3.2.1.2 先更新数据库，后删除缓存
有线程 A 和线程 B 两个线程，同时针对同一条数据，原值age = 28，A线程将age = 18，B线程读数据
1. B线程读取数据库，读到age = 28
2. A线程将数据库age = 18
3. A线程删除缓存
4. B线程重建缓存，缓存age = 28
结果明显了,数据库age = 18 缓存age = 28
还是一句话: 无论哪个顺序都有问题
那是不是搞不了?其实我们分析一下吧，说的是一致性问题注意。
- 先删除缓存，后更新数据库
这种情况发生，只需要读写并发，概率很大 - 先更新数据库，后删除缓存
这种情况发生需要【读写并发】【缓存刚失效】【步骤2+3的时间<步骤1+4的时间】，兄弟，步骤2写操作要对数据库加锁的，所以说，概率低而已
既然哪种都不行，我们就选个概率低的吧，下面全部讨论
先更新数据库，后删除缓存
到此解决了并发的问题，但是我们上面提到的异常情况还没解决，接下来我们来解决异常的情况的问题
4. 解决异常问题
其实最简单的办法就是重试。但是重试有下面几点明显的问题
- 一般立即重试，一般会继续失败
- 就算你设置了休眠时间，那重试多少次合适呢？
- 重试还会一直占用当前线程呢
既然这样，我们换一种想法，用异步重试即可，我们可以用项目中经常用到的MQ
- 先写数据库
- 向MQ写消息
- 消费者消费消息，删除redis
还有另外一个方案，直接引入canal，这样
- 先写数据库
- canal监听binlog的变化，然后投递到MQ
- 消费者消费消息，删除redis
到现在我们使用先写数据库，再删缓存的方式去保证一致性，其中删除缓存使用MQ或者canal配合。
5. mysql读写分离+主从复制延迟
就算我们使用【先写数据库，再删缓存】，在 【mysql读写分离+主从复制延迟】其实还是会导致问题的
有线程 A 和线程 B 两个线程，同时针对同一条数据，原值age = 28，A线程将age = 18，B线程读数据
1. 线程 A 更新主库 age = 18
2. 线程 A 删除缓存
3. 线程 B 查询缓存，没有命中，查询从库得到旧值age = 28
3. 从库同步主库完成age = 18
4. 线程 B 将age = 28写入缓存
结果明显了,数据库age = 18 缓存age = 28
这就引出了缓存延时双删方案，但是这个方案这个时间其实在高并发环境中很难估计，只是降低不一致的概率
- 先写数据库
- 删除缓存
- 发送延时消息到MQ，消费者再删除缓存一次
6. 思考
所以可以用分布式锁做强一致，但是引入缓存在文章开头已经说过，是为了性能，要强一致，必然会导致性能急剧下降。矛盾呀，矛盾呀！
