redis的延迟双删策略

1，redis数据为什么会存在和数据库数据不一致的问题

在多线程并发情况下，假设有两个数据库修改请求，为保证数据库与redis的数据一致性，
修改请求的实现中需要修改数据库后，级联修改redis中的数据。
请求一：1.1修改数据库数据 1.2 修改redis数据
请求二：2.1修改数据库数据 2.2 修改redis数据
并发情况下就会存在1.1 ---> 2.1 ---> 2.2 ---> 1.2的情况

此时存在的问题就是：
1.1修改数据库的数据最终保存到了redis中，2.1在1.1之后也修改了数据库数据。
此时出现了redis中数据和数据库数据不一致的情况，在后面的查询过程中就会长时间去先查redis，
从而出现查询到的数据并不是数据库中的真实数据的严重问题。

2.单删策略为什么不能解决数据一致性问题

上面的单删策略情况如下：
修改请求的实现中需要修改数据库后，级联删除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，
从而出现查询到的数据并不是数据库中的真实数据的严重问题。

3.延迟双删为什么会确保数据一致性

添加延时双删策略后的情况
请求一：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，这个延时的时间取决于读操作的时间来设定