希望长大对我而言，是可以做更多想做的事，而不是被迫做更多不想做的事...... 首页

缓存和数据库不一致分析及解决方案及多维度化

丁D
学无止境
2019-06-03 10:08
2231已阅读

摘要在高并发的场景下如果对同一个数进行操作那么可能导致缓存和数据库不一致，本文将详细分析原因并讲解其解决方案。

###删除缓存还是更新缓存
我们存入缓存的数据，往往是经过一系列的计算才放如缓存的，而不是从数据库直接读取出来，放入缓存；所以更新缓存的代价往往会比较大。
例如：一分钟内可能修改一个字段100次，然后要将相关缓存的数据计算出来，还要查询其他的字段进行计算，然而这个缓存在1分钟内只被读一次，所以如果这时候更新缓存代价就会比较大，而删除删除的代价就小很多。
**业界上大部分是删除缓存，而不是更新缓存**
###为什么缓存和数据库会不一致？

场景1：**先更新数据库，再删除缓存**
假设先更新数据库成功，删除缓存失败，这时候数据库和缓存就不一致了。
所以先删除缓存，再更新数据库
假设删除缓存成功，更新数据库失败，这个时候，数据是一致的。因为缓存空会去数据库读取。

场景2：**先删除缓存，再更新数据库，并读取数据**
我们知道删除缓存和更新数据库是两个操作，假设有这么一种情况，我删除缓存了。然后正要去更新数据库的时候但是还没更新，这个时候来了一个读取请求，并且抢到了cpu。读请求发现缓存为空，会去数据库读取，并存入缓存，，，这个时候才更新数据库，这样就会导致缓存和数据库不一致。

当然在并发很低的情况下，出现这个问题的概率会比较低，但是在并发很高的情况下，很容易就出现这个问题的。。

解决方案：**删除缓存，更新数据库，读取数据异步串行化**

https://zhuanlan.zhihu.com/p/77587581
###异步串行化

当我们要更新数据库数据的时候将数据的唯一标识（比如修改库存，商品id/sku）放入一个jvm的内存队列中。

当我们读取请求过来的时候，如果缓存有数据，直接返回。如果没有数据，就要去读取数据库+更新缓存，这个时候也将唯一标识放在jvm的内存队列中

**注意**：**同一个标识要路由到同一个队列，并且一个队列只能由一个线程进行消费；；这种方案类似rockermq的顺序消费**。

由于队列是先进先出的，这个的话更新数据库操作（删除缓存+更新数据库）就会先于读取请求（读取数据+更新缓存）执行。

优化点：**当队列中有一个读请求的时候（读取数据+更新缓存），这个没必要放入更多的读请求了到jvm内存队列中。之后的读请求可以使用不断的轮询去读取缓存，等待jvm的那个读请求更新缓存就行**。。
当轮询等待的时候过长（200ms）可以直接读取数据库的数据并返回。

**注意**：队列中可能会堆积多个更新数据库的操作（同一数据），导致读取请求轮询超时直接读取数据库（所以要更新数据频繁的情景会怎么样）。

队列中堆积的更新操作可能是针对不同的数据项的，所以，要设当的扩大队列来分摊更新操作。

比如：如果一个内存队列里居然会挤压100个商品的库存修改操作，每隔库存修改操作要耗费10ms区完成，那么最后一个商品的读请求，可能等待10 * 100 = 1000ms = 1s后，才能得到数据

其实根据之前的项目经验，一般来说数据的写频率是很低的，因此实际上正常来说，在队列中积压的更新操作应该是很少的
针对读高并发，读缓存架构的项目，一般写请求相对读来说，是非常非常少的，每秒的QPS能到几百就不错了
一秒，500的写操作，5份，每200ms，就100个写操作