缓存有那么多种，分别是干什么的？

本文做者：oschina_2020

只要是位正儿八经的程序员应该都知道“缓存”是什么，甚至我司的不少作运营的小姐姐如今和程序员小哥哥交流中都时不时冒出“缓存”这个词，让人压力山大。

固然，这里讨论的是指软件层面的缓存。你们都知道的一点是，缓存可让本来打开很慢的页面，变得能“秒开”。你平时访问的 APP 与网站几乎都有涉及到缓存的运用。

那么，缓存除了能加速数据的访问以外，还有什么做用呢？

另外，任何事物都有两面性，咱们如何才能将缓存的优势发挥得淋淋尽致，同时避免掉到它的弊端中呢？

本文接下来就给你们分享一下如何理解缓存，以及它的运用思路，但愿对你有所启发。

缓存能作什么？

正如前面所说，你们最广泛的理解就是当咱们遇到某个页面打开很慢的时候，会想到引入缓存，这样页面打开就快了。

其实快和慢都是相对的，从技术角度来讲，缓存之因此快是由于缓存是基于内存去创建的，而内存的读写速度比硬盘快 X 倍，因此用内存来代替硬盘做为读写的介质天然能大大提升访问数据的速度。

这个过程大体是这样的，经过在内存中存储被访问过的数据供后续访问时使用，以此来达到提速的效果。

其实除此以外，缓存还有另外 2 个重要的运用方式：预读取和延迟写。

预读取

预读取就是预先读取将要载入的数据，也能够称做“缓存预热”，它是在系统中先将硬盘中的一部分数据加载到内存中，而后再对外提供服务。

为何要这样作呢？由于有些系统一旦启动就要面临上千上万的请求进来（在一些 toC 的项目尤为如此），若是直接让这些请求打到数据库上，很是大的多是数据库压力暴增，直接被干趴，没法正常响应。

为了缓解这个问题，就须要经过“预读取”来解决。

可能你会问，哪怕用了缓存仍是扛不住呢？那就是作横向扩展+负载均衡的时候到了，这不是本文讨论的内容，有机会再专门分享吧。

若是说“预读取”是在“数据出口”加了一道前置的缓冲区的话，那么下面要说的“延迟写”就是在“数据入口”后面加了一道后置的缓冲区。

延迟写

你可能知道，数据库的写入速度是慢于读取速度的，由于写入的时候有一系列的保证数据准确性的机制。

因此，若是想提高写入速度的话，要么作分库分表，要么就是经过缓存来进行一道缓冲，再一次性批量写到磁盘，以此来提速。

题外话：因为分库分表对跨表操做以及多条件组合查询的反作用巨大，因此引入它的复杂度远大于引入缓存，咱们应当优先考虑引入缓存的方案。

那么，经过缓存机制来加速“写”的过程就能够称做“延迟写”，它是预先将须要写入到磁盘或者数据库的数据，暂时写入到内存，而后就返回成功，再定时将内存中的数据批量写入到磁盘。

可能你会想，写到内存就认为成功，万一中途出现意外、断电、停机等致使程序异常终止的状况，数据不就丢了吗？ 

是的。因此“延迟写”通常仅用于对数据完整性要求不是那么苛刻的场景，好比点赞数啊、参与用户数啊等等，能够大大缓解对数据库频繁修改所带来的压力。

其实在咱们熟知的分布式缓存 Redis 中，其默认运用的持久化机制——RDB，也是这样的思路。

在一个成熟的系统中，可以运用到缓存的地方其实并非一处。下面就来梳理一下咱们在哪些地方能够“加缓存”。

哪里能够加缓存？

在说哪里能够加缓存以前咱们先搞清楚一个事情，咱们要缓存什么？也就是符合什么特色的数据才须要加缓存？毕竟加缓存是一个额外的成本投入，得物有所值。

通常来讲你能够用这两个标准来判断：

• 热点数据：被高频访问，如几十次/秒以上
• 静态数据：不多变化，读远大于写，如几天变动一次

接下去就能够替它们找到合适的地方加缓存了。

缓存的本质是一个“防护性”的机制，而系统之间的数据流转是一个有序的过程，因此，选择在哪里加缓存就至关于选择在一条马路的哪一个位置设路障。在这个路障以后的道路都能受到保护，不被车流碾压。

那么在以终端用户为起点，系统所用的数据库为终点的这条道路上能够做为缓存设立点的位置大体有如下这些：

每一个设立点能够挡掉一些流量，最终造成一个漏斗状的拦截效果，以此保护最后面的系统以及最终的数据库。

下面简要描述一下每一个运用场景以及须要注意的点。

浏览器缓存

这是离用户最近的能够做为缓存的地方，并且借助的是用户的“资源”（缓存的数据在用户的终端设备上），性价比可谓最好，让用户帮你分担压力。

当你打开浏览器的开发者工具，看到 from cache 或者 from memory cache、from disk cache 的时候，就意味着这些数据已经被缓存在了用户的终端设备上了，没网的时候也能访问到一部份内容就是这个缘由。

这个过程是浏览器替咱们完成的，通常用于缓存图片、js 与 css 这些资源，咱们能够经过 Http 消息头中的 Cache-Control 来控制它，具体细节这里就不展开了。此外，js 里的全局变量、cookie 等运用也属于该范畴。

