阿里雲的CDN緩存系統簡介

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秒。

其他的內容一時辦會想不起來了。。。如果有比較中重要的會進行補充