看到了小白的文章, 為了加深印象自己來整理一下

前言

對于開發同學來說，CDN這個詞，既熟悉又陌生。
平時搞開發的時候很少需要碰這個，但卻總能聽到別人提起。
我們都聽說過它能加速，也大概知道個原因，但是往深了問。用了CDN就一定比不用更快嗎？
就感覺有些懵了。但沒關系，今天我們換個角度重新認識下CDN。

CDN是什么?

對于數字和文本類型的數據，比方說名字和電話號碼相關的信息。我們需要有個地方存起來。我們通常會用mysql數據庫去存。

當我們需要重新將這一數據取出的時候，就需要去讀mysql數據庫。但因為mysql的數據是存在磁盤上的，單臺實例，讀性能到差不多5kqps就已經很不錯了。

看起來還湊合，但對于稍微大一點的系統，就稍微有點捉急了。
為了提升點性能，我們在mysql之前再加一層內存做緩存層，比如常說的redis，讀數據優先到內存里讀，讀不到才到mysql里讀，大大減少了讀mysql的次數。有了這套組合拳，讀性能輕松上萬qps。

到這里，我們說的都是我們平時比較容易接觸的開發場景。

但如果現在我要處理的，不再是上面提到的文本類數據，而是圖片數據。

那么問題來了。這張圖片數據應該存在哪？，又該從哪里讀？

我們回過頭去看mysql和redis的場景，無非就是存儲層加緩存層。

對于圖片這樣的文件對象，存儲層不太可能再用mysql，應該改用專業的對象存儲，比如亞馬遜的S3（Amazon Simple Storage Service，注意后面是三個S開頭的單詞，所以叫s3），或者阿里云的oss（Object Storage Service）。

下面的內容，我們就用比較常見的oss去做解釋。

而緩存層，也不能繼續用redis了，需要改成使用CDN（Content Delivery Network，內容分發網絡）。可以將CDN簡單理解為對象存儲對應的緩存層。

現在就可以回答上面的提問，對用戶來說，這張圖片數據存在了對象存儲那，當有需要的時候，會從CDN那被讀出來。

CDN的工作原理

有了CDN和對象存儲之后，現在我們來看下他們之間是怎么工作的。

我們平時看到的圖片，可以右鍵復制查看它的URL。

會發現圖片的URL長這樣。https://cdn.xiaobaidebug.top/1667106197000.png

其中前面的cdn.xiaobaidebug.top就是CDN的域名，后面的1667106197000.png是圖片的路徑名。

當我們在瀏覽器輸入這個URL就會發起HTTP GET請求，然后經歷以下過程。

第一階段: 你的電腦會先通過DNS協議獲得cdn.xiaobaidebug.top 這個域名對應的IP。

• step1和step2：先查看瀏覽器緩存，再看操作系統里的/etc/hosts 緩存，如果都沒有，就會去詢問最近的DNS服務器（比如你房間里的家用路由器）。看看最近的DNS服務器上有沒有對應的緩存，如果有則返回。
• step3：如果最近的DNS服務器上沒有對應的緩存，就會去查詢根域，一級域，二級域，三級域服務器。
• step4：然后，最近的DNS服務器會得到這個cdn.xiaobaidebug.top 域名的別名（CNAME），比如cdn.xiaobaidebug.top.w.kunlunaq.com .
• kunlunaq.com是阿里CDN專用的DNS調度系統。
• step5到step7：此時最近的DNS服務器會去請求這個kunlunaq.com ，然后返回一個離你最近的IP地址返回給你。

第二階段: 對應上圖里的step8。瀏覽器拿著這個IP去訪問cdn節點，然后，cdn節點返回數據。

上面第一階段流程里，提到了很多新的名詞，比如CNAME，根域，一級域啥的，可以自行查閱資料了解一下.

我們知道DNS的目的就是通過域名去獲得IP地址。但這只是它的眾多功能之一。

DNS消息有很多種類型，其中A類型，就是用 域名 去查 域名對應的IP地址。而CNAME類型，則是用 域名 去查 這個域名的別名。

對于普通域名，DNS解析后一般就能直接得到域名對應的IP 地址（又叫A類型記錄，A指Address）。

比如下面，用dig命令發出DNS請求并打印過程數據。

$ dig +trace xiaobaidebug.top
;; ANSWER SECTION:
xiaobaidebug.top. 600 IN A 47.102.221.141

可以看到xiaobaidebug.top直接解析得到對應的IP地址47.102.221.141。

