多级缓存的设计与实现

在高并发量的后端业务中，多级缓存是一个非常常见的设计。
事实上，多级缓存策略在计算机硬件也是普遍存在的。

为什么会有多级缓存？
通常缓存都是比原数据要小的，设立缓存的目的很简单：某些数据经常用到，我们不想每次都去最深的地方（这里一般是指数据库）去找，所以我们就在更方便取到数据的地方把这些数据保存起来。

那么，为什么要用多级缓存呢？
对于所有的数据来说，并不是每一份数据使用的频率都一样。对于使用频率非常高的数据，我们称为热点数据。
例如，某个大V发了一条微博，告诉大家，他结婚了，那么这一条微博就是一个热点数据，热到不行的数据，我们的服务器平均下来每一毫秒要访问这条数据一万次（不夸张。。）
我前一篇文章也说了，分布式缓存 100us 的读取已经是正常成绩了，但是这个成绩完全不够支撑啊。我们必须有更快的缓存来保存这条数据，以减轻分布式缓存的压力。

对于我们业务开发者来说，显式使用 CPU 的 L1，L2，L3 显然是不现实的。那么，我们只能指望着静静插在主板上的内存条了。

现在的内存性能已经非常牛逼了，10000 mb/s 的读取速度已经非常普遍，至于延迟我还没有太多的概念。
内存那么牛逼，我们就要尽量利用好它，所以内存一般是我们多级缓存的最顶一层。

那么在这篇文章中，我就尝试着用 Java 来实现一下多级缓存。

各个语言都大同小异的，我这一年里基本都是写 Java 了，所以就直接用 Java 来写了。

Preconditions 预设计

对于一个合格的后端服务来说，多级缓存的设计至少要包括以下几个功能：

• 支持过期清理
• 支持容量限制及逐出策略
• 支持回源及回写机制（后面我会说下回源和回写这两个概念）

Back-to-Source 回源

一般我们说回源一般是指 CDN 层面上的回源，意思是在这个 CDN 节点上没找到相关的资源，就去到「源站」上去获取这个资源。
回到我们的缓存设计中，在缓存层面上，回源也是类似的意思：在这一层的缓存中没找到这个数据，就到下一个「数据源」去获取资源。

Write-Back 回写

回写依托在回源的基础上。
当某一层的缓存没找到这个资源时，到下一层去找，发现找到了，然后这一层的缓存就把这个数据缓存起来。
到下一次再取这个数据的时候，就能马上取到了。

Code 搞起

简单写了下，轻喷 https://github.com/XhinLiang/multi-level-cache。