共计 6773 个字符，预计需要花费 17 分钟才能阅读完成。
前言
在互联网高速倒退的明天，缓存技术被宽泛地利用。无论业内还是业外，只有是提到性能问题，大家都会脱口而出“用缓存解决”。
这种说法带有片面性，甚至是只知其一; 不知其二，然而作为专业人士的咱们，须要对缓存有更深、更广的理解。
缓存技术存在于利用场景的方方面面。从浏览器申请，到反向代理服务器，从过程内缓存到分布式缓存。其中缓存策略，算法也是层出不穷，明天就带大家走进缓存。
注释
缓存对于每个开发者来说是相当相熟了，为了进步程序的性能咱们会去加缓存，然而在什么中央加缓存，如何加缓存呢？
假如一个网站，须要进步性能，缓存能够放在浏览器，能够放在反向代理服务器，还能够放在应用程序过程内，同时能够放在分布式缓存零碎中。
从用户申请数据到数据返回，数据通过了浏览器，CDN，代理服务器，应用服务器，以及数据库各个环节。每个环节都能够使用缓存技术。
从浏览器 / 客户端开始申请数据，通过 HTTP 配合 CDN 获取数据的变更状况，达到代理服务器（Nginx）能够通过反向代理获取动态资源。
再往下来到应用服务器能够通过过程内（堆内）缓存，分布式缓存等递进的形式获取数据。如果以上所有缓存都没有命中数据，才会回源到数据库。
缓存的申请程序是：用户申请 → HTTP 缓存 → CDN 缓存 → 代理服务器缓存 → 过程内缓存 → 分布式缓存 → 数据库。
看来在技术的架构每个环节都能够退出缓存，看看每个环节是如何利用缓存技术的。
- HTTP 缓存
当用户通过浏览器申请服务器的时候，会发动 HTTP 申请，如果对每次 HTTP 申请进行缓存，那么能够缩小应用服务器的压力。
当第一次申请的时候，浏览器本地缓存库没有缓存数据，会从服务器取数据，并且放到浏览器的缓存库中，下次再进行申请的时候会依据缓存的策略来读取本地或者服务的信息。
个别信息的传递通过 HTTP 申请头 Header 来传递。目前比拟常见的缓存形式有两种，别离是：
强制缓存
比照缓存
1.1. 强制缓存
当浏览器本地缓存库保留了缓存信息，在缓存数据未生效的状况下，能够间接应用缓存数据。否则就须要从新获取数据。
这种缓存机制看上去比拟间接，那么如何判断缓存数据是否生效呢？这里须要关注 HTTP Header 中的两个字段 Expires 和 Cache-Control。
Expires 为服务端返回的过期工夫，客户端第一次申请服务器，服务器会返回资源的过期工夫。如果客户端再次申请服务器，会把申请工夫与过期工夫做比拟。
如果申请工夫小于过期工夫，那么阐明缓存没有过期，则能够间接应用本地缓存库的信息。
反之，阐明数据曾经过期，必须从服务器从新获取信息，获取结束又会更新最新的过期工夫。
这种形式在 HTTP 1.0 用的比拟多，到了 HTTP 1.1 会应用 Cache-Control 代替。
Cache-Control 中有个 max-age 属性，单位是秒，用来示意缓存内容在客户端的过期工夫。
例如：max-age 是 60 秒，以后缓存没有数据，客户端第一次申请完后，将数据放入本地缓存。
那么在 60 秒以内客户端再发送申请，都不会申请应用服务器，而是从本地缓存中间接返回数据。如果两次申请相隔工夫超过了 60 秒，那么就须要通过服务器获取数据。
1.2. 比照缓存
须要比照前后两次的缓存标记来判断是否应用缓存。浏览器第一次申请时，服务器会将缓存标识与数据一起返回，浏览器将二者备份至本地缓存库中。浏览器再次申请时，将备份的缓存标识发送给服务器。
服务器依据缓存标识进行判断，如果判断数据没有发生变化，把判断胜利的 304 状态码发给浏览器。
这时浏览器就能够应用缓存的数据来。服务器返回的就只是 Header，不蕴含 Body。
上面介绍两种标识规定：
1.2.1. Last-Modified/If-Modified-Since 规定
在客户端第一次申请的时候，服务器会返回资源最初的批改工夫，记作 Last-Modified。客户端将这个字段连同资源缓存起来。
Last-Modified 被保留当前，在下次申请时会以 Last-Modified-Since 字段被发送。
当客户端再次申请服务器时，会把 Last-Modified 连同申请的资源一起发给服务器，这时 Last-Modified 会被命名为 If-Modified-Since，寄存的内容都是一样的。
服务器收到申请，会把 If-Modified-Since 字段与服务器上保留的 Last-Modified 字段作比拟：
若服务器上的 Last-Modified 最初批改工夫大于申请的 If-Modified-Since，阐明资源被改变过，就会把资源（包含 Header+Body）从新返回给浏览器，同时返回状态码 200。
若资源的最初批改工夫小于或等于 If-Modified-Since，阐明资源没有改变过，只会返回 Header，并且返回状态码 304。浏览器承受到这个音讯就能够应用本地缓存库的数据。
留神：Last-Modified 和 If-Modified-Since 指的是同一个值，只是在客户端和服务器端的叫法不同。
1.2.2. ETag / If-None-Match 规定
客户端第一次申请的时候，服务器会给每个资源生成一个 ETag 标记。这个 ETag 是依据每个资源生成的惟一 Hash 串，资源如何发生变化 ETag 随之更改，之后将这个 ETag 返回给客户端，客户端把申请的资源和 ETag 都缓存到本地。
ETag 被保留当前，在下次申请时会当作 If-None-Match 字段被发送进来。
在浏览器第二次申请服务器雷同资源时，会把资源对应的 ETag 一并发送给服务器。在申请时 ETag 转化成 If-None-Match，但其内容不变。
服务器收到申请后，会把 If-None-Match 与服务器上资源的 ETag 进行比拟：
如果不统一，阐明资源被改变过，则返回资源（Header+Body），返回状态码 200。
如果统一，阐明资源没有被改过，则返回 Header，返回状态码 304。浏览器承受到这个音讯就能够应用本地缓存库的数据。
留神：ETag 和 If-None-Match 指的是同一个值，只是在客户端和服务器端的叫法不同。
- CDN 缓存
HTTP 缓存次要是对静态数据进行缓存，把从服务器拿到的数据缓存到客户端 / 浏览器。
如果在客户端和服务器之间再加上一层 CDN，能够让 CDN 为应用服务器提供缓存，如果在 CDN 上缓存，就不必再申请应用服务器了。并且 HTTP 缓存提到的两种策略同样能够在 CDN 服务器执行。
CDN 的全称是 Content Delivery Network，即内容散发网络。
让咱们来看看它是如何工作的吧：
客户端发送 URL 给 DNS 服务器。
DNS 通过域名解析，把申请指向 CDN 网络中的 DNS 负载均衡器。
DNS 负载均衡器将最近 CDN 节点的 IP 通知 DNS，DNS 告之客户端最新 CDN 节点的 IP。
客户端申请最近的 CDN 节点。
CDN 节点从应用服务器获取资源返回给客户端，同时将动态信息缓存。留神：客户端下次互动的对象就是 CDN 缓存了，CDN 能够和应用服务器同步缓存信息。
CDN 承受客户端的申请，它就是离客户端最近的服务器，它前面会链接多台服务器，起到了缓存和负载平衡的作用。
- 负载平衡缓存
说完客户端（HTTP）缓存和 CDN 缓存，咱们离应用服务越来越近了，在达到应用服务之前，申请还要通过负载均衡器。
虽说它的次要工作是对应用服务器进行负载平衡，然而它也能够作缓存。能够把一些批改频率不高的数据缓存在这里，例如：用户信息，配置信息。通过服务定期刷新这个缓存就行了。
以 Nginx 为例，咱们看看它是如何工作的：
用户申请在达到应用服务器之前，会先拜访 Nginx 负载均衡器，如果发现有缓存信息，间接返回给用户。
如果没有发现缓存信息，Nginx 回源到应用服务器获取信息。
另外，有一个缓存更新服务，定期把应用服务器中绝对稳固的信息更新到 Nginx 本地缓存中。
- 过程内缓存
通过了客户端，CDN，负载均衡器，咱们终于来到了应用服务器。应用服务器上部署着一个个利用，这些利用以过程的形式运行着，那么在过程中的缓存是怎么的呢？
过程内缓存又叫托管堆缓存，以 Java 为例，这部分缓存放在 JVM 的托管堆下面，同时会受到托管堆回收算法的影响。
因为其运行在内存中，对数据的响应速度很快，通常咱们会把热点数据放在这里。
在过程内缓存没有命中的时候，咱们会去搜寻过程外的缓存或者分布式缓存。这种缓存的益处是没有序列化和反序列化，是最快的缓存。毛病是缓存的空间不能太大，对垃圾回收器的性能有影响。
目前比拟风行的实现有 Ehcache、GuavaCache、Caffeine。这些架构能够很不便的把一些热点数据放到过程内的缓存中。
这里咱们须要关注几个缓存的回收策略，具体的实现架构的回收策略会有所不同，但大抵的思路都是统一的：
FIFO（First In First Out）：先进先出算法，最先放入缓存的数据最先被移除。
LRU（Least Recently Used）：最近起码应用算法，把最久没有应用过的数据移除缓存。
LFU（Least Frequently Used）：最不罕用算法，在一段时间内应用频率最小的数据被移除缓存。
在分布式架构的明天，多利用中如果采纳过程内缓存会存在数据一致性的问题。
这里举荐两个计划：
音讯队列批改计划
Timer 批改计划
4.1. 音讯队列批改计划
利用在批改完本身缓存数据和数据库数据之后，给音讯队列发送数据变动告诉，其余利用订阅了音讯告诉，在收到告诉的时候批改缓存数据。
4.2. Timer 批改计划
为了防止耦合，升高复杂性，对“实时一致性”不敏感的状况下。每个利用都会启动一个 Timer，定时从数据库拉取最新的数据，更新缓存。
不过在有的利用更新数据库后，其余节点通过 Timer 获取数据之间，会读到脏数据。这里须要管制好 Timer 的频率，以及利用与对实时性要求不高的场景。
过程内缓存有哪些应用场景呢？
场景一：只读数据，能够思考在过程启动时加载到内存。当然，把数据加载到相似 Redis 这样的过程外缓存服务也能解决这类问题。
场景二：高并发，能够思考应用过程内缓存，例如：秒杀。
- 分布式缓存
说完过程内缓存，天然就适度到过程外缓存了。与过程内缓存不同，过程外缓存在利用运行的过程之外，它领有更大的缓存容量，并且能够部署到不同的物理节点，通常会用分布式缓存的形式实现。
分布式缓存是与利用拆散的缓存服务，最大的特点是，本身是一个独立的利用 / 服务，与本地利用隔离，多个利用可间接共享一个或者多个缓存利用 / 服务。
既然是分布式缓存，缓存的数据会散布到不同的缓存节点上，每个缓存节点缓存的数据大小通常也是有限度的。
数据被缓存到不同的节点，为了能不便的拜访这些节点，须要引入缓存代理，相似 Twemproxy。他会帮忙申请找到对应的缓存节点。
同时如果缓存节点减少了，这个代理也会只能辨认并且把新的缓存数据分片到新的节点，做横向的扩大。
为了进步缓存的可用性，会在原有的缓存节点上退出 Master/Slave 的设计。当缓存数据写入 Master 节点的时候，会同时同步一份到 Slave 节点。
一旦 Master 节点生效，能够通过代理间接切换到 Slave 节点，这时 Slave 节点就变成了 Master 节点，保障缓存的失常工作。
每个缓存节点还会提供缓存过期的机制，并且会把缓存内容定期以快照的形式保留到文件上，不便缓存解体之后启动预热加载。
5.1. 高性能
当缓存做成分布式的时候，数据会依据肯定的法则调配到每个缓存利用 / 服务上。
如果咱们把这些缓存利用 / 服务叫做缓存节点，每个节点个别都能够缓存肯定容量的数据，例如：Redis 一个节点能够缓存 2G 的数据。
如果须要缓存的数据量比拟大就须要扩大多个缓存节点来实现，这么多的缓存节点，客户端的申请不晓得拜访哪个节点怎么办？缓存的数据又如何放到这些节点上？
缓存代理服务曾经帮咱们解决这些问题了，例如：Twemproxy 岂但能够帮忙缓存路由，同时能够治理缓存节点。
这里有介绍三种缓存数据分片的算法，有了这些算法缓存代理就能够不便的找到分片的数据了。
5.1.1. 哈希算法
Hash 表是最常见的数据结构，实现形式是，对数据记录的要害值进行 Hash，而后再对须要分片的缓存节点个数进行取模失去的余数进行数据调配。
例如：有三条记录数据别离是 R1，R2，R3。他们的 ID 别离是 01，02，03，假如对这三个记录的 ID 作为要害值进行 Hash 算法之后的后果仍旧是 01，02，03。
咱们想把这三条数据放到三个缓存节点中，能够把这个后果别离对 3 这个数字取模失去余数，这个余数就是这三条记录别离搁置的缓存节点。
Hash 算法是某种程度上的均匀搁置，策略比较简单，如果要减少缓存节点，对曾经存在的数据会有较大的变动。
5.1.2. 一致性哈希算法
一致性 Hash 是将数据依照特征值映射到一个首尾相接的 Hash 环上，同时也将缓存节点映射到这个环上。
如果要缓存数据，通过数据的要害值（Key）在环上找到本人寄存的地位。这些数据依照本身的 ID 取 Hash 之后失去的值依照程序在环上排列。
如果这个时候要插入一条新的数据其 ID 是 115，那么就应该插入到如下图的地位。
同理如果要减少一个缓存节点 N4 150，也能够放到如下图的地位。
这种算法对于减少缓存数据，和缓存节点的开销绝对比拟小。
5.1.3. Range Based 算法
这种形式是依照要害值（例如 ID）将数据划分成不同的区间，每个缓存节点负责一个或者多个区间。跟一致性哈希有点像。
例如：存在三个缓存节点别离是 N1，N2，N3。他们用来存放数据的区间别离是，N1(0, 100]，N2(100, 200]，N3(300, 400]。
那么数据依据本人 ID 作为关键字做 Hash 当前的后果就会别离对应放到这几个区域外面了。
5.2. 可用性
依据事物的两面性，在分布式缓存带来高性能的同时，咱们也须要器重它的可用性。那么哪些潜在的危险是咱们须要防备的呢？
5.2.1. 缓存雪崩
当缓存生效，缓存过期被革除，缓存更新的时候。申请是无奈命中缓存的，这个时候申请会间接回源到数据库。
如果上述情况频繁产生或者同时产生的时候，就会造成大面积的申请间接到数据库，造成数据库拜访瓶颈。咱们称这种状况为缓存雪崩。
从如下两方面来思考解决方案：
缓存方面：
防止缓存同时生效，不同的 key 设置不同的超时工夫。
减少互斥锁，对缓存的更新操作进行加锁爱护，保障只有一个线程进行缓存更新。缓存一旦生效能够通过缓存快照的形式迅速重建缓存。对缓存节点减少主备机制，当主缓存生效当前切换到备用缓存持续工作。
设计方面，这里给出了几点倡议供大家参考：
熔断机制：某个缓存节点不能工作的时候，须要告诉缓存代理不要把申请路由到该节点，缩小用户期待和申请时长。
限流机制：在接入层和代理层能够做限流，当缓存服务无奈反对高并发的时候，前端能够把无奈响应的申请放入到队列或者抛弃。
隔离机制：缓存无奈提供服务或者正在预热重建的时候，把该申请放入队列中，这样该申请因为被隔离就不会被路由到其余的缓存节点。
如此就不会因为这个节点的问题影响到其余节点。当缓存重建当前，再从队列中取出申请顺次解决。
5.2.2. 缓存穿透
缓存个别是 Key，Value 形式存在，一个 Key 对应的 Value 不存在时，申请会回源到数据库。
如果对应的 Value 始终不存在，则会频繁的申请数据库，对数据库造成拜访压力。如果有人利用这个破绽攻打，就麻烦了。
解决办法：如果一个 Key 对应的 Value 查问返回为空，咱们依然把这个空后果缓存起来，如果这个值没有变动下次查问就不会申请数据库了。
将所有可能存在的数据哈希到一个足够大的 Bitmap 中，那么不存在的数据会被这个 Bitmap 过滤器拦挡掉，防止对数据库的查问压力。
5.2.3. 缓存击穿
在数据申请的时候，某一个缓存刚好生效或者正在写入缓存，同时这个缓存数据可能会在这个工夫点被超高并发申请，成为“热点”数据。
这就是缓存击穿问题，这个和缓存雪崩的区别在于，这里是针对某一个缓存，前者是针对多个缓存。
解决方案：导致问题的起因是在同一时间读 / 写缓存，所以只有保障同一时间只有一个线程写，写实现当前，其余的申请再应用缓存就能够了。
比拟罕用的做法是应用 mutex（互斥锁）。在缓存生效的时候，不是立刻写入缓存，而是先设置一个 mutex（互斥锁）。当缓存被写入实现当前，再放开这个锁让申请进行拜访。
小结
总结一下，缓存设计有五大策略，从用户申请开始顺次是：
HTTP 缓存
CDN 缓存
负载平衡缓存
过程内缓存
分布式缓存
其中，前两种缓存静态数据，后三种缓存动态数据：
HTTP 缓存包含强制缓存和比照缓存。
CDN 缓存和 HTTP 缓存是好搭档。
负载均衡器缓存绝对稳固资源，须要服务帮助工作。
过程内缓存，效率高，但容量有限度，有两个计划能够应答缓存同步的问题。
分布式缓存容量大，能力强，牢记三个性能算法并且防备三个缓存危险。
