分布式系统关注点——360°全方位解读「缓存」

若是这是第二次看到个人文章，欢迎 文末扫码订阅我我的的公众号（跨界架构师）哟~
本文长度为 3578字，建议阅读 10分钟。
坚持原创，每一篇都是用心之做～

此前的「伸缩性」章节结束了，此文是「高性能」章节的第一篇。

只要是位正儿八经的程序员天然知道「缓存」是什么，甚至我司的不少作运营的小姐姐如今和程序员小哥哥的交流中都时不时冒出「缓存」字眼，让人压力山大。（本文讨论的「缓存」皆指的是软件层面运用的缓存）

你们都知道的一点是，缓存可让本来打开很慢的页面，变得能“秒开”。你平时访问的APP、网站几乎都有涉及到缓存的运用。

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

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

Z哥今天想分享给你的就是我对缓存的理解和运用的思路，但愿对你有所启发。

「缓存」能作什么？

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

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

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

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

预读取

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

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

为了缓解这个问题，须要经过「预读取」来解决。

可能你会问，哪怕用了缓存仍是扛不住呢？那就是作横向扩展+负载均衡的时候到了。（能够点击文末连接阅读以前的《弹性架构》系列）

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

延迟写

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

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

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

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

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

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

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

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

哪里能够加「缓存」？

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

通常来讲你能够用这两个标准来判断：热点（被高频访问，如几十次/秒以上）数据、静态（不多变化，读远大于写，如几天变动一次）数据。

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

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

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

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

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

浏览器缓存

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

当你打开浏览器的开发者工具，看到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存储。

数据库缓存

数据库自己自带缓存模块的，不然也不会叫它内存杀手，基本上你给多少内存就能吃多少。

数据库缓存是数据库的内部机制，咱们这里就不深刻下去了。通常都会给出设置缓存空间大小的配置来让你进行干预。

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

「缓存」是Silver bullet吗？

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

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

1. 缓存雪崩
2. 缓存穿透
3. 缓存并发
4. 缓存无底洞
5. 缓存淘汰
6. ...

等等问题，这些Z哥会在接下去的文章中和你一块儿深刻剖析。

想第一时间了解这些的能够「关注」Z哥一波～

总结

好了，咱们总结一下。

此次呢，Z哥先向你介绍了运用缓存的三种思路。

而后梳理了在一个完整的系统中能够设立缓存的几个位置，而且分享了关于浏览器缓存、CDN缓存、网关（代理）缓存的一些使用经验。

但愿对你有所启发。

后续的文章我将着重深刻「进程内缓存」和「进程外缓存」的最佳实践，等我再次出现。

---

相关文章：

• 分布式系统关注点——仅需这一篇，吃透「负载均衡」妥妥的
• 分布式系统关注点——如何去实施「负载均衡」？
• 分布式系统关注点——作了「负载均衡」就能够随便加机器了吗？
• 分布式系统关注点——「无状态」详解
• 分布式系统关注点——「高内聚低耦合」详解
• 分布式系统关注点——弹性架构

---

做者：Zachary

出处：https://www.cnblogs.com/Zacha...

---

若是你喜欢这篇文章，能够点一下文末的「赞」。

这样能够给我一点反馈。: )

谢谢你的举手之劳。

▶关于做者：张帆（Zachary， 我的微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎 扫描下方的二维码~。
按期发表原创内容： 架构设计丨分布式系统丨产品丨运营丨一些思考。

若是你是初级程序员，想提高但不知道如何下手。又或者作程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注个人公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思惟导图。

若是你是运营，面对不断变化的市场一筹莫展。又或者想了解主流的运营策略，以丰富本身的“仓库”。欢迎关注个人公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思惟导图。