Redis双写一致性
所有的情况都是再并发情况下存在温蒂
一、先更新数据库，再更新缓存场景-不推荐
当有两个线程A、B，同时对一条数据进行操作，一开始数据库和redis的数据都为1，当线程A去修改数据库，将1改为2，然后线程A在修改缓存中的数据，可能因为网络原因出现延迟，这个时候线程B，将数据修改成了3、然后将数据库中的1也改成了3，然后线程A恢复正常，将redis中的缓存改成了2，此时就出现了缓存数据和数据库数据不一致情况。
二、先更新缓存，再更新数据库场景-不推荐
当有两个线程A、B，同时对一条数据进行操作，线程A先将redis中的数据修改为了2，然后CPU切换到了线程B，将redis中的数据修改为了3，然后将数据库中的信息也修改了3，然后线程A获得CPU执行，将数据库中的信息改为了2，此时出现缓存和数据库数据不一致情况。不推荐
三、先删除缓存，再更新数据库的场景-不推荐
当有两个线程A、B，同时对一条数据进行操作，当线程A进行修改缓存操作时，先删除掉缓存中的数据，然后去修改数据库，因为网络问题出现延迟，这时线程B查新redis没有值，因此去数据库中查询数据为1，然后将数据1更新到缓存中，线程A网络恢复，又将数据库数据修改为了2，此时出现数据不一致。不推荐，当然可以给键设置过期时间，自然过期后悔再查数据库
四、先更新数据库，在删除缓存场景-可以接受
一改一查场景
当有两个线程A、B，线程A先去将数据库的值修改为2，然后需要去删除redis中的缓存，当线程B去读取缓存时，线程A已经完成delete操作时，缓存不命中，需要去查询数据库，然后在更新缓存，数据一致性；
如果线程A没有完成delete操作（图中案例），线程B直接命中，返回的数据与数据库中的数据不一致，可能会短暂出现数据不一致情况，但最终都会一致。
存在的问题
当数据过期或者初始化时，会出现数据不一致情况
解决方案
对于不过期的数据我们要在上线的时候做好数据的预热，保证缓存命中。对于存在过期的数据，因为有过期时间，只会在特定的时间段内数据不一致，下次数据过期后，可以恢复，对于实时性要求不高时，可以接受。
两次修改场景
当有两个线程A、B，线程A去修改数据库中的值改为2，然后出现网络波动，线程B将数库中的值修改为了3，然后两个线程都会删除缓存，保证数据一致性。无非是线程A多删了一次。
但是问题来了，按照以下时序操作，可能会存在一个问题，就是最后redis和数据库中的数据不一致
上面的单删策略情况如下： 修改请求的实现中需要修改数据库后，级联删除redis中的数据。 请求一：1.1修改数据库数据 1.2 删除redis数据 请求二：2.1修改数据库数据 2.2 删除redis数据 假设现在并发存在一个查询请求 请求三：3.1查询redis中数据 3.2查询数据库数据 3.3 新查到的数据写入redis （一定要理解带redis的查询请求实现逻辑，先查redis，数据不存在查数据库，查到的数据写入redis以便以后的查询不去直接查数据库）此时并发情况下就会存在1.1 ---> 1.2 ---> 3.1 ---> 3.2 ---> 2.1 ---> 2.2 ---> 3.3的情况 此时存在的问题就是：此时数据库中的数据保存的是2.1修改后的数据，而redis中保存的数据是3.2中在1.1修改数据后的结果，此时出现了redis中数据和数据库数据不一致的情况，在后面的查询过程中就会长时间去先查redis，从而出现查询到的数据并不是数据库中的真实数据的严重问题。
那怎么解决，就需要用到经典的演示双删策略
上面的单删策略存在问题的情况如下： 请求一：1.1修改数据库数据 1.2 删除redis数据 请求二：2.1修改数据库数据 2.2 删除redis数据 请求三：3.1查询redis中数据 3.2查询数据库数据 3.3 新查到的数据写入redis 添加延时双删策略后的情况 请求一：1.1修改数据库数据 1.2 删除redis数据 1.3 延时3--5s再去删除redis中数据 请求二：2.1修改数据库数据 2.2 删除redis数据 2.3 延时3--5s再去删除redis中数据 请求三：3.1查询redis中数据 3.2 查询数据库数据 3.3 新查到的数据写入redis 双删策略为什么能解决问题： 因为存在了延时时间，故1.3或2.3 一定是最后执行的一步操作（并发中的延时一定要理解） 延时的根本目的就是为了让程序先把3.3执行完，再去删除redis
如何实现演示双删
比较好的： 项目整合quartz等定时任务框架，去实现延时3--5s再去执行最后一步任务，mq的延迟队列
如果延时双删的第二步删除失败了怎么办，则要进行重试
删除缓存重试机制
因为延时双删可能会存在第二步的删除缓存失败，导致的数据不一致问题。
可以使用这个方案优化：删除失败就多删除几次呀,保证删除缓存成功就可以了呀~ 所以可以引入删除缓存重试机制
删除缓存重试流程
-
写请求更新数据库
-
缓存因为某些原因，删除失败
-
把删除失败的key放到消息队列
-
消费消息队列的消息，获取要删除的key
-
重试删除缓存操作
读取binlog异步删除缓存
重试删除缓存机制还可以吧，就是会造成好多业务代码入侵。其实，
优化：通过数据库的binlog来异步淘汰key。
以mysql为例吧
-
可以使用阿里的canal将binlog日志采集发送到MQ队列里面
-
然后通过ACK机制确认处理这条更新消息，删除缓存，保证数据缓存一致性