CDN会把热点数据缓存到磁盘中。当有用户请求资源时，直接在节点命中，这样既提高了访问质量，又减少了源站压力。
关于如何缓存的设置，主要有几个方向可以设置
缓存过期时间，主要是指定路径和指定后缀
状态码的过期时间
配置HTTP头
简单来说，如果源站设置有cache-control: no cache，则不缓存，否则遵循控制台的配置，根据设置的权重来判断优先级。
关于缓存时间的设定，我个人的理解如下：
如果文件很长时间不会更改，或者不会更改的情况，可以设置的比较长的时间，比如: 1415000
如果是文件经常变化，比如每次发版都会有所改变，建议设置的缓存时间比较短，1天即可。否则设置的时间比较长，文件已经发生了变化，但节点有缓存，导致客户请求的是旧的数据。（还可以进行刷新操作，让节点强制刷新资源）
如果缓存的文件包含有参数，如果是所有人都可以访问的数据，可以开启忽略参数，提高资源的命中率
当访问到了旧数据怎么办？
有时候，我们设置的其他缓存的配置生效了，此文件被节点缓存，因此导致我们认为此文件应该会缓存过期回源站拿去最新的数据才对，但节点一直访问就数据。
还有一种情况，是缓存权重的配置导致此文件的缓存时间和预期不符
这时，我们可以看文件的的相应头来进行判断。
如何对测试的数据进行分析?
我们以访淘宝为例，使用curl命令进行测试
[root@www ~]# curl -voa "https://www.taobao.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 113.96.109.100:443...
* Connected to www.taobao.com (113.96.109.100) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: none
CApath: none
* loaded libnssckbi.so
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* ALPN, server accepted to use h2
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=*.tmall.com,O="Alibaba (China) Technology Co., Ltd.",L=HangZhou,ST=ZheJiang,C=CN
* start date: Oct 25 01:37:06 2019 GMT
* expire date: Oct 25 01:31:07 2020 GMT
* common name: *.tmall.com
* issuer: CN=GlobalSign Organization Validation CA - SHA256 - G2,O=GlobalSign nv-sa,C=BE
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x1d86b60)
> GET / HTTP/2
> Host: www.taobao.com
> user-agent: curl/7.70.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< server: Tengine
< content-type: text/html; charset=utf-8
< date: Fri, 24 Jul 2020 14:34:51 GMT
< x-server-id: a16302202f88609bab59d6107b4cee5b05f9fdc9801d6ce04d59a5d982d54dd9
< x-air-hostname: air-ual011001242127.center.na62
< x-air-trace-id: 71606d2115956012909997926e
< vary: Accept-Encoding, ali-detector-type, x-cip-pt
< x-air-source: backup
< etag: W/"static-1736b1f0850"
< x-backup: 1595230062672
< cache-control: s-maxage=300
< x-xss-protection: 1; mode=block
< x-readtime: 15
< eagleeye-traceid: 71606d2115956012909997926e
< strict-transport-security: max-age=31536000
< timing-allow-origin: *, *
< via: cache19.l2st3-1[210,304-0,H], cache44.l2st3-1[212,0], cache10.cn747[0,200-0,H], cache6.cn747[1,0]
< ali-swift-global-savetime: 1595230489
< age: 109
< x-cache: HIT TCP_MEM_HIT dirn:0:112410018
< x-swift-savetime: Fri, 24 Jul 2020 14:34:51 GMT
< x-swift-cachetime: 300
< eagleid: 71606d1a15956014008752388e
<
{ [1924 bytes data]
100 144k 0 144k 0 0 545k 0 --:--:-- --:--:-- --:--:-- 543k
* Connection #0 to host www.taobao.com left intact
Trying 113.96.109.100:443... 表示哪个节点提供的访问
从第6行到17行在校验证书的可靠性
18行-25行是自身的请求头信息
28行为http返回的状态码
29行server: Tengine表示你web服务器使用的软件
30行content-type: text/html; charset=utf-8表示文件的类型
date源站吐出数据的时间
cache-control: s-maxage=300表示缓存的时间300s
eagleeye-traceid相当于此次请求的表示符，如果说这个请求有异常或者卡顿，可以提供给阿里云的售后同学来排查原因
strict-transport-security 开启了HSTS功能
via数据缓存的走向，通过了哪些节点，为我们进行的服务（H表示Hit命中，M表示MISS，C表示合并回源）此处是多副本模式。
ali-swift-global-savetime文件进入缓存系统的时间
age距离缓存到资源的时间
x-cache 可能表示资源是HIT，特殊相应头，初步判断的
x-swift-savetime这个节点缓存资源的时间
x-swift-cachetime接待你缓存此资源的时间
可以通过以上的相应头信息来进行判断，在哪里出现的问题。
Tips:
阿里云CDN默认会缓存301、302错误码
对于状态码303、304、401、407、600和601，不进行缓存。
对于状态码204、305、400、403、404、405、414、500、501、502、503和504，如果源站响应了Cache-Control，则遵循源站的Cache-Control原则。如果未设置状态码，则缓存时间默认为1秒。
其他的内容一时办会想不起来了。。。如果有比较中重要的会进行补充