xyZGHio

本是青灯不归客,却因浊酒恋风尘

0%

浅谈缓存模式

缓存作为实际开发中高频出现的基础组件,这里简单谈谈使用缓存的几种典型模式

abstract.jpeg

Cache Aside Pattern

Cache Aside模式,是我们日常开发中经常使用的缓存模式。该模式的目的在于保证并发的前提下尽可能减少(缓存与数据库间)数据不一致的可能,其是对AP模型下Base理论的体现。具体来说,在该模式下对于数据的读操作,步骤如下:

  1. 首先从缓存中读取数据
  2. 如果命中缓存Cache Hit,则直接进入步骤4
  3. 如果未命中缓存Cache Miss,则从数据库读取数据,并放入缓存中
  4. 返回数据结果

而对于数据的写操作,其步骤流程就很简单了

  1. 更新数据库,即将数据写入数据库
  2. 删除缓存中相应的数据

显然这里对于读操作的流程步骤没有什么争议。问题在于写操作中为什么是先写数据库、再删缓存?能不能先删除缓存再写数据库?答案显然是不能。如下图所示,当写操作刚删除完缓存中的数据时,恰好此时有一个新的读请求。其读取数据库,并设置缓存。此时缓存中Name的值为Aaron。然后写操作开始写数据库,将数据库中的Name修改为Bob。可以看到此时缓存与数据库中的数据发生不一致

figure 1.jpeg

还有人可能会问,为什么在Cache Aside模式的写操作过程中,为什么不在写完数据库后、再去写缓存呢?这样不是可以提高下一次读操作的效率么?一方面,有些场景下计算缓存值的成本可能较高,如果本次写缓存后。下次又是一次写操作,则会浪费之前所计算的缓存。故缓存的写入放在读操作中进行,即所谓的懒加载。另一方面,其同样会导致数据的一致性问题。如下图所示,有两个请求分别进行写操作。当写操作#1刚刚写完数据库,此时DB中Age的值为22。此时另外一个写操作#2则将数据库、缓存均更新为18。现在写操作#1开始写缓存,可以看到当其操作结束后。数据库、缓存中Age的值出现了不一致

figure 2.png

前面提到了Cache Aside模式只能尽可能地减少发生数据不一致的问题,其在极端情况下依然有可能会出现数据不一致。如下图所示,比如在某请求在进行读操作时,缓存中并无相应数据。造成该现象的原因有可能是因为此前刚刚完成了一次写操作,把缓存删掉了;也有可能是因为是第一次访问,缓存无数据所导致的。总之该请求的读操作需要从数据库中读取,这里记为200。这时突然有另外一个请求,即写操作#2。其迅速完成了数据库的写入将其更新为300,并同时删除了缓存。而此时读操作才开始将其此前读到的200写入缓存。显然此时缓存与数据库的数据发生了不一致

figure 3.jpeg

甚至可以说,在数据库使用主从架构时,如果从库的同步延迟较高,即虽然针对主库的写请求很快完成了写数据库、删除缓存的操作;但此时从库的数据依然还没有被同步更新过来,导致对从库的读操作访问到了旧值并回写到了缓存当中。此时同样出现了数据的不一致性问题。故针对类似这种极端场景,可以考虑在基础的Cache Aside(即写数据库、删缓存)完成后,经过一定的延迟时间后再进行一次缓存删除操作,以解决读操作把旧值写入缓存的问题。即所谓的延迟双删。当然这里第二次删除所需的延迟时间,需要根据实际业务场景来决策

Read/Write Through Pattern

在Cache Aside模式中,我们需要同时操作数据库和缓存,以保持二者间数据的同步。而在Read/Write Through模式下,则简单很多。我们只需对缓存服务进行读、写即可。由缓存服务内部实现与数据库数据的同步。换言之,在该模式下可以将缓存服务视为数据库的门面/代理。典型地,Ehcache支持该缓存模式

Write Behind Pattern

在Write Through模式中,当进行写入操作时,缓存服务内部是先写入缓存、再同步到数据库中。此举显然大大降低了性能,故提出了Write Behind模式,其不同点就在于。执行写操作时,缓存服务是先写入缓存,然后通过异步的方式写入数据库。典型地,数据库的Buffer Pool缓冲池中就使用了该缓存模式

参考文献

  1. 凤凰架构: 构建可靠的大型分布式系统 周志明著
请我喝杯咖啡捏~

欢迎关注我的微信公众号:青灯抽丝