目录
1、数据不一致的原因
1.1 并发操作
1.2 非原子操作
1.3 数据库主从同步延迟
2、数据不一致的解决方案
2.1 并发操作
2.2 非原子操作
2.3 主从同步延迟
2.4 最终方案
3、不同场景下的特殊考虑
3.1 读多写少的场景
3.2 读少写多的场景
1、数据不一致的原因
导致缓存和数据库数据不一致的原因有三个
- 并发操作
- 非原子操作
- 数据库主从同步延迟
1.1 并发操作
假设数据库的原数据为x=0，考虑两种并发情况
- 两个线程同时写入
- 一个线程读，一个线程写
有以下4种方案
- 先更新缓存，后更新数据库
- 先更新数据库，后更新缓存
- 先删除缓存，再更新数据库
- 先更新数据库，再删除缓存
（1）先更新缓存，后更新数据库
两个线程同时写入
- A更新缓存，x=1
- B更新缓存，x=2
- B更新数据库，x=2
- A更新数据库，x=1
最终缓存为2，数据库为1
一个线程读，一个线程写
- A读取缓存发现没有命中，于是读取数据库，得到x=0
- B更新缓存，x=1
- B更新数据库，x=1
- A更新缓存，x=0
最终缓存为0，数据库为1
这种情况发生的概率极小，需要同时满足几个条件
- 第一，缓存不存在
- 第二，A的更新缓存命令 后于 B的更新缓存命令（基本不可能发生）
- 第三，A读取数据库+更新缓存的时间 > B更新缓存+B更新数据库的时间（基本不可能发生，因为写数据库的耗时大概率是比读数据库慢）
（2）先更新数据库，后更新缓存
两个线程同时写入
- A更新数据库，x=2
- B更新数据库，x=1
- B更新缓存，x=1
- A更新缓存，x=2
最终缓存为2，数据库为1
一个线程读，一个线程写
- A读取缓存发现没有命中，于是读取数据库，得到x=0
- B更新数据库，x=1
- B更新缓存，x=1
- A更新缓存，x=0
最终缓存为0，数据库为1
这种情况发生的概率也是极小，跟方案2的发生条件一样。
（3）先删除缓存，再更新数据库
两个线程同时写入
由于是删除缓存，多线程同时更新的话，缓存都是会被删除，没有讨论意义
一个线程读，一个线程写
- A读取缓存发现没有命中，于是读取数据库，得到x=0
- B删除缓存
- A更新缓存，x=0
- B更新数据库，x=1
最终，缓存是0，数据库是1
（4）先更新数据库，再删除缓存
两个线程同时写入
由于是删除缓存，多线程同时更新的话，缓存都是会被删除，没有讨论意义
一个线程读，一个线程写
- A读取缓存发现没有命中，于是读取数据库，得到x=0
- B更新数据库，x=1
- B删除缓存
- A更新缓存，x=0
最终，缓存是0，数据库是1
这种情况发生的概率也是极小，需要同时满足几个条件
- 第一，缓存不存在
- 第二，B更新数据库+删除缓存的时间 < A读取数据库+更新缓存的时间 （基本不可能发生，因为写数据库的耗时大概率是比读数据库慢）
1.2 非原子操作
非原子操作很好理解，就是因为操作缓存和操作数据库是两步操作，所以当第二步操作失败时，就会导致数据不一致问题。
1.3 数据库主从同步延迟
以上都只考虑了单机数据库的情况，对于主从数据库还有另一个问题，就是主从同步延迟
考虑以下情况
一个往主库写入，一个从从库读取
- A更新主库，x=1
- A删除缓存
- B查询缓存没有命中，查询从库，得到x=0
- 从库同步主库，更新为x=1
- B更新缓存，x=0
最终，缓存是0，数据库是1
2、数据不一致的解决方案
2.1 并发操作
根据1.1的几种方案，『先更新数据库，再删除缓存』是最好的。
2.2 非原子操作
最简单的解决办法就是重试，但是重试也要考虑一些问题：
- 立即重试的话大概率会失败；
- 重试次数设置多少比较合适；
- 同步重试会一直占用资源；
- 重试的过程中服务重启，会导致重试的操作消失，数据会一直不一致
所以就能想到异步重试方法，也就是把重试的这个操作写入到消息队列里，由另一个线程专门来处理重试的操作，而且消息队列本身可以保证消息不丢失（不丢失有两个方面，一是消息持久化，二是只有正确被消费掉了才会删除）
除了消息队列这中异步重试方案外，业界还有一种监听数据库bin log的方式，监听到变化后再去操作缓存，但是这种会额外引入其他的中间件而且实现复杂，综合而言没有消息队列的方案好用。
2.3 主从同步延迟
主从同步延迟的解决方案也很明显，就是延迟删除缓存，但是延迟多久再执行删除呢？这个就要靠经验了，一般来说1~5秒不等，看具体业务
所以在之前方案的基础上，引入延迟删除可以解决主从同步延迟的问题。
2.4 最终方案
1）更新数据库
2）删除缓存
3）如果删除失败则额外写入一条重试删除命令到消息队列
4）最后写入一个延迟删除命令到消息队列
3、不同场景下的特殊考虑
3.1 读多写少的场景
这种场景下，redis的作用是为了减轻数据库读取压力、加速读取，往往能接受一定的数据延迟，即保证最终一致性即可。
- 读多，所以删除缓存操作会导致缓存穿透问题（key不存在，大量请求命中数据库）
- 写少，所以基本不存在并发写入的问题，但是会存在并发读取和写入的问题
所以，读多写少的场景下，方案3和4是容易出现大问题的。
方案1和方案2是相对能接受的，但是也会有一定概率存在并发写入导致数据不一致的问题。
此时我们可以通过给缓存设置过期时间，使得数据保证最终一致性。
3.2 读少写多的场景
这种场景下，redis的作用是为了减轻数据库写入压力，对数据的一致性要求较高。
- 读少，所以并发读取和写入的情况比较少
- 写多，所以并发写入的情况比较多
由于并发写入情况比较多，此时方案3和4比较好，根据上文的分析，方案4比方案3更好。
