缓存数据双写一致性

缓存数据双写一致性

缓存常被用于处理高并发,高性能问题,在现今的系统中被广泛使用。在读取缓存方面,都是先查缓存,如果击穿缓存,再查数据库等其他长期存储服务。

            graph TD
            id1(开始) --> id2{cache 中存在对应Key}
id2-->|缓存命中存在查询的key|id3(返回调用端)
id2-->|缓存未命中查询的key|id5(从存储服务加载数据)
id5-->id6(数据写入缓存)
id6-->id3
id3-->id4(结束)
          

在更新缓存方面,有了多种实现方式:

  1. 更新完数据库,更新缓存
  2. 更新完数据库,删除缓存
  3. 先删除缓存,再更新数据库

下面我们来对这几种方案进行分析。

先更新数据库,再更新缓存

假设同时有请求A和请求B进行更新操作,那么会出现

  1. 线程A更新了数据库
  2. 线程B更新了数据库
  3. 线程B更新了缓存
  4. 线程A更新了缓存

请求A更新缓存应该比请求B更新缓存早才对,但是因为网络等原因,B却比A更早更新了缓存。这就导致了脏数据,因此不考虑。

接下来讨论的就是争议最大的,先删缓存,再更新数据库。还是先更新数据库,再删缓存的问题。

先删缓存,再更新数据库

该方案会导致不一致的原因是。有一个请求A进行更新操作,同时另一个请求B进行查询操作。那么会出现如下情形:

  1. 请求A进行写操作,删除缓存
  2. 请求B查询发现缓存不存在
  3. 请求B去数据库查询得到旧值
  4. 请求B将旧值写入缓存
  5. 请求A将新值写入数据库

上述情况就会导致不一致的情形出现。而且,如果不采用给缓存设置过期时间策略,该数据永远都是脏数据。

那么,如何解决呢?采用延时双删策略。

  1. 先淘汰缓存
  2. 再写数据库(这两步和原来一样)
  3. 休眠1秒,再次淘汰缓存

这么做,可以将1秒内所造成的缓存脏数据,再次删除。那么,这个1秒怎么确定的,具体该休眠多久呢?针对上面的情形,应该自行评估自己的项目的读数据业务逻辑的耗时。然后在读数据业务逻辑的耗时基础上加上写数据的耗时即可。这么做的目的,就是确保读请求结束,写请求可以删除读请求造成的缓存脏数据。

采用这种同步淘汰策略,吞吐量降低怎么办?那就将第二次删除作为异步的。自己起一个线程,异步删除。

第二次删除,如果删除失败怎么办?维护消息队列,支持重试机制。

先更新数据库,再删缓存

Cache-Aside Pattern:

  • 失效:应用程序先从cache取数据,没有得到,则从数据库中取数据,成功后,放到缓存中。
  • 命中:应用程序从cache中取数据,取到后返回。
  • 更新:先把数据存到数据库中,成功后,再让缓存失效。

这种情况不存在并发问题么?NO.假设有两个请求,一个请求A做查询操作,一个请求B做更新操作,那么会有如下情形产生

  1. 缓存刚好失效
  2. 请求A查询数据库,得一个旧值
  3. 请求B将新值写入数据库
  4. 请求B删除缓存
  5. 请求A将查到的旧值写入缓存

如果发生上述情况,还是会发生脏数据。但是发生上述情况有一个先天性条件,就是步骤3 的写数据库操作比步骤2 的读数据库操作耗时更短,才有可能使得步骤4 先于步骤5。可是数据库的读操作的速度远快于写操作的,这一情形很难出现。从概率角度来说这种策略比第二种更安全。

当然,从严谨的角度来看,上述现象还是有可能出现的。那么我们仍需要解决这一问题。采用上面给出的异步延时删除策略,保证读请求完成以后,再进行删除操作。

上述的方法实质上是通过补偿实现了最终一致性。考虑到高性能高并发的应用场景,缓存数据双写一致性问题,并不太适合通过锁,异步队列等方式来处理。一个更安全的方法是使用乐观锁,在数据中记录version时,更新缓存时,判断version的单调性。

-------------本文结束感谢您的阅读-------------
坚持分享,您的支持将鼓励我继续创作!
0%