缓存双写一致性，谈谈你的理解
- 如果redis中有数据，需要和数据库中的值相同
- 如果redis中无数据，数据库中的值要是最新值
缓存按照操作来分，有细分2种 1.只读缓存
2.读写缓存
- 同步直写策略：写缓存时也同步写数据库，缓存和数据库中的数据⼀致；
- 对于读写缓存来说，要想保证缓存和数据库中的数据⼀致，就要采⽤同步直写策略
数据库和缓存一致性更新策略
目的：总之，我们要达到最终一致性！
给缓存设置过期时间，是保证最终一致性的解决方案。
我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存，达到一致性，切记以mysql的数据库写入库为准。
上述方案和后续落地案例是调研后的主流+成熟的做法，但是考虑到各个公司业务系统的差距，不是100%绝对正确，不保证绝对适配全部情况，请同学们自行酌情选择打法，合适自己的最好。
先更新数据库，再更新缓存
异常问题如下： 1 先更新mysql的某商品的库存，当前商品的库存是100，更新为99个。
2 先更新mysql修改为99成功，然后更新redis。
3 此时假设异常出现，更新redis失败了，这导致mysql里面的库存是99而redis里面的还是100 。
4 上述发生，会让数据库里面和缓存redis里面数据不一致，读到脏数据。
先删除缓存，再更新数据库
异常问题如下：
阳哥自己这里写20秒，是自己故意乱写的，表示更新数据库可能失败，实际中不可能...O(∩_∩)O哈哈~
1 A线程先成功删除了redis里面的数据，然后去更新mysql，此时mysql正在更新中，还没有结束。（比如网络延时） B突然出现要来读取缓存数据。
2 此时redis里面的数据是空的，B线程来读取，先去读redis里数据(已经被A线程delete掉了)，此处出来2个问题：
2.1 B从mysql获得了旧值 B线程发现redis里没有(缓存缺失)马上去mysql里面读取，从数据库里面读取来的是旧值。
2.2 B会把获得的旧值写回redis 获得旧值数据后返回前台并回写进redis(刚被A线程删除的旧数据有极大可能又被写回了)。
3.A线程更新完mysql，发现redis里面的缓存是脏数据，A线程直接懵逼了，o(╥﹏╥)o
两个并发操作，一个是更新操作，另一个是查询操作，A更新操作删除缓存后，B查询操作没有命中缓存，B先把老数据读出来后放到缓存中，然后A更新操作更新了数据库。
于是，在缓存中的数据还是老的数据，导致缓存中的数据是脏的，而且还一直这样脏下去了。
4 总结流程：
- （1）请求A进行写操作，删除缓存后，工作正在进行中......A还么有彻底更新完
- （2）请求B开工，查询redis发现缓存不存在
- （3）请求B继续，去数据库查询得到了myslq中的旧值
- （4）请求B将旧值写入redis缓存
- （5）请求A将新值写入mysql数据库
上述情况就会导致不一致的情形出现。
总结：
先删除缓存，再更新数据库的异常问题总结：
1.低并发情况下：写回旧值
2.高并发情况下：缓存击穿
解决方案
题外话，复习阿里内部缓存击穿的方案：
多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个 互斥锁来锁住它。其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。后面的线程进来发现已经有缓存了，就直接走缓存。
采用延时双删策略
双删方案面试题
1.这个删除该休眠多久呢 线程Asleep的时间，就需要大于线程B读取数据再写入缓存的时间。这个时间怎么确定呢？
在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，自行评估自己的项目的读数据业务逻辑的耗时，以此为基础来进行估算。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上加百毫秒即可。
这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
2.当前演示的效果是mysql单机，如果mysql主从读写分离架构如何？
- （1）请求A进行写操作，删除缓存
- （2）请求A将数据写入数据库了，
- （3）请求B查询缓存发现，缓存没有值
- （4）请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值
- （5）请求B将旧值写入缓存
- （6）数据库完成主从同步，从库变为新值 上述情形，就是数据不一致的原因。还是使用双删延时策略。
3.这种同步淘汰策略，吞吐量降低怎么办？
延迟双删会造成吞吐量降低，因为每次都得睡眠一段时间，即卡一下
先更新数据库，再删除缓存
异常问题如下：
业务指导思想
1.老外论文： docs.microsoft.com/en-us/azure… 2.知名社交网站facebook也在论文《Scaling Memcache at Facebook》中提出：www.usenix.org/system/file…
3.我们上面的canal也是类似的思想：上述的订阅binlog程序在mysql中有现成的中间件叫canal，可以完成订阅binlog日志的功能。
解决方案
先更新缓存，再更新数据库这种策略
不许问！！！
小总结
方案2和方案3用那个？利弊如何 在大多数业务场景下，我们会把Redis作为只读缓存使用。假如定位是只读缓存来说，理论上我们既可以先删除缓存值再更新数据库，也可以先更新数据库再删除缓存，但是没有完美方案，两害相衡趋其轻的原则
个人建议是，优先使用先更新数据库，再删除缓存的方案。理由如下：
1 先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力，严重导致打满mysql。
2 如果业务应用中读取数据库和写缓存的时间不好估算，那么，延迟双删中的等待时间就不好设置。
多补充一句：如果使用先更新数据库，再删除缓存的方案
一图总结如下：
