修改数据时,先更新缓存还是数据库?

一道面试题

修改数据时,先更新缓存还是数据库?
答:其实问题本身并没有标准答案,不同的场景有不一样的一致性要求,要求的越多,系统耗费的代价就越大,复杂度也越高。
如果仅限于数据库和缓存两者之间操作先后顺序,那么最容易接受的应该先更新数据库,再删除缓存,这种策略叫做旁路缓存策略(Cache Aside Pattern)

选择旁路缓存策略的原因

其实对于数据库和缓存关系大体上有四种操作顺序:

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

下面分别讨论四种情况肯能产生的问题,假设A和B两条线程并发访问,更新数据库同一个字段,字段原值为origin,A更新字段的值为a,B更新字段的值为b。C线程并发读取这个相同的字段。

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

一种可能的不一致问题:

  • C读取到origin,此时没有命中缓存,直接读取数据库
  • A先更新数据库a
  • A删除缓存
  • C更新缓存为origin

此时数据库值为a,缓存值为origin。解释这种情况前,先分析如果A和B同时更新是否会产生不一致呢?因为A和B都是先更新了数据库后删除缓存,这样缓存的值实际上只依赖于读取的线程C来更新,所以更新操作的线程A和B的并发是不会导致数据库和缓存的不一致的。
现在分析上面的情况,首先对于数据的操作,读请求要快于写请求,因此在“C读取到origin”时出现滞后于“A先更新数据库a,A删除缓存”两个操作的情况在实际系统中发生的概率本身非常低,换句话说,“C更新缓存为origin”极大概率发生在“A删除缓存”之前。加之即使偶然的错误,数据也是原来的值,我们可以通过设置缓存的过期时间来减少这种数据不一致带来的影响。或者使用“延时删除策略”让A线程等待一下再删除一次缓存。
比起下面三种情况产生的问题,相对而言先更新数据库,再删除缓存的结果是最容易让人接受的。

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

A和B线程同时更新数据库,之后再更新缓存,A和B的执行先后顺序无法保证,两者操作速度基本一致,因此数据库和缓存最终写入的是a还是b根本无法预估,而且系统大概率产生不一致的问题。
因此,在没有任何分布式保证的前提下,绝对不可以使用“先更新数据库,再更新缓存”的操作顺序 。

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

删除缓存后,A和B线程更新数据库完全依赖到达数据库的先后顺序,而缓存的值依赖读线程C进行更新。这个操作顺序表面上看似与第一种情况差不多,但是问题出现在了线程C的操作时间点上。

  • A删除缓存
  • B删除缓存
  • C读取到origin
  • A先更新数据库a
  • B先更新数据库b
  • C更新缓存为origin

如上所示,A和B的操作顺序无法确定,但是C读取操作的执行速度要远远小于A和B的更新速度,那么三条线程同时操作时,大概率线程C会在A和B更新数据库前读到origin,此时缓存和数据库是不一致的。比起第一种情况,由于读写耗时的原因,会更大概率出现数据的不一致。

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

与“先更新数据库,再更新缓存”本质上是一样的,A和B线程并发时无法保证操作的先后顺序,数据和缓存无法保证一致性,而且大概率会产生不一致。
同样,在没有任何分布式保证的前提下,绝对不可以使用“先更新缓存,再更新数据库”的操作顺序 。


你可能感兴趣的:(修改数据时,先更新缓存还是数据库?)