redis和mysql数据一致性的问题
在这里，我们讨论三种更新策略：
- 先更新缓存，再更新数据库
- 先更新数据库，再更新缓存
- 先删除缓存，再更新数据库
- 先更新数据库，再删除缓存
第一种，先更新缓存，再更新数据库
问题：更新缓存成功，更新数据库失败，导致数据不一致。
第二种，先更新数据库，再更新缓存
问题：
1、A更新数据库
2、B更新数据库
3、B写入缓存
4、A写入缓存
出现数据不一致。
考虑另一种情况， 有如下两点：
（1）如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
（2）如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。
第三种，先删除缓存，再更新数据库。
问题：
1、A删除缓存
2、B查询数据库获取旧值
3、B更新了缓存
4、A更新数据库
出现数据不一致的问题
延时双删
public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(1000);
redis.delKey(key);
}
问题一：延时双删，演变成了：先更新数据库，再删除缓存。。。。
比如：
1、A删除缓存
2、B查询数据库获取旧值
3、B更新了缓存
4、A更新数据库
5、A延时删缓存
1～3步执行后，数据库和缓存是一致的，相当于没删除。
4～5步：先更新数据库，再删缓存。
所以延时双删演变成了：先更新数据库，再删除缓存。问题还是没解决。。。
为什么？假设，此时，在第4步执行之前，又来了个查询C，C查询到旧值。第6步：C将旧值插入缓存。此时出现缓存和数据库不一致。
延时并不能解决：C插入缓存的操作在第5步后面执行，比如C遇到网络问题、GC问题等。当然这是小概率，但并不代表不存在。
当然，延时越长，这个问题越能规避。如果业务需求不是非常严格，是可以忽略的。
问题二：吞吐量
问题三：数据库更新后，无法保证下一次查询，从缓存获取的值和数据库是一致的。
第四种，先更新数据库，再删除缓存
问题：上面C的查询，已经说明问题了。
出现数据不一致的概率，比较小。采取这个方案，取决于业务需求。
终极方案
请求串行化
真正靠谱的方案：将访问操作串行化
- 先删缓存，将更新数据库的操作放进有序队列中
- 从缓存查不到的查询操作，都进入有序队列
需要解决的问题：
- 读请求积压，大量超时，导致数据库的压力：限流、熔断
- 如何避免大量请求积压：将队列水平拆分，提高并行度。
- 保证相同请求路由正确。