在使用redis时，最常见的就是数据库和缓存的一致性问题，现在普遍的做法就是采用延时双删，我们来分析下为什么采用延时双删
1，首先要理解在并发环境下redis数据一致性的问题所在
在多线程并发情况下，假设有两个数据库修改请求，为保证数据库与redis的数据一致性，
修改请求的实现中需要修改数据库后，级联修改redis中的数据。
请求1：1.1修改数据库数据 1.2 修改redis数据
请求2：2.1修改数据库数据 2.2 修改redis数据
并发情况下就会存在1.1 ---> 2.1 ---> 2.2 ---> 1.2的情况
（一定要理解线程并发执行多组原子操作执行顺序是可能存在交叉现象的）
此时存在的问题就是：
1.1修改数据库的数据最终保存到了redis中，2.1在1.1之后也修改了数据库数据。
此时出现了redis中数据和数据库数据不一致的情况，在后面的查询过程中就会长时间去先查redis，
从而出现查询到的数据并不是数据库中的真实数据的严重问题。
问题解决：
修改数据库级联修改redis数据改为 修改数据库数据后级联删除redis数据
至于是先执行1.2的redis删除，还是限制性2.2的redis删除，无关紧要。
结果都是redis中数据已被删除。之后的查询就会由于redis中没有数据而去查数据库，
此时即不会存在查询到的数据和数据库的数据不一致的情况。
2，上面详解了redis数据一致性的问题所在，并提供了单删策略来解决问题
但此时依然存在比较严重的问题。
上面的单删策略情况如下：
修改请求的实现中需要修改数据库后，级联删除redis中的数据。
请求1：1.1修改数据库数据 1.2 删除redis数据
请求2：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，上面刨析到了单删策略来解决redis数据一致性存在的问题，下面我们来说双删策略
上面的单删策略存在问题的情况如下：
请求1：1.1修改数据库数据 1.2 删除redis数据
请求2：2.1修改数据库数据 2.2 删除redis数据
请求3：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
4，小结
- 延迟双删用比较简洁的方式实现 mysql 和 redis 数据最终一致性，但它不是强一致。
- 延迟是指当前请求逻辑处理延时，而不是当前线程或进程睡眠延迟。
- mysql 和 redis 数据一致性是一个复杂的课题，通常是多种策略同时使用，例如：延迟双删、redis 过期淘汰、通过路由策略串行处理同类型数据、分布式锁等等。
延时的时间应该大于数据库查询时间+缓存写入的时间，待其他线程读取db旧数据存入redis