浏览器缓存是在于用户侧的缓存点，因此咱们对它的掌控力会比较差，在没有发起新请求的状况下，你没法主动去更新数据。

CDN 缓存

提供 CDN 服务的服务商，在全国甚至是全球部署着大量的服务器节点（能够叫作“边缘服务器”）。

那么将数据分发到这些遍及各地服务器上做为缓存，让用户访问就近的服务器上的缓存数据，就能够起到压力分摊和加速效果。这在 toC 类型的系统上运用，效果格外显著。

可是须要注意的是，因为节点众多，更新缓存数据比较缓慢，通常至少是分钟级别，因此通常仅适用于不常常变更的静态数据。

题外话：解决方式也是有的，就是在 url 后面带个自增数或者惟一标示，如 ?v=1001。由于不一样的 url 会被视做“新”的数据和文件，被从新 create 出来。

网关（代理）缓存

到这里作缓存就是在你本身的地盘了。不少时候咱们会在源站前面架一层网关（或者说反向代理、正向代理），为的是作一些安全机制或者做为统一分流策略的入口。

同时这里也是作缓存的一个好场所，毕竟网关是“业务无关性”的，它可以拦下来请求，对背后的源站也有很大的受益，减小了大量的 CPU 运算。 

经常使用的网关（代理）缓存有 Varnish、Squid 与 Ngnix。通常状况下，简单的缓存运用场景，用 Nginx 便可，由于大部分时候咱们会用它来作负载均衡，能少引入一个技术就少一份复杂度。若是是大量的小文件可使用 Varnish，而 Squid 则相对大而全，运用成本也更高一些。

进程内缓存

可能咱们大多数程序员第一次刻意使用缓存的场景就是这个时候。

一个请求能走到这里说明它是“业务相关”的，须要通过业务逻辑的运算。

也正由于如此，从这里开始对缓存的引入成本比前面 3 种大大增长，由于对缓存与数据库之间的“数据一致性”要求更高了。

进程外缓存

这个你们也熟悉，就是 Redis 与 Memcached 之类，甚至也能够本身单独写一个程序来专门存放缓存数据，供其它程序远程调用。

这里先多说几句关于 Redis 和 Memcached 该怎么选择的思路。 

对资源（cpu、内存等）利用率格外重视的话可使用 Memcached，但程序在使用的时候须要容忍可能发生的数据丢失，由于是纯内存的机制。若是没法容忍这点，而且对资源利用率也比较豪放的话可使用 Redis。并且 Redis 的数据库结构更多，Memcached 只有 key-value，更像是一个 NoSQL 存储。

数据库缓存

数据库自己是自带缓存模块的，不然也不会叫它内存杀手，基本上你给多少内存就能吃多少。数据库缓存是数据库的内部机制，通常都会给出设置缓存空间大小的配置来让你进行干预。

最后，其实磁盘自己也有缓存。因此你会发现，为了让数据可以平稳地写到物理磁盘中真的是一波三折，不知道何时能够有“快”到不须要程序来考虑缓存的磁盘出现来拯救咱们程序员呢。

缓存是银弹吗？

可能你会想缓存那么好，那么应该多多益善，只要慢就上缓存来解决？

一个事物看上去再好，也有它负面的一面，缓存也有一系列的反作用须要考虑。除了前面提到的“缓存更新”和“缓存与数据的一致性”问题，还有诸以下边的这些问题：

• 缓存雪崩。在大量的请求并发进入时，因为某些缘由未起到预期的缓冲效果，哪怕只是很短的一段时间，致使请求所有流转到数据库，形成数据库压力太重。解决它能够经过“加锁排队”或者“缓存时间增长随机值”。
• 缓存穿透。和“缓存雪崩”比较相似，区别是这会持续更长的时间，由于每次“cache miss”后依然没法从数据源加载数据到缓存，致使持续产生“cache miss”。解决它能够经过“布隆过滤器”或者“缓存空对象”。
• 缓存并发。一个缓存 Key 下的数据被同时 set，怎么保证业务的准确性？再加上数据库的话呢？进程内缓存、进程外缓存与数据库三者皆用的状况下呢？用一句话来归纳建议的方案是：使用“先 DB 再缓存”的方式，而且缓存操做用 delete 而不是 set。
• 缓存无底洞。虽然分布式缓存是能够无限横向扩展的，可是，集群下的节点真的是越多越好吗？固然不是，缓存也是符合“边际效应递减”规律的。
• 缓存淘汰。内存老是有限的，若是数据量很大，那么根据具体的场景定制合理的淘汰策略是必不可少的，如 LRU、LFU 与 FIFO 等等。

因此缓存不是银弹，对缓存的使用也须要先考虑各类问题。总结一下，本文先向你介绍了运用缓存的三种思路，而后梳理了在一个完整的系统中能够设立缓存的几个位置，而且分享了关于浏览器、CDN 与网关（代理）等缓存的一些使用经验，没有具体展开来说细节，只是但愿你对缓存有一个更加体系化的认识，但愿能让你看得更加全面。

做者介绍

张帆（Zachary），7 年电商行业经验，5 年开发团队管理经验，4 年互联网架构经验，目前任职某垂直电商技术总监。专一大型系统架构与分布式系统，坚持用心打磨每一篇原创。我的公众号：跨界架构师（ID：Zachary_ZF）。

原文连接地址：https://developer.baidu.com/topic/show/290593