但對于cdn域名，一波查詢下來，先得到的卻是一條CNAME的記錄xx.kunlunaq.com，然后dig這個xx.kunlunaq.com才能得到對應的IP地址。

$ dig +trace cdn.xiaobaidebug.top
cdn.xiaobaidebug.top. 600 IN CNAME cdn.xiaobaidebug.top.w.kunlunaq.com.$ dig +trace cdn.xiaobaidebug.top.w.kunlunaq.com
cdn.xiaobaidebug.top.w.kunlunaq.com. 300 IN A 122.228.7.243
cdn.xiaobaidebug.top.w.kunlunaq.com. 300 IN A 122.228.7.241
cdn.xiaobaidebug.top.w.kunlunaq.com. 300 IN A 122.228.7.244
cdn.xiaobaidebug.top.w.kunlunaq.com. 300 IN A 122.228.7.249
cdn.xiaobaidebug.top.w.kunlunaq.com. 300 IN A 122.228.7.248
cdn.xiaobaidebug.top.w.kunlunaq.com. 300 IN A 122.228.7.242
cdn.xiaobaidebug.top.w.kunlunaq.com. 300 IN A 122.228.7.250
cdn.xiaobaidebug.top.w.kunlunaq.com. 300 IN A 122.228.7.251

看到這里，問題就又來了。

為什么要加個CNAME那么麻煩？

CNAME里指向的，其實是CDN專用的DNS域名服務器，它對整個DNS體系來說，只是其中一臺小小的DNS域名服務器，看起來就跟其他域名服務器一樣，平平無奇。DNS請求也會正常打入這個服務器里。

但當請求真正打到它上面的時候，它的特別之處就體現出來了，當查詢請求打入域名服務器時，普通的DNS域名服務器返回域名對應的部分IP就夠了，但CDN專用的DNS域名服務器卻會要求返回離調用方"最近的"服務器IP。

怎么知道哪個服務器IP里調用方最近？

可以看到"最近"這個詞其實是加了雙引號的。

CDN專用的DNS域名服務器其實是CDN提供商提供的，比如阿里云當然知道自己的的CDN節點有哪些，以及這些CDN服務器目前的負載情況和響應延時甚至權重啥的，并且也能知道調用方的IP地址是什么，可以通過調用方的IP知道它所屬的運營商以及大概所在地，根據條件篩選出最合適的CDN服務器，這就是所謂的"最近"。

舉個例子。假設地理位置最近的CDN機房流量較多，響應較慢，但地理位置遠一些的服務器卻能更好的響應當前請求，那按理說可能會選擇地理位置遠一些的那臺CDN服務器。

也就是說，選出來的服務器不一定在地理位置最近，但一定是當前最合適的服務器。

回源是什么

上面的圖片URL，是https://cdn域名/圖片地址.png的形式。也就是說這張圖片是訪問CDN拿到的。

那么，直接訪問對象存儲能不能拿到圖片數據并展示？比如像這樣。https://oss域名/圖片地址.png

這就像問，不走redis，直接從mysql中能不能讀取到文本數據并展示一樣。當然能。

但這樣成本更高，這里的成本，可以指性能成本，也可以指調用成本。看下面這個圖。

可以看到直接請求oss的費用差不多是通過cdn請求oss的兩倍，考慮到家境貧寒，同時也為了讓博客獲取圖片的速度更快，就接入了CDN。

但看到這里，問題又又來了。上面的截圖里，紅框里有個詞叫"回源"。

回源是什么？

當我們訪問https://cdn域名/圖片地址.png時，請求會打到cdn服務器上面。

但cdn服務器本質上就是一層緩存，并不是數據源，對象存儲才是數據源。

第一次訪問cdn獲取某張圖片時，大概率在cdn里并沒有這張圖片的數據，因此需要回到數據源那去取出這份圖片數據。然后再放到cdn上。下次再次訪問cdn時，只要緩存不過期，就能命中緩存直接返回，這就不需要再回源。

于是訪問的過程就變成了下面這樣。

那還有哪些情況會發生回源呢？

除了上面提到的cdn上拿不到數據會回源站外，還有cdn上的緩存過期失效了也會導致回源站。

另外，就算有緩存，且緩存不過期，也可以通過cdn提供的開放接口來觸發主動回源，但這個我們比較少機會能接觸到。

另外，回源這個事情，其實用戶是感知不到的，因為用戶去讀圖片的時候，只能知道自己讀到了還是讀不到。

同樣是讀到了，還細分為是從cdn那直接讀的，還是cdn回源讀對象存儲之后返回的。

那么，**我們有辦法判斷是否發生過回源嗎？**有。我們接著往下看。

