Cache Aside Pattern

前言

缓存是互联网高并发系统里常用的组件。由于多增加了一层,如果没有正确的使用效果可能适得其反,诸如“缓存是删除还是更新?”,“先操作数据库还是先操作缓存?”都是些老生常谈的话题,今天要介绍的是一个由 Facebook 提出的广受认可的缓存方案。

缓存是删除还是更新

  1. 缓存更新策略,如果缓存里面存的 value 是经过序列化的对象,需要经过反序列化设置新值等步骤更新成本高,此时删除缓存成本低 ,只需直接淘汰缓存,等待下次数据汇源在设置新的缓存。
  2. 缓存更新策略,高并发场景有脏数据问题。
同时有请求A和请求B进行更新操作,那么会出现:

线程A更新了数据库;

线程B更新了数据库;

线程B更新了缓存;

线程A更新了缓存;

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

总结:更新缓存会带来种种问题,直接删除缓存比较简单粗暴,稳妥。

先更新数据库还是先操作缓存

  1. 先操作(删除)缓存的情况,还是回到上面的高并发场景:
1. 请求A进行写操作,删除缓存;

2. 请求B查询发现缓存不存在;

3. 请求B去数据库查询得到旧值;

4. 请求B将旧值写入缓存;

5. 请求A将新值写入数据库;

此时如果缓存没有设置超时时间,则缓存里面的数据会一直都是旧的数据。

  1. 先更新数据库的情况,这就是 Cache Aside Pattern 里的原则之一,下面分析下 case :
1. 缓存刚好失效,请求A查询数据库,得一个旧值;

2. 请求B将新值写入数据库;

3. 请求B删除缓存;

4. 请求A将查到的旧值写入缓存;

这时缓存里面确实是脏数据了,然而这种情况很小概率发生。因为只有在第 2 步写数据库的请求比第 1 步查询数据的请求还快还会发生这种情况,由于数据库的特性,这种情况很少会存在,所以这种方案相对来说是比较可靠的。

Cache Aside Pattern

除了上面举的例子,Cache Aside Pattern 还有几个原则。

失效:应用程序先从cache取数据,没有得到,则从数据库中取数据,成功后,放到缓存中;

命中:应用程序从cache中取数据,取到后返回;

更新:先把数据存到数据库中,成功后,再让缓存失效;

前面两点几乎都是共识了也没必要展开讲了,重点就是第 3 点。

参考资料:https://mp.weixin.qq.com/s/-fk-cEIo3iDCUSwT_l8d2w

你可能感兴趣的:(Cache Aside Pattern)