摘要： CDN 在静态资源的加速场景中是将静态资源缓存在距离客户端较近的CDN 节点上，然后客户端访问该资源即可通过较短的链路直接从缓存中获取资源，而避免再通过较长的链路回源获取静态资源。因此 CDN的缓存命中率的高低直接影响客户体验，而保证较高的命中率也成为了站长的核心命题。
点此查看原文：https://yq.aliyun.com/articles/288084?spm=a2c41.11181499.0.0
CDN 在静态资源的加速场景中是将静态资源缓存在距离客户端较近的CDN 节点上，然后客户端访问该资源即可通过较短的链路直接从缓存中获取资源，而避免再通过较长的链路回源获取静态资源。因此 CDN的缓存命中率的高低直接影响客户体验，而保证较高的命中率也成为了站长的核心命题。在本文中我们就一起探讨 CDN 缓存命中率的概念、影响因素以及优化策略。
1、缓存命中率的概念
CDN 的缓存命中率包括两种：字节缓存命中率和请求缓存命中率。其中字节缓存命中率是指 CDN 缓存命中 Response 的字节数除以 CDN所有请求 Response 的字节数。而请求缓存命中率是指 CDN 缓存命中的请求的个数除以 CDN 所有的请求数。
从上面的描述中可以查看到字节缓存命中率可以表征回源流量的大小，回源流量越高那么源站的流出流量也就越大，这样对于源站的带宽资源以及其他的负载都会越大，因此回源流量代表了源站服务器接收到的负载压力。而我们在业务使用中也主要关心字节缓存命中率。
查看缓存命中率主要包括控制台、 CDN 日志和 API/SDK 查看两种方式。现在 CDN 控制台上提供的命中率监控均是字节缓存命中率，如图1 中所示即是控制台监控信息中命中率的详情。
图 1. 控制台命中率监控示意图
在CDN的请求日志中，CDN记录了所有的CDN请求的缓存命中状态，详细的日志格式请参考CDN日志格式，其中“cache命中状态”字段为HIT即表示命中，而MISS即表示未命中的状态。这里特别需要注意的一点是这里的命中状态仅表征CDN的L1节点的命中状态，当CDN的L1节点未命中缓存但是L2节点命中缓存的情况下这里仍然会显示MISS。
而API/SDK的方式CDN分别提供了DescribeDomainHitRateData和DescribeDomainReqHitRateData两个接口分别查询的CDN的字节缓存命中率和请求缓存命中率。该接口是可以查看到历史90天内的所有的数据。
2、影响因素及优化建议
CDN的缓存规则同时按照CDN上的缓存规则、源站配置的Cache-Control等response头、文件类型等综合考虑，具体的缓存规则解读建议查阅【 CDN 最佳实践】CDN 缓存策略解读和配置策略。那么按照上述的缓存规则会影响命中率的因素主要有以下：
1. 文件类型是否适合于在CDN上缓存。
CDN在业务架构中负责加速静态资源，因此如果动态资源也经过CDN的话是会导致CDN的命中率下降的。CDN判断动态文件和静态文件的标准是该文件的response头中是否带有Etag头和Last-modified头。这两个头在HTTP协议中分别通过文件内容和文件最后修改时间表征文件的修改情况。
因此建议用户使用过程中优化点：
网站架构是否适合于动静分离。动静分离是常见的网站优化的策略，主要是通过将静态资源和动态资源分离成两个站点提供服务。静态资源由于长时间不会发生变化，因此可以使用CDN加速；而动态资源因为需要实时获取源站的资源并且可能源站加载需要一段时间（CDN回源获取数据有严格的的回源超时时间，动态文件响应较慢可能导致CDN回源直接抛出504错误）而直接解析到源站服务器拉取资源。
静态文件文件是否在response头中返回Etag头和Last-modified头。在CDN上没有配置缓存规则的情况下，静态文件没有返回Etag头和Last-modified头也同样会导致该静态资源不在CDN节点上缓存。如图2中所示，x-swift-cachetime头即表示该文件在CDN上的缓存时间（单位是秒）。该文件其实为静态文件，但是由于response头中没有Etag和Last-modified导致CDN并不会该文件进行缓存。
图 2. CDN 缓存时间示意图
配置合理的源站缓存规则。源站服务器可以针对于资源配置其缓存规则。当源站配置了以下response头时CDN将不会对该文件进行缓存：
1）有s-maxage=0，no-cache，no-store，private其中一种
2）如果没有s-maxage或者s-maxage=0，并且有max-age=0.
3）带Pragma: no-cache
而且上述的response头在CDN缓存规则中将有最高优先级（即使CDN上配置了缓存规则也不缓存），因此上述的这些response头并不适合于配置于源站的静态资源的。另外当CDN上没有配置缓存规则时,资源的缓存规则将按照源站的Cache-Control或者Expires头进行缓存（Cache-Control优先级比Expires高），因此建议用户设置合理的Cache-Control或者Expires头。
配置缓存规则。上面所指的没有包括Etag和Last-modified头而导致CDN缓存时间为0的场景是CDN控制台上没有配置缓存配置时会出现这种情况，因此如果用户的静态资源确实无法配置上述两个response头的话是可以考虑针对该文件配置缓存规则，这样该文件即可在CDN上按照缓存规则进行缓存。
2. CDN的刷新和预热功能
CDN提供了刷新缓存和预热缓存两个操作。两个操作都会对缓存命中率有影响，但是两个操作的影响是完全相反的。因此用户是需要了解两个操作的概念以及使用场景。
刷新功能是指将特定URL或者目录下的所有历史缓存的内容清除掉，该操作常用于源站进行同名更新后导致CDN缓存内容已为历史脏数据，刷新后将使URL下次访问时直接回源。因此会导致命中率下降。
预热功能是将URL提前上传到CDN的L2节点上，这样下次访问的时候就不需要从源站再拉取资源了，因此预热是没有直接导致L1的命中率升高，但提升了CDN的真实命中率。
因此建议用户使用过程中优化点：
慎重使用刷新功能。刷新功能肯定是会导致命中率出现下降的，特别是对于加速域名根目录的刷新任务会导致加速域名下的所有缓存均无效，势必会导致后续出现大量回源请求导致源站服务器负载升高。因此请用户在实际线上环境特别是高峰期进行刷新操作。另外建议客户尽量避免执行静态资源同名更新，可以尝试通过添加queryString的方式进行版本更替（例如url中带有?version=1.1等方式）。
业务高峰前预热热门资源。预热可以提前将资源预热到CDN的L2节点，避免业务高峰对于源站产生压力，也同时保证了CDN的真实命中率。但是预热的请求次数每天客户均是有条数限制的，因此建议客户可以根据历史的热门资源统计得要待预热的资源URL进行操作。
3. CDN缓存规则是否合理
CDN上是可以针对于目录或者后缀名设置缓存配置的。而在CDN和源站同时配置缓存规则时是会以CDN上的缓存规则优先的（除非源站设置了不允许缓存的规则），因此建议用户在CDN控制台中设置合理的缓存规则，避免走默认的缓存规则导致频繁回源（默认缓存经常缓存3600秒过期）。另外特别注意CDN控制台上配置的缓存时间为0秒时该资源并不是客户端直接请求到源站的，而是客户端请求仍然会先到CDN节点，然后由CDN节点触发回源请求到源站获取资源，并且流出流量仍然会计算CDN的流出流量。
4. 可变参数导致命中率下降
客户请求的URL中常带有queryString，例如上面所说的请求URL中为了区分版本带上?version=1.1等参数或者CDN回源到私有读写类型的bucket时会带上OSS私有访问需要的OSSAccessKeyId、Expires和Signature参数。在CDN处理的过程中默认的处理逻辑是对于同样的URL而带有不同queryString的请求会认为完全不同的请求，因此缓存也对应的是不同份，这就会导致如果queryString参数发生变化时会导致重新回源，因此命中率会出现下降的情况。
因此建议用户使用过程中优化点：
业务系统允许的情况下使用“过滤参数”功能。开启过滤参数功能后，CDN接收到queryString的URL替换成没有带参数的URL。例如请求URL为http://www.aliyun.com/1.jpg?version=1，开启过滤参数后将替换URL为http://www.aliyun.com/1.jpg，这样讲查看是否存在有http://www.aliyun.com/1.jpg的缓存，如果有的话将直接返回客户端；如果没有缓存的话就会按照http://www.aliyun.com/1.jpg请求回源站。因此业务系统允许queryString不敏感的情况下可以开启该功能。但是对于一些系统需要queryString进行传参或者设置跳转逻辑的话就不能开启该功能。
对于CDN加速OSS的场景建议使用“私有bucket回源”功能。当OSS设置为私有时不可以开启过滤参数并且当签名querystring发生变化时还会影响CDN缓存命中率。而“私有bucket回源”功能将使CDN的请求回源OSS的时候自动带上签名querystring参数，而不需要客户自己在请求CDN的时候设置。这样即实现了OSS本身资源的安全防护而又不影响CDN的缓存命中率。
5. CDN加速域名流量较低
CDN节点作为所有使用CDN的用户公用的节点资源，因此CDN配置的缓存规则表示了该资源在CDN上的缓存最长时间，如果用户在CDN上的缓存资源的热度较低的话是有可能被提前踢出CDN节点的缓存的。因此可以理解为缓存按照热度属性采取末尾淘汰制，所谓热度就是该文件在该节点上被访问的频率，文件热度不够即被提前剔除。
因此建议用户使用过程中优化点：
对于流量较低的域名可以提前定期将热度资源预热到CDN节点上，避免影响业务使用。
建议用户考虑对于流量较低的域名可以不使用CDN加速，这样的域名的加速效果并不明显。
来源：oschina
链接：https://my.oschina.net/u/3552485/blog/1612289