在线乱码卡一卡二卡新HD,最近韩国免费观看视频,国产色无码精品视频国产,亚洲男人的天堂久久香蕉

?對(duì)于開發(fā)同學(xué)來說，CDN這個(gè)詞，既熟悉又陌生。

【資料圖】

平時(shí)搞開發(fā)的時(shí)候很少需要碰這個(gè)，但卻總能聽到別人提起。

我們都聽說過它能加速，也大概知道個(gè)原因，但是往深了問。

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

就感覺有些懵了。但沒關(guān)系，今天我們換個(gè)角度重新認(rèn)識(shí)下CDN。

CDN是什么

對(duì)于數(shù)字和文本類型的數(shù)據(jù)，比方說名字和電話號(hào)碼相關(guān)的信息。我們需要有個(gè)地方存起來。

我們通常會(huì)用mysql數(shù)據(jù)庫去存。

文本存在mysql中

當(dāng)我們需要重新將這一數(shù)據(jù)取出的時(shí)候，就需要去讀mysql數(shù)據(jù)庫。

但因?yàn)閙ysql的數(shù)據(jù)是存在磁盤上的，單臺(tái)實(shí)例，讀性能到差不多5kqps就已經(jīng)很不錯(cuò)了。

看起來還湊合，但對(duì)于稍微大一點(diǎn)的系統(tǒng)，就稍微有點(diǎn)捉急了。

為了提升點(diǎn)性能，我們?cè)趍ysql之前再加一層內(nèi)存做緩存層，比如常說的redis，讀數(shù)據(jù)優(yōu)先到內(nèi)存里讀，讀不到才到mysql里讀，大大減少了讀mysql的次數(shù)。有了這套組合拳，讀性能輕松上萬qps。

mysql和redis

好了，到這里，我們說的都是我們平時(shí)比較容易接觸的開發(fā)場(chǎng)景。

但如果現(xiàn)在我要處理的，不再是上面提到的文本類數(shù)據(jù)，而是圖片數(shù)據(jù)。

比如，我有一張帥氣的照片。就下面這張。

每次刷某音聽到有人翻唱蔡健雅的《letting go》的時(shí)候，我都忍不住想發(fā)這張圖。

并配文"還是忘不了"。

那么問題來了。

這張圖片數(shù)據(jù)應(yīng)該存在哪？，又該從哪里讀？

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

存儲(chǔ)層和緩存層

對(duì)于圖片這樣的文件對(duì)象，存儲(chǔ)層不太可能再用mysql，應(yīng)該改用專業(yè)的對(duì)象存儲(chǔ)，比如亞馬遜的S3（Amazon Simple Storage Service，注意后面是三個(gè)S開頭的單詞，所以叫s3），或者阿里云的oss（Object Storage Service）。下面的內(nèi)容，我們就用比較常見的oss去做解釋。

而緩存層，也不能繼續(xù)用redis了，需要改成使用CDN（ContentDeliveryNetwork，內(nèi)容分發(fā)網(wǎng)絡(luò)）。

可以將CDN簡(jiǎn)單理解為對(duì)象存儲(chǔ)對(duì)應(yīng)的緩存層。

CDN和OSS

現(xiàn)在就可以回答上面的提問，對(duì)用戶來說，這張圖片數(shù)據(jù)存在了對(duì)象存儲(chǔ)那，當(dāng)有需要的時(shí)候，會(huì)從CDN那被讀出來。

CDN的工作原理

有了CDN和對(duì)象存儲(chǔ)之后，現(xiàn)在我們來看下他們之間是怎么工作的。

我們平時(shí)看到的圖片，可以右鍵復(fù)制查看它的URL。

會(huì)發(fā)現(xiàn)圖片的URL長(zhǎng)這樣。

https://cdn.xiaobaidebug.top/1667106197000.png

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

當(dāng)我們?cè)跒g覽器輸入這個(gè)URL就會(huì)發(fā)起HTTP GET請(qǐng)求，然后經(jīng)歷以下過程。

CDN的查詢流程

第一階段: 你的電腦會(huì)先通過DNS協(xié)議獲得cdn.xiaobaidebug.top這個(gè)域名對(duì)應(yīng)的IP。

? step1和step2：先查看瀏覽器緩存，再看操作系統(tǒng)里的/etc/hosts緩存，如果都沒有，就會(huì)去詢問最近的DNS服務(wù)器（比如你房間里的家用路由器）。最近的DNS服務(wù)器上有沒有對(duì)應(yīng)的緩存，如果有則返回。

