也许你会觉得缓存读写很简单:
针对不同的业务场景,实际选用的缓存的读写策略也不同。为方便讨论,这里假定更新数据库、缓存都成功。
最常用的模式:
注意,是先更新DB,成功后,让缓存失效。
一个查询操作,一个更新操作的并发 首先,没有了删除cache数据的操作,而是先更新数据库中的数据,此时,缓存依然有效,所以,并发的查询操作拿的是没有更新的数据,但是,更新操作马上让缓存的失效了,后续的查询操作再把数据从数据库中拉出来。而不会像文章开头的那个逻辑产生的问题,后续的查询操作一直都在取老的数据。
这是标准的design pattern,包括Facebook的论文《Scaling Memcache at Facebook》也使用了这个策略。为什么不是写DB后更新缓存?可以看一下Quora上的这个问答《Why does Facebook use delete to remove the key-value pair in Memcached instead of updating the Memcached during write request to the backend?》,主要是怕两个并发的写操作导致脏数据。
那Cache Aside有并发问题吗?
有。比如,一个是读操作
,但是没有命中缓存,然后就到数据库中取数据,此时来了一个写操作
,写完数据库后,让缓存失效,然后,之前的那个读操作再把老的数据放进去,所以,会造成脏数据。
这个情形理论上会出现,不过,实际上出现的概率可能非常低,因为需要发生在读缓存时缓存失效,而且并发着有一个写操作。 而实际上数据库的写操作会比读操作慢得多,而且还要锁表,而读操作必需在写操作前进入数据库操作,而又要晚于写操作更新缓存,所有的这些条件都具备的概率基本并不大
这也就是Quora上的那个答案里说的,要么通过2PC或是Paxos协议保证一致性,要么就是拼命的降低并发时脏数据的概率,而Facebook使用了这个降低概率的玩法,因为2PC太慢,而Paxos太复杂。当然,最好还是为缓存设置上过期时间。
上面的Cache Aside,应用代码需要维护两个数据存储,一个是缓存,一个是数据库,应用程序比较啰嗦。
而Read/Write Through
是把更新数据库的操作由缓存自己代理,所以,对于应用层来说,就简单很多。
可理解为,应用认为后端就是一个单一的存储,而存储自己维护自己的Cache。
Read Through 就是在查询操作中更新缓存,也就是说,当缓存失效的时候(过期或LRU换出)
调用方负责
把数据加载入缓存缓存服务
自己来加载,从而对应用方是透明的和Read Through相仿,不过是在更新数据时发生 当有数据更新时
下图中的Memory可以理解为就是我们例子里的数据库
又叫 Write Back。在更新数据时,只更新缓存,不更新DB,而我们的缓存会异步批量更新DB
数据不是强一致性的,而且可能会丢失(我们知道Unix/Linux非正常关机会导致数据丢失,就是因为这个事)。
另外,Write Back实现逻辑比较复杂,因为他需要track哪些数据是被更新的,需要刷到持久层。 os的write back会在仅当这个cache需要失效时,才会被真正持久化,比如,内存不够了,或是进程退出了等情况,这又叫lazy write。
比如在向磁盘中写数据时采用的也是这种策略。无论是:
大多采用了这种策略。因为这个策略在性能优势明显,直接写内存,避免了直接写磁盘造成的随机写。
参考