怎么判斷是否發生回源

我們以某里云的對象存儲和CDN為例。

假設我要請求下面這張圖https://cdn.xiaobaidebug.top/image/image-20220404094549469.png

為了更方便的查看響應數據的http header，我們可以用上postman。

通過GET方法去請求圖片數據。

然后通過下面的tab切換查看response header信息。


此時查看response header下的X-Cache的值是MISS TCP_MISS。意思是未命中緩存導致CDN回源查oss，拿到數據后再返回。

那此時CDN里肯定是有這張圖片的緩存了。我們可以試著再執行一次 GET 方法獲取圖片。

X-Cache的值就變成了HIT TCP_MEM_HIT，這就是命中緩存了。

這個是某里云的做法，其他比如騰某云啥的，也都大差不差，幾乎都可以從response header里找到相關的信息。

用了CDN一定比不用的更快嗎？

看到這里我們就可以回答文章開頭的問題了。

如果沒有接入CDN，直接訪問源站，流程是這樣的。

但如果接入了CDN，且CDN上沒有緩存數據，那就會觸發回源。

相當于在原來的流程上還多了一層CDN的調用流程。

也就是，用了CDN時，未命中CDN緩存導致回源，就會比不用的時候更慢。

未命中緩存，可能是cdn里壓根就沒這一數據，也可能是曾經有這條數據但后來過期失效了。

這兩種情況都正常，大部分時候并不需要做任何處理。

但對于極個別場景，我們可能需要做些優化。比如你們源站數據有大版本更新，就像更換cdn域名啥的，那在上線的那一刻用戶全用新cdn域名去請求圖片啥的，新CDN節點基本上百分百觸發回源，嚴重的時候甚至可能會拖垮對象存儲。這時候你可能需要提前將熱點數據篩選出來，利用工具預先請求一波，讓CDN加載上熱數據緩存。比如某里云上的CDN就有這樣的"刷新預熱"功能。

當然也可以通過灰度發布的模式，先讓少量用戶體驗新功能，讓這些用戶把cdn"熱"起來，然后再逐步放開流量。

還有就是曾經有這條數據但后來過期失效了，對于熱點數據，可以適當提高一下cdn數據的緩存時間。

什么情況下不應該使用CDN？

從上面的描述看下來，CDN最大的優勢在于，對于來自世界各地的用戶，它可以就近分配CDN節點獲取數據，并且多次重復獲取同一個文件數據的時候，有緩存加速的作用。

這對于網頁圖片這樣的場景，是再合適不過了。因為底層用的是對象存儲，也就是說，只要是文件對象，比如視頻啥的，都可以用這套流程接入cdn做加速。比如平時刷的某音某手短視頻就是這么干的。

那反過來想想，問題就來了。

什么情況下不應該使用CDN？

如果你有一個公司內網的服務，并且服務請求的圖片等文件不太可能被多次重復調用，這時候其實沒必要使用CDN。

注意上面兩個加粗了的關鍵點。

• 內網服務，是為了保證你是了解服務的請求來源的，也能拿到對象存儲的讀權限，并且如果你的對象存儲也是公司內部的，那大概率跟你的服務已經在同一個機房里，這已經很近了。接入CDN也享受不到"就近分配CDN節點"所帶來的好處。
• 圖片或其他文件不太可能被多次重復使用，如果接入了CDN，那你每次去訪問CDN獲取圖片的時候，CDN節點上大概率沒有你要的數據，相當于每次都需要回源到對象存儲去取一把。那接入CDN相當于給自己加了一層代理，多一層代理，就多一層耗時。
  
  關于上面的第二點，如果你需要一個明確的指標去說服自己，那我可以給你一個。從上面的介紹內容，我們知道，可以通過cdn響應的http header中的X-Cache字段，看到一個請求是否觸發過回源，統計次數，再除以總的請求數，就能得到回源的比例，比如回源比例高達90%，那還接啥cdn。

總結

• 對于文本類數據我們習慣用mysql做存儲，redis做緩存。但屬于文件類數據，比如視頻圖片，則需要使用oss等做對象存儲，cdn做緩存
• 用了CDN如果發生回源，那實際上會比不用的時候更慢一些。
• CDN最大的優勢在于，對于來自世界各地的用戶，它可以就近分配CDN節點獲取數據，并且多次重復獲取同一個文件數據的時候，有緩存加速的作用。如果你的服務和對象存儲都在內網，并且文件數據也不太會有重復使用的可能性，那其實沒必要接入cdn。

參考

侵刪
來自微信公眾號: 小白debug