用这四种套路更新缓存，你会少走不少弯路！

点关注，不迷路；持续更新Java架构相关技术及资讯热文！！！

看到好些人在写更新缓存数据代码时，先删除缓存，而后再更新数据库，然后续的操做会把数据再装载的缓存中。然而，这个是逻辑是错误的。试想，两个并发操做，一个是更新操做，另外一个是查询操做，更新操做删除缓存后，查询操做没有命中缓存，先把老数据读出来后放到缓存中，而后更新操做更新了数据库。因而，在缓存中的数据仍是老的数据，致使缓存中的数据是脏的，并且还一直这样脏下去了。

我不知道为何这么多人用的都是这个逻辑，当我在微博上发了这个帖之后，我发现好些人给了好多很是复杂和诡异的方案，因此，我想写这篇文章说一下几个缓存更新的Design Pattern（让咱们多一些套路吧）。

这里，咱们先不讨论更新缓存和更新数据这两个事是一个事务的事，或是会有失败的可能，咱们先假设更新数据库和更新缓存均可以成功的状况（咱们先把成功的代码逻辑先写对）。

更新缓存的的Design Pattern有四种：Cache aside，Read through，Write through，Write behind caching，咱们下面一一来看一下这四种Pattern。

Cache Aside Pattern

---

这是最经常使用的pattern了。其具体逻辑以下：

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

注意，咱们的更新是先更新数据库，成功后，让缓存失效。那么，这种方式是否能够没有文章前面提到过的那个问题呢？咱们能够脑补一下。

一个是查询操做，一个是更新操做的并发，首先，没有了删除cache数据的操做了，而是先更新了数据库中的数据，此时，缓存依然有效，因此，并发的查询操做拿的是没有更新的数据，可是，更新操做立刻让缓存的失效了，后续的查询操做再把数据从数据库中拉出来。而不会像文章开头的那个逻辑产生的问题，后续的查询操做一直都在取老的数据。

Read/Write Through Pattern

---

咱们能够看到，在上面的Cache Aside套路中，咱们的应用代码须要维护两个数据存储，一个是缓存（Cache），一个是数据库（Repository）。因此，应用程序比较啰嗦。而Read/Write Through套路是把更新数据库（Repository）的操做由缓存本身代理了，因此，对于应用层来讲，就简单不少了。能够理解为，应用认为后端就是一个单一的存储，而存储本身维护本身的Cache。

Read Through

Read Through 套路就是在查询操做中更新缓存，也就是说，当缓存失效的时候（过时或LRU换出），Cache Aside是由调用方负责把数据加载入缓存，而Read Through则用缓存服务本身来加载，从而对应用方是透明的。

Write Through

Write Through 套路和Read Through相仿，不过是在更新数据时发生。当有数据更新的时候，若是没有命中缓存，直接更新数据库，而后返回。若是命中了缓存，则更新缓存，而后再由Cache本身更新数据库（这是一个同步操做）

下图自来Wikipedia的Cache词条。其中的Memory你能够理解为就是咱们例子里的数据库。

Write Behind Caching Pattern

---

Write Behind 又叫 Write Back。一些了解Linux操做系统内核的同窗对write back应该很是熟悉，这不就是Linux文件系统的Page Cache的算法吗？是的，你看基础这玩意全都是相通的。因此，基础很重要，我已经不是一次说过基础很重要这事了。

Write Back套路，一句说就是，在更新数据的时候，只更新缓存，不更新数据库，而咱们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的I/O操做飞快无比（由于直接操做内存嘛 ），由于异步，write backg还能够合并对同一个数据的屡次操做，因此性能的提升是至关可观的。

可是，其带来的问题是，数据不是强一致性的，并且可能会丢失（咱们知道Unix/Linux非正常关机会致使数据丢失，就是由于这个事）。在软件设计上，咱们基本上不可能作出一个没有缺陷的设计，就像算法设计中的时间换空间，空间换时间一个道理，有时候，强一致性和高性能，高可用和高性性是有冲突的。软件设计历来都是取舍Trade-Off。

另外，Write Back实现逻辑比较复杂，由于他须要track有哪数据是被更新了的，须要刷到持久层上。操做系统的write back会在仅当这个cache须要失效的时候，才会被真正持久起来，好比，内存不够了，或是进程退出了等状况，这又叫lazy write。

在wikipedia上有一张write back的流程图，基本逻辑以下：

再多唠叨一些

---

• 上面讲的这些Design Pattern，其实并非软件架构里的mysql数据库和memcache/redis的更新策略，这些东西都是计算机体系结构里的设计，好比CPU的缓存，硬盘文件系统中的缓存，硬盘上的缓存，数据库中的缓存。基本上来讲，这些缓存更新的设计模式都是很是老古董的，并且历经长时间考验的策略，因此这也就是，工程学上所谓的Best Practice，听从就行了。
• 有时候，咱们以为能作宏观的系统架构的人必定是颇有经验的，其实，宏观系统架构中的不少设计都来源于这些微观的东西。好比，云计算中的不少虚拟化技术的原理，和传统的虚拟内存不是很像么？Unix下的那些I/O模型，也放大到了架构里的同步异步的模型，还有Unix发明的管道不就是数据流式计算架构吗？TCP的好些设计也用在不一样系统间的通信中，仔细看看这些微观层面，你会发现有不少设计都很是精妙……因此，请容许我在这里放句观点鲜明的话——若是你要作好架构，首先你得把计算机体系结构以及不少老古董的基础技术吃透了。
• 在软件开发或设计中，我很是建议在以前先去参考一下已有的设计和思路，看看相应的guideline，best practice或design pattern，吃透了已有的这些东西，再决定是否要从新发明轮子。千万不要似是而非地，想固然的作软件设计。
• 上面，咱们没有考虑缓存（Cache）和持久层（Repository）的总体事务的问题。好比，更新Cache成功，更新数据库失败了怎么吗？或是反过来。关于这个事，若是你须要强一致性，你须要使用“两阶段提交协议”——prepare, commit/rollback，好比Java 7 的XAResource，还有MySQL 5.7的 XA Transaction，有些cache也支持XA，好比EhCache。固然，XA这样的强一致性的玩法会致使性能降低。

写在最后

最后，欢迎作Java的工程师朋友们加入Java高级架构进阶Qqun：963944895

群内有技术大咖指点难题，还提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）

比你优秀的对手在学习，你的仇人在磨刀，你的闺蜜在减肥，隔壁老王在练腰， 咱们必须不断学习，不然咱们将被学习者超越！

趁年轻，使劲拼，给将来的本身一个交代！