? step3：如果最近的DNS服務(wù)器上沒有對(duì)應(yīng)的緩存，就會(huì)去查詢根域，一級(jí)域，二級(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，根域，一級(jí)域啥的，它們?cè)谥皩懙?「DNS中有哪些值得學(xué)習(xí)的優(yōu)秀設(shè)計(jì)」有很詳細(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ù)據(jù)。

$ 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ù)器，它對(duì)整個(gè)DNS體系來說，只是其中一臺(tái)小小的DNS域名服務(wù)器，看起來就跟其他域名服務(wù)器一樣，平平無奇。DNS請(qǐng)求也會(huì)正常打入這個(gè)服務(wù)器里。

但當(dāng)請(qǐng)求真正打到它上面的時(shí)候，它的特別之處就體現(xiàn)出來了，當(dāng)查詢請(qǐng)求打入域名服務(wù)器時(shí)，普通的DNS域名服務(wù)器返回域名對(duì)應(yīng)的部分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ù)器目前的負(fù)載情況和響應(yīng)延時(shí)甚至權(quán)重啥的，并且也能知道調(diào)用方的IP地址是什么，可以通過調(diào)用方的IP知道它所屬的運(yùn)營商以及大概所在地，根據(jù)條件篩選出最合適的CDN服務(wù)器，這就是所謂的"最近"。

舉個(gè)例子。假設(shè)地理位置最近的CDN機(jī)房流量較多，響應(yīng)較慢，但地理位置遠(yuǎn)一些的服務(wù)器卻能更好的響應(yīng)當(dāng)前請(qǐng)求，那按理說可能會(huì)選擇地理位置遠(yuǎn)一些的那臺(tái)CDN服務(wù)器。

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

回源是什么

上面的圖片URL，是https://cdn域名/圖片地址.png的形式。

也就是說這張圖片是訪問CDN拿到的。

那么，直接訪問對(duì)象存儲(chǔ)能不能拿到圖片數(shù)據(jù)并展示？

比如像下面這樣。

https://oss域名/圖片地址.png

這就像問，不走redis，直接從mysql中能不能讀取到文本數(shù)據(jù)并展示一樣。

當(dāng)然能。

我之前放在博客里的圖片就是這么干的。

但這樣成本更高，這里的成本，可以指性能成本，也可以指調(diào)用成本?？聪孪旅孢@個(gè)圖。

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

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

上面的截圖里，紅框里有個(gè)詞叫"回源"。

回源是什么？

當(dāng)我們?cè)L問https://cdn域名/圖片地址.png時(shí)，請(qǐng)求會(huì)打到cdn服務(wù)器上面。

但cdn服務(wù)器本質(zhì)上就是一層緩存，并不是數(shù)據(jù)源，對(duì)象存儲(chǔ)才是數(shù)據(jù)源。

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

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

那還有哪些情況會(huì)發(fā)生回源呢？

除了上面提到的cdn上拿不到數(shù)據(jù)會(huì)回源站外，還有cdn上的緩存過期失效了也會(huì)導(dǎo)致回源站。

另外，就算有緩存，且緩存不過期，也可以通過cdn提供的開放接口來觸發(fā)主動(dòng)回源，但這個(gè)我們比較少機(jī)會(huì)能接觸到。

另外，回源這個(gè)事情，其實(shí)用戶是感知不到的，因?yàn)橛脩羧プx圖片的時(shí)候，只能知道自己讀到了還是讀不到。

同樣是讀到了，還細(xì)分為是從cdn那直接讀的，還是cdn回源讀對(duì)象存儲(chǔ)之后返回的。

有緩存直接返回和沒緩存回源的區(qū)別

那么，我們有辦法判斷是否發(fā)生過回源嗎？

有。我們接著往下看。

怎么判斷是否發(fā)生回源

我們以某里云的對(duì)象存儲(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里肯定是有這張圖片的緩存了。我們可以試著再執(zhí)行一次 GET 方法獲取圖片。

X-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ù)，也可能是曾經(jīng)有這條數(shù)據(jù)但后來過期失效了。

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

