對(duì)于開發(fā)同來說，CDN 這個(gè)詞，既熟悉又陌生平時(shí)搞開發(fā)時(shí)候很少需碰這個(gè)，但總能聽到別提起。我們聽說過它能速，也大概道個(gè)原因，是往深了問用了 CDN 就一定比不用更快嗎？感覺有些懵。但沒關(guān)系今天我們換角度重新認(rèn)下 CDN。CDN 是什么對(duì)于數(shù)字文本類型的據(jù)，比方說字和電話號(hào)相關(guān)的信息我們需要有地方存起來我們通常會(huì) mysql 數(shù)據(jù)庫(kù)去存。文本存在 mysql 中當(dāng)我們需重新將這一據(jù)取出的時(shí)，就需要去 mysql 數(shù)據(jù)庫(kù)。但因?yàn)?mysql 的數(shù)據(jù)是存在磁盤的，單臺(tái)實(shí)，讀性能到不多 5kqps 就已經(jīng)很不錯(cuò)了。起來還湊合但對(duì)于稍微一點(diǎn)的系統(tǒng)就稍微有點(diǎn)急了。為了升點(diǎn)性能，們?cè)?mysql 之前再加一層內(nèi)存緩存層，比常說的 redis，讀數(shù)據(jù)優(yōu)先到內(nèi)里讀，讀不才到 mysql 里讀，大大減少了 mysql 的次數(shù)。有了這套組合，讀性能輕上萬 qps。mysql 和 redis好了，到這里，我們的都是我們時(shí)比較容易觸的開發(fā)場(chǎng)。但如果現(xiàn)我要處理的不再是上面到的文本類據(jù)，而是圖數(shù)據(jù)。比如我有一張帥的照片。就面這張。每刷某音聽到人翻唱蔡健的《letting go》的時(shí)候，都忍不住想這張圖。并文 "還是忘不了"。那么問題來了。張圖片數(shù)據(jù)該存在哪？又該從哪里？我們回過去看 mysql 和 redis 的場(chǎng)景，無非是存儲(chǔ)層加存層。存儲(chǔ)和緩存層對(duì)圖片這樣的件對(duì)象，存層不太可能用 mysql，應(yīng)該改用專業(yè)的對(duì)象儲(chǔ)，比如亞遜的 S3（Amazon Simple Storage Service，注意后面是個(gè) S 開頭的單詞，所叫 s3），或者阿里云 oss（Object Storage Service）。下面的內(nèi)容，們就用比較見的 oss 去做解釋。而緩存層，不能繼續(xù)用 redis 了，需要改使用 CDN（Content?Delivery?Network，內(nèi)容分發(fā)網(wǎng)絡(luò)）。可將 CDN 簡(jiǎn)單理解為象存儲(chǔ)對(duì)應(yīng)緩存層。CDN 和 OSS現(xiàn)在就可以回答上面的問，對(duì)用戶說，這張圖數(shù)據(jù)存在了象存儲(chǔ)那，有需要的時(shí)，會(huì)從 CDN 那被讀出來。CDN 的工作原理了 CDN 和對(duì)象存儲(chǔ)后，現(xiàn)在我來看下他們間是怎么工的。我們平看到的圖片可以右鍵復(fù)查看它的 URL。1667103075060會(huì)發(fā)現(xiàn)圖片的 URL 長(zhǎng)這樣。https://cdn.xiaobaidebug.top/1667106197000.png其中前面的 cdn.xiaobaidebug.top 就是 CDN 的域名，后面的 1667106197000.png 是圖片的路徑。當(dāng)我們?cè)?覽器輸入這 URL 就會(huì)發(fā)起 HTTP GET 請(qǐng)求，然后經(jīng)歷以下過。CDN 的查詢流程第階段: 你的電腦會(huì)先通 DNS 協(xié)議獲得 cdn.xiaobaidebug.top 這個(gè)域名對(duì)應(yīng)的 IP。?step1 和 step2：先查看瀏覽器緩存再看操作系里的 / etc / hosts 緩存，如果都有，就會(huì)去問最近的 DNS 服務(wù)器（比如你房里的家用路器）。最近 DNS 服務(wù)器上有沒對(duì)應(yīng)的緩存如果有則返。?step3：如果最近的 DNS 服務(wù)器上沒對(duì)應(yīng)的緩存就會(huì)去查詢域，一級(jí)域二級(jí)域，三域服務(wù)器。step4：然后，最近 DNS 服務(wù)器會(huì)得到個(gè) cdn.xiaobaidebug.top 域名的別名（CNAME），比如 cdn.xiaobaidebug.top.w.kunlunaq.com。??kunlunaq.com 是阿里 CDN 專用的 DNS 調(diào)度系統(tǒng)。?step5 到 step7：此時(shí)最近的 DNS 服務(wù)器會(huì)去請(qǐng)求個(gè) kunlunaq.com，然后返回一個(gè)離你近的 IP 地址返回給。第二階段: 對(duì)應(yīng)上圖里的 step8。瀏覽器拿著這個(gè) IP 去訪問 cdn 節(jié)點(diǎn)，然后，cdn 節(jié)點(diǎn)返回?cái)?shù)據(jù)。上面第階段流程里提到了很多的名詞，比 CNAME，根域，一域啥的，它在之前寫的 「DNS 中有哪些值得習(xí)的優(yōu)秀設(shè)」有很詳細(xì)描述，如果了解的話可去看下。我知道 DNS 的目的就是通過域名去得 IP 地址。但這只它的眾多功之一。DNS 消息有很多種類型，其 A 類型，就是用域名查域名對(duì)應(yīng) IP 地址。而 CNAME 類型，則是用域名查這個(gè)域名別名。對(duì)于通域名，DNS 解析后一般就能直接到域名對(duì)應(yīng) IP 地址（又叫 A 類型記錄，A 指 Address）。比如下面，用 dig 命令發(fā)出 DNS 請(qǐng)求并打印過程數(shù)。$?dig?+trace?xiaobaidebug.top;;?ANSWER?SECTION:xiaobaidebug.top.?600?IN?A?47.102.221.141可以看到 xiaobaidebug.top 直接解析得到對(duì)應(yīng) IP 地址 47.102.221.141。但對(duì)于 cdn 域名，一波詢下來，先到的卻是一 CNAME 的記錄 xx.kunlunaq.com，然后 dig 這個(gè) xx.kunlunaq.com 才能得到對(duì)應(yīng) IP 地址。$?dig?+trace?cdn.xiaobaidebug.topcdn.xiaobaidebug.top.?600?IN?CNAME?cdn.xiaobaidebug.top.w.kunlunaq.com.$?dig?+trace?cdn.xiaobaidebug.top.w.kunlunaq.comcdn.xiaobaidebug.top.w.kunlunaq.com.?300?IN?A?122.228.7.243cdn.xiaobaidebug.top.w.kunlunaq.com.?300?IN?A?122.228.7.241cdn.xiaobaidebug.top.w.kunlunaq.com.?300?IN?A?122.228.7.244cdn.xiaobaidebug.top.w.kunlunaq.com.?300?IN?A?122.228.7.249cdn.xiaobaidebug.top.w.kunlunaq.com.?300?IN?A?122.228.7.248cdn.xiaobaidebug.top.w.kunlunaq.com.?300?IN?A?122.228.7.242cdn.xiaobaidebug.top.w.kunlunaq.com.?300?IN?A?122.228.7.250cdn.xiaobaidebug.top.w.kunlunaq.com.?300?IN?A?122.228.7.251看到這里，問題就又來。為什么要個(gè) CNAME 那么麻煩？CNAME 里指向的，其實(shí)是 CDN 專用的 DNS 域名服務(wù)器，它整個(gè) DNS 體系來說，只是其中一小小的 DNS 域名服務(wù)器，看起來跟其他域名務(wù)器一樣，平無奇。DNS 請(qǐng)求也會(huì)正常打入這服務(wù)器里。當(dāng)請(qǐng)求真正到它上面的候，它的特之處就體現(xiàn)來了，當(dāng)查請(qǐng)求打入域服務(wù)器時(shí)，通的 DNS 域名服務(wù)器返回域名對(duì)的部分 IP 就夠了，但 CDN 專用的 DNS 域名服務(wù)器卻會(huì)要求返離調(diào)用方 " 最近的 " 服務(wù)器 IP。CDN 專用的 DNS 解析服務(wù)器會(huì)返回就的 CDN 節(jié)點(diǎn) IP怎么知道哪個(gè)務(wù)器 IP 里調(diào)用方最？可以看到 "最近" 這個(gè)詞其實(shí)是了雙引號(hào)的CDN 專用的 DNS 域名服務(wù)器實(shí)是 CDN 提供商提供的，比如阿云當(dāng)然知道己的的 CDN 節(jié)點(diǎn)有哪些，以及這 CDN 服務(wù)器目前的載情況和響延時(shí)甚至權(quán)啥的，并且能知道調(diào)用的 IP 地址是什么，以通過調(diào)用的 IP 知道它所屬的營(yíng)商以及大所在地，根條件篩選出合適的 CDN 服務(wù)器，這就是所謂 " 最近 "。舉個(gè)例子。假設(shè)地理置最近的 CDN 機(jī)房流量較多，響較慢，但地位置遠(yuǎn)一些服務(wù)器卻能好的響應(yīng)當(dāng)請(qǐng)求，那按說可能會(huì)選地理位置遠(yuǎn)些的那臺(tái) CDN 服務(wù)器。也就是說選出來的服器不一定在理位置最近但一定是當(dāng)最合適的服器。回源是么上面的圖 URL，是 https://cdn 域名 / 圖片地址.png 的形式。也就是說張圖片是訪 CDN 拿到的。那么直接訪問對(duì)存儲(chǔ)能不能到圖片數(shù)據(jù)展示？比如下面這樣。https://oss域名/圖片地址png這就像問，不走 redis，直接從 mysql 中能不能讀取到文本據(jù)并展示一。當(dāng)然能。之前放在博里的圖片就這么干的。這樣成本更，這里的成，可以指性成本，也可指調(diào)用成本看下下面這圖。1667101182393可以看到直接請(qǐng)求 oss 的費(fèi)用差不多是過 cdn 請(qǐng)求 oss 的兩倍，考慮到家境貧，同時(shí)也為讓博客獲取片的速度更，我就接入 CDN。但看到這里，題又又來了上面的截圖，紅框里有詞叫 " 回源 "?；卦词鞘裁?？當(dāng)們?cè)L問 https://cdn 域名 / 圖片地址.png 時(shí)，請(qǐng)求會(huì)到 cdn 服務(wù)器上面但 cdn 服務(wù)器本質(zhì)就是一層緩，并不是數(shù)源，對(duì)象存才是數(shù)據(jù)源第一次訪問 cdn 獲取某張圖片時(shí)大概率在 cdn 里并沒有這張圖片數(shù)據(jù)，因此要回到數(shù)據(jù)那去取出這圖片數(shù)據(jù)。后再放到 cdn 上。下次再次訪問 cdn 時(shí)，只要緩存不期，就能命緩存直接返，這就不需再回源。于訪問的過程變成了下面樣。1668605964836那還有哪些情況會(huì)生回源呢？了上面提到 cdn 上拿不到數(shù)據(jù)回源站外，有 cdn 上的緩存過失效了也會(huì)致回源站。外，就算有存，且緩存過期，也可通過 cdn 提供的開放接口來觸發(fā)動(dòng)回源，但個(gè)我們比較機(jī)會(huì)能接觸。另外，回這個(gè)事情，實(shí)用戶是感不到的，因用戶去讀圖的時(shí)候，只知道自己讀了還是讀不。同樣是讀了，還細(xì)分是從 cdn 那直接讀的，還是 cdn 回源讀對(duì)象存儲(chǔ)之后回的。有緩直接返回和緩存回源的別那么，我有辦法判斷否發(fā)生過回嗎？有。我接著往下看怎么判斷是發(fā)生回源我以某里云的象存儲(chǔ)和 CDN 為例。假設(shè)我要請(qǐng)下面這張圖 https://cdn.xiaobaidebug.top/ image / image-20220404094549469.png為了更方便的看響應(yīng)數(shù)據(jù) http header，我們可以上 postman。通過 GET 方法去請(qǐng)求圖數(shù)據(jù)。然后過下面的 tab 切換查看 response header 信息。查看 response header回源的情況此時(shí)查 response header 下的 X-Cache 的值是?MISS TCP_MISS。意思是未命中緩導(dǎo)致 CDN 回源查 oss，拿到數(shù)據(jù)后再返回那此時(shí) CDN 里肯定是有這張圖片緩存了。我可以試著再行一次 GET 方法獲取圖片。1667095186020X-Cache 的值就變成?HIT TCP_MEM_HIT，這就是命中緩了。這個(gè)是里云的做法其他比如騰云啥的，也大差不差，乎都可以從 response header 里找到相關(guān)的信。用了 CDN 一定比不用的更快嗎看到這里我就可以回答章開頭的問了。如果沒接入 CDN，直接訪問站，流程是樣的。更新接訪問源站如果接入了 CDN，且 CDN 上沒有緩存數(shù)據(jù)那就會(huì)觸發(fā)源。更新走 CDN 還回源相當(dāng)于原來的流程還多了一層 CDN 的調(diào)用流程。也是，用了 CDN 時(shí)，未命中 CDN 緩存導(dǎo)致回源，就會(huì)比用的時(shí)候更。未命中緩，可能是 cdn 里壓根就沒這一數(shù)，也可能是經(jīng)有這條數(shù)但后來過期效了。這兩情況都正常大部分時(shí)候不需要做任處理。但對(duì)極個(gè)別場(chǎng)景我們可能需做些優(yōu)化。如你們?cè)凑?據(jù)有大版本新，就像更 cdn 域名啥的，那上線的那一用戶全用新 cdn 域名去請(qǐng)求圖片的，新 CDN 節(jié)點(diǎn)基本上百分百觸回源，嚴(yán)重時(shí)候甚至可會(huì)拖垮對(duì)象儲(chǔ)。這時(shí)候可能需要提將熱點(diǎn)數(shù)據(jù)選出來，利工具預(yù)先請(qǐng)一波，讓 CDN 加載上熱數(shù)據(jù)緩存比如某里云的 CDN 就有這樣的 " 刷新預(yù)熱 " 功能。cdn 刷新預(yù)熱當(dāng)然也以通過灰度布的模式，讓少量用戶驗(yàn)新功能，這些用戶把 cdn"熱" 起來，然后再逐步放開量。還有就曾經(jīng)有這條據(jù)但后來過失效了，對(duì)熱點(diǎn)數(shù)據(jù)，以適當(dāng)提高下 cdn 數(shù)據(jù)的緩存間。1667344813600什么情況下不應(yīng)該用 CDN？從上面的描看下來，CDN 最大的優(yōu)勢(shì)在于，對(duì)來自世界各的用戶，它以就近分配 CDN 節(jié)點(diǎn)獲取數(shù)據(jù)，且多次重復(fù)取同一個(gè)文數(shù)據(jù)的時(shí)候有緩存加速作用。這對(duì)網(wǎng)頁(yè)圖片這的場(chǎng)景，是合適不過了因?yàn)榈讓佑?是對(duì)象存儲(chǔ)也就是說，要是文件對(duì)，比如視頻的，都可以這套流程接 cdn 做加速。比如時(shí)刷的某音手短視頻就這么干的。反過來想想問題就來了什么情況下應(yīng)該使用 CDN？如果你有一個(gè)公司網(wǎng)的服務(wù)，且服務(wù)請(qǐng)求圖片等文件太可能被多重復(fù)調(diào)用，時(shí)候其實(shí)沒要使用 CDN。注意上面兩個(gè)加粗了關(guān)鍵點(diǎn)。?內(nèi)網(wǎng)服務(wù)，為了保證你了解服務(wù)的求來源的，能拿到對(duì)象儲(chǔ)的讀權(quán)限并且如果你對(duì)象存儲(chǔ)也公司內(nèi)部的那大概率跟的服務(wù)已經(jīng)同一個(gè)機(jī)房，這已經(jīng)很了。接入 CDN 也享受不到 "就近分配 CDN 節(jié)點(diǎn)" 所帶來的好處??圖片或他文件不太能被多次重使用，如果入了 CDN，那你每次訪問 CDN 獲取圖片的鮆魚候，CDN 節(jié)點(diǎn)上大概柢山?jīng)]有你要數(shù)據(jù)，相當(dāng)每次都需要源到對(duì)象存去取一把。接入 CDN 相當(dāng)于給自隋書加了一層理，多一層理，就多一耗時(shí)。1668612494972關(guān)于上面的第二，如果你需一個(gè)明確的標(biāo)去說服自，那我可以你一個(gè)。從面的介紹內(nèi)，我們知道可以通過 cdn 響應(yīng)的 http header 中的 X-Cache 字段，看到個(gè)請(qǐng)求是否發(fā)過回源，計(jì)次數(shù)，再以總的請(qǐng)求，就能得到源的比例，如回源比例達(dá) 90%，那還接啥 cdn?？偨Y(jié)??對(duì)于文本數(shù)據(jù)我們習(xí)用 mysql 做存儲(chǔ)，redis 做緩存。但于文件類數(shù)，比如視頻片，則需要用 oss 等做對(duì)象存，cdn 做緩存。??了 CDN 如果發(fā)生回，那實(shí)際上比不用的時(shí)更慢一些。?CDN 最大的優(yōu)勢(shì)在，對(duì)于來自界各地的用，它可以就分配 CDN 節(jié)點(diǎn)獲取數(shù)節(jié)并，并且多重復(fù)獲取同個(gè)文件數(shù)據(jù)時(shí)候，有緩加速的作用如果你的服和對(duì)象存儲(chǔ)在內(nèi)網(wǎng)，并文件數(shù)據(jù)也太會(huì)有重復(fù)用的可能性那其實(shí)沒必接入 cdn。本文來自信公眾號(hào)：白 debug （ID：xiaobaidebug），作者：?