十七、缓存双写一致性之更新策略探讨

一、缓存双写一致性，谈谈你的理解

需要和数据库中的值相同

数据库中的值要是最新值

小数据，某条、某—小撮热点数据，要求立刻变更，可以前台服务降级一下，后台马上同步直写。

挂牌报错，凌晨升级。采用单线程，这样重量级的数据操作最好不要多线程。比如：停服更新。

目的：总之，我们要达到最终一致性！给缓存设置过期时间，是保证最终一致性的解决方案。

我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存，达到一致性，切记以mysql的数据库写入库为准。

上述方案和后续落地案例是调研后的主流+成熟的做法，但是考虑到各个公司业务系统的差距，不是100%绝对正确，不保证绝对适配全部情况，请同学们自行酌情选择打法，合适自己的最好。

可能的异常：

违背了所有数据以数据库为准的原则。

A线程先成功删除了redis里面的数据，然后去更新 mysql，此时 mysql 正在更新中，还没有结束（比如网络延时）。B突然出现要来读取缓存数据。
此时redis里面的数据是空的，B线程来读取，先去读 redis 里数据(已经被A线程delete掉了)，此处出来2个问题：（低并发，写回旧值；高并发，缓存击穿）
2.1 B从mysql获得了旧值
B线程发现redis里没有(缓存缺失)马上去mysql里面读取，从数据库里面读取来的是旧值。
2.2 B会把获得的旧值写回redis
获得旧值数据后返回前台并回写进redis(刚被A线程删除的旧数据有极大可能又被写回了)。
A线程更新完 mysql，发现 redis 里面的缓存是脏数据。于是，数据是新数据，缓存中的数据还是老的数据，导致缓存中的数据是脏的，而且还一直这样脏下去了。
总结流程：

（1）请求A进行写操作，删除缓存后，工作正在进行中......A还么有彻底更新完
（2）请求B开工，查询redis发现缓存不存在
（3）请求B继续，去数据库查询得到了myslq中的旧值
（4）请求B将旧值写入redis缓存
（5）请求A将新值写入mysql数据库

时间	线程A	线程B	出现的问题
t1	请求A进行写操作，删除缓存后，工作正在进行中......
t2		1、缓存中读取不到，立刻读mysql，由于A还没有对mysql更新完，读到的是旧值。 2、把从mysql读取的旧值，写回了redis。	1、A还未更新完mysql，导致B读到了旧值。 2、线程B遵守回写机制，把旧值写回redis，导致其它请求读取的还是旧值，A白干了。
t2	更新mysql数据库的值，over		redis是被B写回的旧值，mysql是被A更新的新值。出现了，数据不一致问题。

如果数据库更新失败，导致B线程请求再次访问缓存时，发现redis里面没数据，缓存缺失，再去读取mysql时，从数据库中读取到旧值。

加上 sleep 的这段时间，就是为了让线程B能够先从数据库读取数据，再把缺失的数据写入缓存。然后，线程A再进行删除。所以，线程A sleep的时间，就需要大于线程B读取数据再写入缓存的时间。

这样一来，其它线程读取数据时，会发现缓存缺失，所以会从数据库中读取最新值。因为这个方案会在第一次删除缓存值后，延迟一段时间再次进行删除，所以我们也把它叫做“延迟双删”。

这个删除该休眠多久呢？
在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，自行评估自己的项目的读数据业务逻辑的耗时，以此为基础来进行估算。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上加百毫秒即可。
目的就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
当前演示的效果是mysql单机，如果mysql主从读写分离架构如何？
还是使用双删延时策略。
只是，睡眠时间修改为在主从同步的延时时间基础上，加几百ms。
这种同步淘汰策略，吞吐量降低怎么办？
异步线程。

假如缓存更新失败或者来不及，导致请求再次访问redis时缓存命中，读取到的是缓存旧值。

完美方案，两害相衡趋其轻的原则。优先使用先更新数据库，再删除缓存的方案。理由如下：

如果使用先更新数据库，再删除缓存的方案：
如果业务层要求必须读取一致性的数据，那么我们就需要在更新数据库时，先在Redis缓存客户端暂存并发读请求，等数据库更新完、缓存值删除后，再读取数据，从而保证数据一致性。