数据库与缓存双写不一致问题分析与解决方案设计

一、说明

根据 Cloud Design Patterns 一书中关于缓存模式的 Cache Aside Pattern 说明，其主要内容总结如下：

• 读取的时候，先读取缓存，如果缓存中没有，就直接从数据库中读取，然后取出数据后放入缓存
• 更新的时候，先删除缓存，再更新数据库

二、数据库与缓存读写模式策略

写完数据库后是否需要立即更新缓存还是直接删除缓存？
（1）、如果写数据库的内容与更新到缓存中的内容是一样的，不需要经过任何的计算，可以立即更新到缓存；但是如果对于那种写数据频繁而读数据少的场景并不合适这种解决方案，因为也许还没有任何的查询请求到来之前，数据就被删除或修改了，这样会浪费时间和资源。

（2）、如果写数据库的内容与更新到缓存中的内容不一致，写入缓存中的数据需要经过几个表的关联计算后得到的结果插入缓存中，那就没有必要马上更新缓存，只要删除缓存即可，等到查询的时候在去把计算后得到的结果插入到缓存中即可。

所以一般的策略是当更新数据时，先删除缓存数据，然后更新数据库，等要查询的时候才把最新的数据更新到缓存。

三、数据库与缓存双写情况下导致数据不一致问题

场景一

    当更新数据时，如更新某商品的库存，当前商品的库存是100，现在要更新为99，先将数据库库存修改为99，然后删除缓存，发现删除缓存失败了，这意味着数据库中的库存是99，而缓存是100，这导致数据库和缓存不一致。

场景一解决方案

    这种情况应该是先删除缓存，然后在更新数据库，如果删除缓存失败，那就不要更新数据库，如果说删除缓存成功，而更新数据库失败，那查询的时候只是从数据库里查了旧的数据而已，这样就能保持数据库与缓存的一致性。

场景二

    在高并发的情况下，如果当删除完缓存的时候，这时去更新数据库，但还没有更新完，另外一个请求来查询数据，发现缓存里没有，就去数据库里查，还是以上面商品库存为例，如果数据库中产品的库存是100，那么查询到的库存是100，然后插入缓存，插入完缓存后，原来那个更新数据库的线程把数据库更新为了99，导致数据库与缓存不一致的情况

场景二解决方案

    遇到这种情况，可以用队列来解决这个问题，创建几个队列，如20个，根据商品的ID去做hash值，然后和队列个数取摸，当有数据更新请求时，先把它丢到队列里去，当更新完后再从队列里删除，如果在更新的过程中，遇到以上场景，先去缓存里看下有没有数据，如果没有，可以先去队列里看是否有相同商品ID在做更新，如果有，则把查询的请求发送到队列里去，然后同步等待缓存更新完成。

    优化点：相同商品的数据，如果发现队列里已经有一个查询请求了，那么就不要放新的查询操作进去了，用一个while（true）循环去查询缓存，当等待时长超过200MS时，如果缓存里还没有则直接取数据库的旧数据。原因：如果队列中存在N多个读请求，当处理线程处理的时候，就会处理N次的DB查询并写入缓存的操作，这无疑是增加DB的负担。


在高并发下解决场景二要注意的问题
（1）读请求长时阻塞
由于读请求进行了非常轻度的异步化，所以一定要注意读超时的问题，每个读请求必须在超时时间范围内返回，例如，200ms，该解决方案最大的风险在于，可能数据更新很频繁，导致队列中积压了大量的更新操作在里面，然后读请求会发生大量的超时，最后导致大量的请求直接走数据库，像遇到这种情况，一般要做好足够的压力测试，如果压力过大，需要根据实际情况添加机器。

（2）请求并发量过高
 这里还是要做好压力测试，多模拟真实场景，并发量在最高的时候QPS多少，扛不住就要多加机器，还有就是做好读写比例的测算。
如果一秒有500的写QPS，那么要测算好，可能写操作影响的数据有500条，这500条数据在缓存中失效后，可能导致多少读请求，发送读请求到库存服务来，要求更新缓存？

（3）多服务实例部署的请求路由
可能这个服务部署了多个实例，那么必须保证说，执行数据更新操作，以及执行缓存更新操作的请求，都通过nginx服务器路由到相同的服务实例上

（4）热点商品的路由问题，导致请求的倾斜
某些商品的读请求特别高，全部打到了相同的机器的相同丢列里了，可能造成某台服务器压力过大，因为只有在商品数据更新的时候才会清空缓存，然后才会导致读写并发，所以更新频率不是太高的话，这个问题的影响并不是很大，但是确实有可能某些服务器的负载会高一些。

四、数据库与缓存数据一致性解决方案流程图

    以上内容引用自：https://blog.csdn.net/simba_1986/article/details/77823309

五、数据库与缓存数据一致性解决方案简单代码示例

源代码地址：https://github.com/sunqiangwei/RedisAndDBDoubleWriteConsistency

说明：

1、源代码中使用了BitSet来进行标志位的设置，至于原因，请参见：《java bitmap/bitvector的分析和应用》。

2、源代码中修改了RequestProcessorThread在运行的过程中，会返回return true的bug。

3、目前的版本中如果队列中出现了N多次的强制刷新操作时，就会直接进行DB查询并更新，其实这一步还是有优化的空间的。