嘉兴中小企业网站建设,怎样建立一个自己的网站,网站做充值和提现,做复刻手表的网站目录 1、数据不一致的原因
1.1 并发操作
1.2 非原子操作
1.3 数据库主从同步延迟
2、数据不一致的解决方案
2.1 并发操作
2.2 非原子操作
2.3 主从同步延迟
2.4 最终方案
3、不同场景下的特殊考虑
3.1 读多写少的场景
3.2 读少写多的场景 1、数据不一致的原因
导致…目录 1、数据不一致的原因
1.1 并发操作
1.2 非原子操作
1.3 数据库主从同步延迟
2、数据不一致的解决方案
2.1 并发操作
2.2 非原子操作
2.3 主从同步延迟
2.4 最终方案
3、不同场景下的特殊考虑
3.1 读多写少的场景
3.2 读少写多的场景 1、数据不一致的原因
导致缓存和数据库数据不一致的原因有三个
并发操作非原子操作数据库主从同步延迟
1.1 并发操作
假设数据库的原数据为x0考虑两种并发情况
两个线程同时写入一个线程读一个线程写
有以下4种方案
先更新缓存后更新数据库先更新数据库后更新缓存先删除缓存再更新数据库先更新数据库再删除缓存
1先更新缓存后更新数据库 两个线程同时写入 A更新缓存x1B更新缓存x2B更新数据库x2A更新数据库x1 最终缓存为2数据库为1 一个线程读一个线程写 A读取缓存发现没有命中于是读取数据库得到x0B更新缓存x1B更新数据库x1A更新缓存x0 最终缓存为0数据库为1 这种情况发生的概率极小需要同时满足几个条件 第一缓存不存在第二A的更新缓存命令 后于 B的更新缓存命令基本不可能发生第三A读取数据库更新缓存的时间 B更新缓存B更新数据库的时间基本不可能发生因为写数据库的耗时大概率是比读数据库慢 2先更新数据库后更新缓存 两个线程同时写入 A更新数据库x2B更新数据库x1B更新缓存x1A更新缓存x2 最终缓存为2数据库为1 一个线程读一个线程写 A读取缓存发现没有命中于是读取数据库得到x0B更新数据库x1B更新缓存x1A更新缓存x0 最终缓存为0数据库为1 这种情况发生的概率也是极小跟方案2的发生条件一样。 3先删除缓存再更新数据库 两个线程同时写入 由于是删除缓存多线程同时更新的话缓存都是会被删除没有讨论意义 一个线程读一个线程写 A读取缓存发现没有命中于是读取数据库得到x0B删除缓存A更新缓存x0B更新数据库x1 最终缓存是0数据库是1 4先更新数据库再删除缓存 两个线程同时写入 由于是删除缓存多线程同时更新的话缓存都是会被删除没有讨论意义 一个线程读一个线程写 A读取缓存发现没有命中于是读取数据库得到x0B更新数据库x1B删除缓存A更新缓存x0 最终缓存是0数据库是1 这种情况发生的概率也是极小需要同时满足几个条件 第一缓存不存在第二B更新数据库删除缓存的时间 A读取数据库更新缓存的时间 基本不可能发生因为写数据库的耗时大概率是比读数据库慢 1.2 非原子操作
非原子操作很好理解就是因为操作缓存和操作数据库是两步操作所以当第二步操作失败时就会导致数据不一致问题。
1.3 数据库主从同步延迟
以上都只考虑了单机数据库的情况对于主从数据库还有另一个问题就是主从同步延迟
考虑以下情况 一个往主库写入一个从从库读取 A更新主库x1A删除缓存B查询缓存没有命中查询从库得到x0从库同步主库更新为x1B更新缓存x0 最终缓存是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更好。
