如何做deal网站推广,无锡市网站,手机能建网站吗,seo做得比较好的公司前言
缓存技术存在于应用场景的方方面面。从浏览器请求#xff0c;到反向代理服务器#xff0c;从进程内缓存到分布式缓存#xff0c;其中缓存策略算法也是层出不穷。
假设一个网站#xff0c;需要提高性能#xff0c;缓存可以放在浏览器#xff0c;可以放在反向代理服…前言
缓存技术存在于应用场景的方方面面。从浏览器请求到反向代理服务器从进程内缓存到分布式缓存其中缓存策略算法也是层出不穷。
假设一个网站需要提高性能缓存可以放在浏览器可以放在反向代理服务器还可以放在应用程序进程内同时可以放在分布式缓存系统中。
从用户请求数据到数据返回数据经过了浏览器CDN代理服务器应用服务器以及数据库各个环节。每个环节都可以运用缓存技术。
从浏览器/客户端开始请求数据通过 HTTP 配合 CDN 获取数据的变更情况到达代理服务器Nginx可以通过反向代理获取静态资源。
再往下来到应用服务器可以通过进程内堆内缓存分布式缓存等递进的方式获取数据。如果以上所有缓存都没有命中数据才会回源到数据库。
缓存的请求顺序是用户请求 → HTTP 缓存 → CDN 缓存 → 代理服务器缓存 → 进程内缓存 → 分布式缓存 → 数据库。
看来在技术的架构每个环节都可以加入缓存看看每个环节是如何应用缓存技术的。 HTTP 缓存
当用户通过浏览器请求服务器的时候会发起 HTTP 请求如果对每次 HTTP 请求进行缓存那么可以减少应用服务器的压力。
当第一次请求的时候浏览器本地缓存库没有缓存数据会从服务器取数据并且放到浏览器的缓存库中下次再进行请求的时候会根据缓存的策略来读取本地或者服务的信息。
私有缓存
私有缓存是绑定到特定客户端的缓存——通常是浏览器缓存。由于存储的响应不与其他客户端共享因此私有缓存可以存储该用户的个性化响应。该种缓存
如果响应包含个性化内容并且你只想将响应存储在私有缓存中则必须指定 private 指令。
Cache-Control: private共享缓存
共享缓存位于客户端和服务器之间可以存储能在用户之间共享的响应可以供多个客户端使用的缓存通常依赖于代理服务器。
客户端发起的第一个请求通过代理服务器访问源服务器缓存生效后会存放在代理服务器后续客户端发起的相同请求均由代理服务器提供缓存服务共享缓存可以减轻源服务器的压力 其实共享代理可以细分为代理缓存和托管缓存简单理解代理缓存由代理服务器管理位于客户端与原始服务器之间减轻服务器负载、提高响应速度。托管缓存由内容提供商或 CDN 管理分布全球提供更快的内容传递和更好的用户体验。 缓存处理机制
下方为整体处理机制示意图后文很多内容针对图中某些环节进行扩展讲解 上面强缓存中的 Pragma 大多数用于 http 1.0http 1.1 中也适用而 Cache-Control 只能应用于 http 1.1 需要注意的是Expires 为服务端返回的过期时间这种判断缓存是否过期的方式在 HTTP 1.0 用的比较多到了 HTTP 1.1 会使用 Cache-Control 的 max-age 属性替代单位是秒 Last-Modified/If-Modified-Since 规则
在客户端第一次请求的时候服务器会返回资源最后的修改时间记作 Last-Modified。客户端将这个字段连同资源缓存起来。
当客户端再次请求服务器时会把 Last-Modified 连同请求的资源一起发给服务器这时 Last-Modified 会被命名为 If-Modified-Since但其内容一样。
服务器收到请求会把 If-Modified-Since 字段与服务器上保存的 Last-Modified 字段作比较
若服务器上的 Last-Modified 最后修改时间大于请求的 If-Modified-Since说明资源被改动过就会把资源包括 HeaderBody重新返回给浏览器同时返回状态码 200。若资源的最后修改时间小于或等于 If-Modified-Since说明资源没有改动过只会返回 Header并且返回状态码 304。浏览器接受到这个消息就可以使用本地缓存库的数据。 注意Last-Modified 和 If-Modified-Since 指的是同一个值只是在客户端和服务器端的叫法不同。 ETag / If-None-Match 规则
客户端第一次请求的时候服务器会给每个资源生成一个 ETag 标记。这个 ETag 是根据每个资源生成的唯一 Hash 串资源如何发生变化 ETag 随之更改之后将这个 ETag 返回给客户端客户端把请求的资源和 ETag 都缓存到本地。
在浏览器第二次请求服务器相同资源时会把资源对应的 ETag 一并发送给服务器。在请求时 ETag 会被命名为 If-None-Match但其内容不变
服务器收到请求后会把 If-None-Match 与服务器上资源的 ETag 进行比较
如果不一致说明资源被改动过则返回资源HeaderBody返回状态码 200。如果一致说明资源没有被改过则返回 Header返回状态码 304。浏览器接受到这个消息就可以使用本地缓存库的数据。
规则使用时机
那么什么时候使用修改日期Last-Modified再验证和实体标签再验证ETag呢
如果服务器返回了一个 ETag 首部客户端就必须使用 If-None-Match 实体标签再验证如果服务器返回了一个 Last-Modified 首部客户端就可以使用 If-Modified-Since 修改日期再验证如果 ETag 和 Last-Modified 都提供了客户端就应该同时使用这两种再验证方案。
如果HTTP/1.1缓存或服务器收到的请求既带有 If-Modified-Since又带有 If-None-Match那么只有这两个条件都满足时才能返回304 Not Modified响应。
缓存控制策略
对于网站来说缓存是达到高性能的重要组成部分缓存需要合理配置因为并不是所有资源都是永久不变的。Cache-Control 首部可以对缓存进行控制Cache-Control 能用于 HTTP 请求和响应中支持多个指令以逗号分隔
请求首部描述Cache-Control: no-store不使用缓存。Cache-Control: no-cache使用缓存前无论本地副本是否过期都需要请求源服务器进行验证协商缓存验证。Cache-Control: max-age秒设置缓存存储的最大期限超过这个期限缓存被认为过期时间是相对于请求的时间。Cache-Control: max-stale秒客户端愿意接收一个已经过期的资源。可以设置一个可选的秒数表示响应不能已经过时超过该给定的时间。Cache-Control: min-fresh秒客户端希望获取一个能在指定的秒数内保持其最新状态的响应。
响应首部描述Cache-Control: no-store不使用缓存。Cache-Control: no-cache使用缓存前无论本地副本是否过期都需要请求源服务器进行验证协商缓存验证。Cache-Control: max-age秒设置缓存存储的最大期限超过这个期限缓存被认为过期时间是相对于请求的时间。Cache-Control: s-maxage秒同 max-age仅适用于共享缓存。Cache-Control: private私有缓存响应只能被单个客户端缓存。Cache-Control: public共享缓存即由缓存代理服务器提供的缓存响应可以被多个客户端缓存。Cache-Control: must-revalidate如果本地副本未过期则可继续供客户端使用不需要向源服务器再验证如果本地副本已过期比如已经超过 max-age在成功向源服务器验证之前缓存不能用该资源响应后续请求。Cache-Control: proxy-revalidate同 must-revalidate仅适用于共享缓存。
Cache-Control有几个指令特别容易混淆不能望文生义。比如no-cache并不是指不能用 cache客户端仍会把带有 no-cache 的响应缓存下来只不过每次不会直接用缓存而是要先去服务端验证一下。如果你想让客户端完全不缓存响应应该用no-store带有no-store的响应不会被缓存到任意的磁盘或者内存里它才是真正的 no-cache。
下面是对三个容易混淆的指令进行对比说明
首部描述Cache-Control: no-store不使用缓存。Cache-Control: no-cache无论本地副本是否过期都需要请求源服务器进行验证。Cache-Control: must-revalidate如果本地副本未过期可以使用本地副本否则需要请求源服务器进行验证。
CDN 缓存
HTTP 缓存主要是对静态数据进行缓存把从服务器拿到的数据缓存到客户端/浏览器。
如果在客户端和服务器之间再加上一层 CDN可以让 CDN 为应用服务器提供缓存如果在 CDN 上缓存就不用再请求应用服务器了。并且 HTTP 缓存提到的两种策略同样可以在 CDN 服务器执行。
CDN 的全称是 Content Delivery Network即内容分发网络。其目的是通过在现有的 Internet 中增加一层新的网络架构将网站的内容发布到最接近用户的网络边缘使用户可以就近取得所需的内容解决 Internet 网络拥塞状况提高用户访问网站的响应速度。
从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。
CDN 分发系统架构 CDN 工作流程 用户访问某个站点的内容时若该站点使用了 CDN 网络则在用户会在域名解析时获得 CDN 网络 GSLB 设备的 IP 地址。GSLB 设备根据其预设的选择策略如地理区域、用户时间等为用户选择最合适的内容缓存节点并且使用某种方式如基于 DNS、基于 HTTP 重定向、基于 IP 欺骗的方式等导引用户访问所选的内容缓存节点。
用户继续向缓存节点发出请求若缓存中包含请求的内容则直接返回给用户否则从核心Web服务器中获取该内容缓存后返回给用户。这样当用户再次访问相同内容或其他用户访问相同内容时可以直接从缓存中读取提高了效率。
负载均衡缓存
说完客户端HTTP缓存和 CDN 缓存我们离应用服务越来越近了在到达应用服务之前请求还要经过负载均衡器。
虽说它的主要工作是对应用服务器进行负载均衡但是它也可以作缓存。可以把一些修改频率不高的数据缓存在这里例如用户信息配置信息。通过服务定期刷新这个缓存就行了。
以 Nginx 为例我们看看它是如何工作的
用户请求在达到应用服务器之前会先访问 Nginx 负载均衡器如果发现有缓存信息直接返回给用户。如果没有发现缓存信息Nginx 回源到应用服务器获取信息。另外有一个缓存更新服务定期把应用服务器中相对稳定的信息更新到 Nginx 本地缓存中。 进程内缓存
通过了客户端CDN负载均衡器我们终于来到了应用服务器。应用服务器上部署着一个个应用这些应用以进程的方式运行着那么在进程中的缓存是怎样的呢
进程内缓存又叫托管堆缓存以 Java 为例这部分缓存放在 JVM 的托管堆上面同时会受到托管堆回收算法的影响。
由于其运行在内存中对数据的响应速度很快通常我们会把热点数据放在这里。
在进程内缓存没有命中的时候我们会去搜索进程外的缓存或者分布式缓存。这种缓存的好处是没有序列化和反序列化是最快的缓存。缺点是缓存的空间不能太大对垃圾回收器的性能有影响。
目前比较流行的实现有 Ehcache、GuavaCache、Caffeine。这些架构可以很方便的把一些热点数据放到进程内的缓存中。
这里我们需要关注几个缓存的回收策略具体的实现架构的回收策略会有所不同但大致的思路都是一致的
FIFOFirst In First Out先进先出算法最先放入缓存的数据最先被移除。LRULeast Recently Used最近最少使用算法把最久没有使用过的数据移除缓存。LFULeast Frequently Used最不常用算法在一段时间内使用频率最小的数据被移除缓存。
在分布式架构的今天多应用中如果采用进程内缓存会存在数据一致性的问题。
解决方案
保障进程内缓存数据一致性有以下几种方案
单节点通知修改方案 第一种方案可以通过单节点通知其他节点。如上图写请求发生在 server1在修改完自己内存数据与数据库中的数据之后可以主动通知其他 server 节点也修改内存的数据。
这种方案的缺点是同一功能的一个集群的多个节点相互耦合在一起特别是节点较多时网状连接关系极其复杂。
消息队列修改方案 第二种方案可以通过 MQ 通知其他节点。如上图写请求发生在 server1在修改完自己内存数据与数据库中的数据之后给 MQ 发布数据变化通知其他 server 节点订阅 MQ 消息也修改内存数据。
这种方案虽然解除了节点之间的耦合但引入了MQ使得系统更加复杂。
前两种方案节点数量越多数据冗余份数越多数据同时更新的原子性越难保证一致性也就越难保证。
Timer 修改方案 第三种方案为了避免耦合降低复杂性干脆放弃了“实时一致性”每个节点启动一个timer定时从后端拉取最新的数据更新内存缓存。在有节点更新后端数据而其他节点通过timer更新数据之间会读到脏数据。
应用场景
为什么不能频繁使用进程内缓存
分层架构设计有一条准则站点层、服务层要做到无数据无状态这样才能任意的加节点水平扩展数据和状态尽量存储到后端的数据存储服务例如数据库服务或者缓存服务。
可以看到站点与服务的进程内缓存实际上违背了分层架构设计的无状态准则故一般不推荐使用。
那么什么情况下可以考虑使用进程内缓存
情况一只读数据可以考虑在进程启动时加载到内存。 其实此时也可以把数据加载到 redis / memcache进程外缓存服务也能解决这类问题。 情况二极高并发如果透传后端压力极大的场景可以考虑使用进程内缓存。
例如秒杀业务并发量极高需要站点层挡住流量可以使用内存缓存。
情况三一定程度上允许数据不一致业务。
例如有一些计数场景运营场景页面对数据一致性要求较低可以考虑使用进程内页面缓存。
再次强调下进程内缓存的适用场景并不如 redis/memcache 广泛不要为了炫技而使用。
分布式缓存
与进程内缓存相对应的就是进程外缓存它拥有更大的缓存容量并且可以部署到不同的物理节点通常会用分布式缓存的方式实现。
分布式缓存是与应用分离的缓存服务最大的特点是自身是一个独立的应用/服务与本地应用隔离多个应用可直接共享一个或者多个缓存应用/服务。 既然是分布式缓存缓存的数据会分布到不同的缓存节点上每个缓存节点缓存的数据大小通常也是有限制的。
数据被缓存到不同的节点为了能方便的访问这些节点需要引入缓存代理类似 Twemproxy。他会帮助请求找到对应的缓存节点。
同时如果缓存节点增加了这个代理也会只能识别并且把新的缓存数据分片到新的节点做横向的扩展。
为了提高缓存的可用性会在原有的缓存节点上加入 Master/Slave 的设计。当缓存数据写入 Master 节点的时候会同时同步一份到 Slave 节点。
一旦 Master 节点失效可以通过代理直接切换到 Slave 节点这时 Slave 节点就变成了 Master 节点保证缓存的正常工作。
每个缓存节点还会提供缓存过期的机制并且会把缓存内容定期以快照的方式保存到文件上方便缓存崩溃之后启动预热加载。
当缓存做成分布式的时候数据会根据一定的规律分配到每个缓存应用/服务上需要缓存的数据量比较大就需要扩展多个缓存节点来实现这么多的缓存节点客户端的请求不知道访问哪个节点怎么办缓存的数据又如何放到这些节点上
下面介绍三种缓存数据分片的算法有了这些算法缓存代理就可以方便的找到分片的数据
哈希分片 Hash 分片的算法就是对缓存的 Key 做哈希计算然后对总的缓存节点个数取余。你可以这么理解
比如说我们部署了三个缓存节点组成一个缓存的集群当有新的数据要写入时我们先对这个缓存的 Key 做比如 crc32 等 Hash 算法生成 Hash 值然后对 Hash 值模 3得出的结果就是要存入缓存节点的序号。
这个算法最大的优点就是简单易理解缺点是当增加或者减少缓存节点时缓存总的节点个数变化造成计算出来的节点发生变化从而造成缓存失效不可用。
所以如果采用这种方法最好建立在你对于这组缓存命中率下降不敏感比如下面还有另外一层缓存来兜底的情况下。那有没有更好的方案能解决这个问题呢那就是一致性 Hash 分片算法。
一致性哈希分片
用一致性 Hash 算法可以很好地解决增加和删减节点时命中率下降的问题。在这个算法中我们将整个 Hash 值空间组织成一个虚拟的圆环然后将缓存节点的 IP 地址或者主机名做 Hash 取值后放置在这个圆环上。当我们需要确定某一个 Key 需要存取到哪个节点上的时候先对这个 Key 做同样的 Hash 取值确定在环上的位置然后按照顺时针方向在环上“行走”遇到的第一个缓存节点就是要访问的节点。比方说下面这张图里面Key 1 和 Key 2 会落入到 Node 1 中Key 3、Key 4 会落入到 Node 2 中Key 5 落入到 Node 3 中Key 6 落入到 Node 4 中。 这时如果在 Node 1 和 Node 2 之间增加一个 Node 5你可以看到原本命中 Node 2 的 Key 3 现在命中到 Node 5而其它的 Key 都没有变化同样的道理如果我们把 Node 3 从集群中移除那么只会影响到 Key 5 。所以你看在增加和删除节点时只有少量的 Key 会 漂移 到其它节点上而大部分的 Key 命中的节点还是会保持不变从而可以保证命中率不会大幅下降。 不过事物总有两面性。虽然这个算法对命中率的影响比较小但它还是存在问题
缓存节点在圆环上分布不平均会造成部分缓存节点的压力较大当某个节点故障时这个节点所要承担的所有访问都会被顺移到另一个节点上会对后面这个节点造成压力。
一致性哈希的脏数据问题
极端情况下比如一个有三个节点 A、B、C 承担整体的访问每个节点的访问量平均A 故障后B 将承担双倍的压力A 和 B 的全部请求当 B 承担不了流量 Crash 后C 也将因为要承担原先三倍的流量而 Crash这就造成了整体缓存系统的雪崩。
解决方案就是在一致性 Hash 算法中引入虚拟节点的概念它将一个缓存节点计算多个 Hash 值分散到圆环的不同位置这样既实现了数据的平均而且当某一个节点故障或者退出的时候它原先承担的 Key 将以更加平均的方式分配到其他节点上从而避免雪崩的发生。
其次就是一致性 Hash 算法的脏数据问题。为什么会产生脏数据呢 比方说在集群中有两个节点 A 和 B客户端初始写入一个 Key 为 k值为 3 的缓存数据到 Cache A 中。这时如果要更新 k 的值为 4但是缓存 A 恰好和客户端连接出现了问题那这次写入请求会写入到 Cache B 中。接下来缓存 A 和客户端的连接恢复当客户端要获取 k 的值时就会获取到存在 Cache A 中的脏数据 3而不是 Cache B 中的 4。
所以在使用一致性 Hash 算法时一定要设置缓存的过期时间这样当发生漂移时之前存储的脏数据可能已经过期就可以减少存在脏数据的几率。 很显然数据分片最大的优势就是缓解缓存节点的存储和访问压力但同时它也让缓存的使用更加复杂。在 MultiGet批量获取场景下单个节点的访问量并没有减少同时节点数太多会造成缓存访问的 SLA即“服务等级协议”SLA 代表了网站服务可用性得不到很好的保证因为根据木桶原则SLA 取决于最慢、最坏的节点的情况节点数过多也会增加出问题的概率因此我推荐 4 到 6 个节点为佳。
按照数据范围分片
常见场景就是按照 时间区间 或 ID区间 来切分。例如按日期将不同月甚至是日的数据分散到不同的库中将 userId 为 1~9999 的记录分到第一个库 10000~20000 的分到第二个库以此类推。某种意义上某些系统中使用的 “冷热数据分离” 将一些使用较少的历史数据迁移到其他库中业务功能上只提供热点数据的查询也是类似的实践。
这样的优点在于
单表大小可控天然便于水平扩展后期如果想对整个分片集群扩容时只需要添加节点即可无需对其他分片的数据进行迁移使用分片字段进行范围查找时连续分片可快速定位分片进行快速查询有效避免跨分片查询的问题。
缺点
热点数据成为性能瓶颈。连续分片可能存在数据热点例如按时间字段分片有些分片存储最近时间段内的数据可能会被频繁的读写而有些分片存储的历史数据则很少被查询
参考链接
一篇文章让你明白你多级缓存的分层架构 - 掘金 (juejin.cn)分布式多级缓存SDK设计的思考-腾讯云开发者社区-腾讯云 (tencent.com)多级缓存架构设计 - 秦羽的思考 - 博客园 (cnblogs.com)HTTP 缓存 - HTTP | MDN (mozilla.org)30分钟搞懂 HTTP 缓存 - 掘金 (juejin.cn)【CDN 最佳实践】CDN缓存策略解读和配置策略 - 知乎 (zhihu.com)CDN图解秒懂 史上最全 - 疯狂创客圈 - 博客园 (cnblogs.com)009.Nginx缓存配置 - 木二 - 博客园进程内缓存究竟怎么玩-阿里云开发者社区 (aliyun.com)Hash分片一致性Hash分片和按照数据范围分片三种常用的数据分片方式-腾讯云开发者社区-腾讯云 (tencent.com) 本文由博客一文多发平台 OpenWrite 发布
