sang-bit

引言

缓存与数据库的一致性即更新数据库中的记录后,缓存的数据也可要同步更新,不然会读到脏数据。事实上我们是无法保证缓存与数据库中的强一致性的,一定会有延迟,我们只能保证其最终一致性。

首先要明确的是,我们不更新缓存的数据,而是删除缓存,然后由下个请求去去缓存,发现不存在后再读取数据库,写入缓存。因为操作简单,带来的副作用也只是一次cache miss而已,删除缓存可能会因为线程安全的原因导致脏数据,比如线程a,b先后更新数据库,但是由于网络阻塞等原因,更新缓存的顺序是b,a,从而导致脏数据。

明确了删除缓存而非更新缓存的原则后,实现一致性无外乎就两种思路:

  • 先删除缓存,再更新数据库
  • 先更新数据库,再删除缓存

下面我们深入剖析这两种思路,看看谁优谁劣?

先缓存后数据库

考虑这种情况:

(1)请求 A 进行写操作,删除缓存

(2)请求 B 查询发现缓存不存在

(3)请求 B 去数据库查询得到旧值

(4)请求 B 将旧值写入缓存

(5)请求 A 将新值写入数据库

上述情况下,即使A删除了缓存,缓存中依然存在脏数据,如果没有设置过期时间,这个脏数据永远不会被清除。

这么看来这种思路并非最优解,但是上有政策下有对策,聪明的程序员们想到了使用“延迟双删”来解决这个问题。还是这个问题,使用延迟双删是这样执行的:

(1)请求 A 进行写操作,删除缓存

(2)请求 B 查询发现缓存不存在

(3)请求 B 去数据库查询得到旧值

(4)请求 B 将旧值写入缓存

(5)请求 A 将新值写入数据库

(6)请求A休眠一秒,再次删除缓存

延迟双删策略下每次更新数据库都会二次删除缓存,确保读请求结束,写请求可以删除读请求造成的缓存脏数据。

先数据库再缓存

这种方式同样会有问题,考虑这种情况:

(1)缓存刚好失效

(2)请求 A 查询数据库,得一个旧值

(3)请求 B 将新值写入数据库

(4)请求 B 删除缓存

(5)请求 A 将查到的旧值写入缓存

但是实际上很难发生这种情况,因为请求A查询完数据库一般很快就会写入缓存,很难等到 请求B更新完数据库再删除删除 还没写入缓存。如果真发生这种情况,同样可以使用延迟双删解决。

因此,保证缓存与数据库一致性一般情况下应先更新数据库,再删除缓存。

重试机制

看似问题都解决了,其实还有一个因素没有考虑到,那就是缓存删除失败怎么办?无论是第一次还是第二次,只要缓存删除失败都有可能会造成脏数据未被清空,所以我们需要重试机制保证删除缓存成功

方案一:异步重试

image-20210925132543872

把需要删除的key发送至消息队列,自己消费信息,获取需要删除的key进行重试删除操作,直至成功

这种方案的缺点是需要维护消息队列,还会对业务代码造成侵入

方案二:订阅bin log

image-20210925132918399

更新数据库数据时,数据库会将操作信息写入 binlog 日志当中,订阅程序提取出所需要的数据以及 key,另起一段非业务代码,获得该信息,尝试删除缓存操作。发现删除失败将这些信息发送至消息队列 重新从消息队列中获得该数据,重试操作。

总结

如果我们要保证缓存与数据库的一致性,一般情况下选择先更新数据库再删除缓存,配合消息队列或者订阅binlog的方式防止删除缓存失败。此外,如果对缓存中数据的实时性要求不高,可以等待key过期,这样也能保证一致性。

参考

相关文章: