缓存更新的模式架构

标题缓存更新的设计 1错误案例场景：更新缓存数据时，先删除cache，然后再更新db

1 a，b线程，a线程删除cache，更新db前，b线程先读数cache，发现chche没有数据，从db读取数，并加载到cache中，执行后a线程更新db。
2 这个时候db的数据和cache的数据是不一样的，因为cache的数据还是旧数据（脏数据）。

解决这类问题的设计一 Cache Aside Pattern 最常用的设计了。其具体逻辑如下：

失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。命中：应用程序从cache中取数据，取到后返回。更新：先把数据存到数据库中，成功后，再让缓存失效。

文章图片

1 a，b线程，a线程更新db，更新后让cache失效(删除cache)。后面的线程读数据，发现没有数据，从数据库读取，并放到缓存中。解决了上面脏数据的问题。因为最后是cache失效(删除缓存)的操作，所以，后面的请求数据都会是最新的数据。

1为什么不是写完数据库后更新缓存《Why does Facebook use delete to remove the key-value pair in Memcached instead of updating the Memcached during write request to the backend?》。主要是怕两个并发的写操作导致脏数据
场景：

1 a，b线程，线程顺序：a更新db，b更新db，b线程更新cache，a线程更新cache。
2 db存储是b线程数据，cache存储是a线程的数据，脏数据了。

2这个设计就不会有并发问题了？
【缓存更新的模式】场景：

1 a，b线程，线程顺序：a读取cache，发现没有数据,读db数据，cpu时间片给b线程。b线程更新db,并让cache失效。cpu时间片给a线程，a线程因为已经读取到数据（b更新前的数据），这个时候a线程把数据同步到cache中，造成脏数据。

实际上脏数据出现的概率可能非常低

因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。
数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作更新缓存，所有的这些条件都具备的概率基本并不大。

Facebook使用了这个降低概率的玩法，最好还是为缓存设置上过期时间。
二 Read/Write Through Pattern

文章图片

思路
在一中，我们的应用代码需要维护两个数据存储，一个是缓存（Cache），一个是数据库（db）。所以，应用程序比较啰嗦。而Read/Write Through套路是把更新数据库（Repository）的操作由缓存自己代理了。
Read Through
套路：在查询操作中更新缓存
查询，当缓存失效的时候（过期或LRU换出），Read Through则用缓存服务自己来加载数据到cache中。
Write Through
套路：更新数据时发生。
数据更新的时候

没有命中缓存，直接更新数据库，然后返回。
命中了缓存，则更新缓存，然后再由Cache自己更新数据库（这是一个同步操作）

三Write Behind Caching Pattern

文章图片

Write Behind 又叫 Write Back。就是Linux文件系统的Page Cache的算法。

套路：
1更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。好处就是让数据的I/O操作飞快无比（因为直接操作内存嘛），因为异步，write backg还可以合并对同一个数据的多次操作，所以性能的提高是相当可观的。

带来的问题：
1 数据不是强一致性的，而且可能会丢失（我们知道Unix/Linux非正常关机会导致数据丢失，就是因为这个事）。
2 Write Back实现逻辑比较复杂，因为他需要track有哪数据是被更新了的，需要刷到持久层上。操作系统的write back会在仅当这个cache需要失效的时候，才会被真正持久起来，比如，内存不够了，或是进程退出了等情况，这又叫lazy write。