但對(duì)于極個(gè)別場(chǎng)景，我們可能需要做些優(yōu)化。比如你們?cè)凑緮?shù)據(jù)有大版本更新，就像更換cdn域名啥的，那在上線的那一刻用戶全用新cdn域名去請(qǐng)求圖片啥的，新CDN節(jié)點(diǎn)基本上百分百觸發(fā)回源，嚴(yán)重的時(shí)候甚至可能會(huì)拖垮對(duì)象存儲(chǔ)。這時(shí)候你可能需要提前將熱點(diǎn)數(shù)據(jù)篩選出來，利用工具預(yù)先請(qǐng)求一波，讓CDN加載上熱數(shù)據(jù)緩存。比如某里云上的CDN就有這樣的"刷新預(yù)熱"功能。

cdn刷新預(yù)熱

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

還有就是曾經(jīng)有這條數(shù)據(jù)但后來過期失效了，對(duì)于熱點(diǎn)數(shù)據(jù)，可以適當(dāng)提高一下cdn數(shù)據(jù)的緩存時(shí)間。

什么情況下不應(yīng)該使用CDN？

從上面的描述看下來，CDN最大的優(yōu)勢(shì)在于，對(duì)于來自世界各地的用戶，它可以就近分配CDN節(jié)點(diǎn)獲取數(shù)據(jù)，并且多次重復(fù)獲取同一個(gè)文件數(shù)據(jù)的時(shí)候，有緩存加速的作用。

這對(duì)于網(wǎng)頁圖片這樣的場(chǎng)景，是再合適不過了。因?yàn)榈讓佑玫氖菍?duì)象存儲(chǔ)，也就是說，只要是文件對(duì)象，比如視頻啥的，都可以用這套流程接入cdn做加速。比如平時(shí)刷的某音某手短視頻就是這么干的。

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

什么情況下不應(yīng)該使用CDN？

如果你有一個(gè)公司內(nèi)網(wǎng)的服務(wù)，并且服務(wù)請(qǐng)求的圖片等文件不太可能被多次重復(fù)調(diào)用，這時(shí)候其實(shí)沒必要使用CDN。

注意上面兩個(gè)加粗了的關(guān)鍵點(diǎn)。

內(nèi)網(wǎng)服務(wù)，是為了保證你是了解服務(wù)的請(qǐng)求來源的，也能拿到對(duì)象存儲(chǔ)的讀權(quán)限，并且如果你的對(duì)象存儲(chǔ)也是公司內(nèi)部的，那大概率跟你的服務(wù)已經(jīng)在同一個(gè)機(jī)房里，這已經(jīng)很近了。接入CDN也享受不到"就近分配CDN節(jié)點(diǎn)"所帶來的好處。圖片或其他文件不太可能被多次重復(fù)使用，如果接入了CDN，那你每次去訪問CDN獲取圖片的時(shí)候，CDN節(jié)點(diǎn)上大概率沒有你要的數(shù)據(jù)，相當(dāng)于每次都需要回源到對(duì)象存儲(chǔ)去取一把。那接入CDN相當(dāng)于給自己加了一層代理，多一層代理，就多一層耗時(shí)。

關(guān)于上面的第二點(diǎn)，如果你需要一個(gè)明確的指標(biāo)去說服自己，那我可以給你一個(gè)。從上面的介紹內(nèi)容，我們知道，可以通過cdn響應(yīng)的http header中的X-Cache字段，看到一個(gè)請(qǐng)求是否觸發(fā)過回源，統(tǒng)計(jì)次數(shù)，再除以總的請(qǐng)求數(shù)，就能得到回源的比例，比如回源比例高達(dá)90%，那還接啥cdn。

總結(jié)對(duì)于文本類數(shù)據(jù)我們習(xí)慣用mysql做存儲(chǔ)，redis做緩存。但屬于文件類數(shù)據(jù)，比如視頻圖片，則需要使用oss等做對(duì)象存儲(chǔ)，cdn做緩存。用了CDN如果發(fā)生回源，那實(shí)際上會(huì)比不用的時(shí)候更慢一些。CDN最大的優(yōu)勢(shì)在于，對(duì)于來自世界各地的用戶，它可以就近分配CDN節(jié)點(diǎn)獲取數(shù)據(jù)，并且多次重復(fù)獲取同一個(gè)文件數(shù)據(jù)的時(shí)候，有緩存加速的作用。如果你的服務(wù)和對(duì)象存儲(chǔ)都在內(nèi)網(wǎng)，并且文件數(shù)據(jù)也不太會(huì)有重復(fù)使用的可能性，那其實(shí)沒必要接入cdn。

關(guān)鍵詞： 域名服務(wù)器 圖片數(shù)據(jù) 地理位置 就近分配 也就是說