国产成人毛片毛片久久网_国产午夜激无码av毛片不_国产乱对白精彩在线播放_av资源站中文字幕_亚洲男人的天堂网站_国产成 人 综合 亚洲网_中国国产激情一区_少妇一级淫片免费放_亚洲一本大道av久在线播放_免费观看美女裸体网站

我們講到了為何引入緩存且應(yīng)該什么時候引入，并且講到了我們生產(chǎn)中緩存的讀寫策略是什么，忘記了的可以自行去文章列表看下，同時又單獨深入講解了redis哨兵機制(Redis 哨兵機制以及底層原理深入解析，這次終于搞清楚了)和緩存穿透問題的解決方案(緩存穿透問題，開發(fā)中真實解決方案)。至此，我們現(xiàn)在的系統(tǒng)架構(gòu)已經(jīng)是這樣子的了

于架構(gòu)圖我們可以看出，我們現(xiàn)在使用了分布式緩存來加速動態(tài)請求的各種數(shù)據(jù)，但是，我們的系統(tǒng)中其實還有很多的靜態(tài)資源的，并且請求量也是超級大的。例如：

移動端App，有很多的圖片，小視頻以及流媒體等。 對于網(wǎng)站來說，不僅有上面那些資源之外，還有大量的HTML 文件，css文件以及java script文件等。

現(xiàn)在我們的一個商城里面，有很多的商品圖片，并且詳情頁還有產(chǎn)品介紹視頻，目前這些靜態(tài)資源均是放在Nginx服務(wù)器上的，請求量很大，并且這些文件對于訪問速度要求極高，并且占據(jù)很高的帶寬。這里就會很有可能出現(xiàn)訪問速度變慢，將帶寬占滿從而影響我們后端動態(tài)請求。這個時候我們就需要考慮該怎么去對這些靜態(tài)資源做加速了。

如何思考加速

首先我們想一下可不可以也用分布式緩存來存儲達到加速的目的呢?答案肯定是不行的，因為：

圖片或者視頻文件大小都不小，在幾兆到幾百兆之間。 我們的用戶是遍地全國各地的甚至還有國外用戶，需要讓用戶能很快的得到相應(yīng)，即就近訪問，我們不能全國各地都建機房去部署緩存，不現(xiàn)實。 圖片或視頻信息文件很大，訪問量又極高，這樣，如果自建機房帶寬肯定是會面臨極大的風(fēng)險。

因此，我們不能自建機房來加速靜態(tài)資源，我們需要在我們的應(yīng)用服務(wù)器外層加一層靜態(tài)資源處理的組件，并且還能遍地全國各地讓用戶能就近訪問，還能讓這些緩存命中率很高，以至于盡量減少回源到我們自己的業(yè)務(wù)服務(wù)器，這種技術(shù)就是我們下面要說的CDN。

CDN核心技術(shù)

CDN 其實就是網(wǎng)絡(luò)分發(fā)的一種技術(shù)，它將我們的靜態(tài)資源分發(fā)到各個地理位置不同的機房服務(wù)器上，這樣就能實現(xiàn)用戶就近訪問的問題，且加快靜態(tài)資源的訪問速度。

你可能會說，cdn這玩意我們開發(fā)又用不到，不用去掌握的吧，其實不然，建議你不要只是將自己一直放在只是開發(fā)的位置，你要有掌控全局的決心，很多cdn排查的工作都是需要資深工程師才能干的，所以你要了解這門技術(shù)，現(xiàn)在假如讓你來配置cdn和排查CDN問題，你可能就會因為自身技術(shù)壁壘而感到束手無策。

首先，我們來看看搭建一個CDN系統(tǒng)需要考慮的兩個關(guān)鍵點：

怎樣才能讓用戶請求先映射到CDN服務(wù)器上，這應(yīng)該是最基本的了。 怎樣根據(jù)用戶所處的地理位置，選出離他最近的CDN節(jié)點給用戶訪問。

接下來，我們就基于上面考慮點來一起來看看CDN技術(shù)是怎么實現(xiàn)靜態(tài)資源的加速。

如何將用戶請求落到CDN服務(wù)器上

12306網(wǎng)站我們應(yīng)該都不陌生，它是有很多的cdn節(jié)點來讓我們就近訪問提供靜態(tài)資源加速的，而我們輸入的網(wǎng)址就是12306自己家的網(wǎng)址，并不是cdn的ip。這是為什么呢?因為如果直接提供給用戶cdn 節(jié)點IP的話，如果IP改變怎么辦，那所有的靜態(tài)資源都得改變地址，這種是很不靠譜的，所以都是直接給我們服務(wù)的自己家域名，然后隱藏住CDN 的IP，那這種機制該怎么做呢?其實大家應(yīng)該能猜得到，就是運用DNS進行域名映射。

DNS(Domain Name System)就是一個存儲域名和 IP 映射的分布式數(shù)據(jù)庫，其中域名解析返回的結(jié)果有兩種：

直接返回域名對應(yīng)的 IP 地址。 返回另一個域名，即將當(dāng)前域名解析到另一個域名，會跳轉(zhuǎn)到另一個域名解析上，現(xiàn)在我們就是通過這種方式來解決上面域名映射問題

下面我們就來看看具體的是怎么操作的。

假設(shè)我們的一級域名為 a.com ，那么我們就可以將圖片服務(wù)域名定義為“img.a.com”，然后將這個域名的解析結(jié)果配置到CDN提供的域名上。例如，ucoud提供一個這樣的域名“78f98.cdn.ucloud.com.cn”，我們的系統(tǒng)圖片地址是這個樣子"img.a.com/100.jpg"。

用戶在請求100.jpg 地址的時候，DNS服務(wù)器就會將這個域名解析到78f98.cdn.ucloud.com.cn 域名上，然后再將這個域名解析到CDN的IP地址，這樣就得到了CDN上資源數(shù)據(jù)了。

我們知道其實DNS解析是有個問題的就是，因為域名解析過程是分好幾個級別的，每一級有專門的域名服務(wù)器承擔(dān)其解析的職責(zé)，所以，域名的解析過程有可能需要跨越公網(wǎng)做多次 DNS 查詢，在性能上是比較差的。

經(jīng)過了向多個 DNS 服務(wù)器做查詢之后，整個 DNS 的解析的時間有可能會到秒級別，那我們應(yīng)該解決這個問題呢?

這里，我就將我們在做數(shù)據(jù)抓取的時候是怎么解決這個性能問題告訴大家，希望給遇到同樣問題的朋友一點思路。即如果是APP的項目話，我們就在APP啟動的時候，對需要的域名進行預(yù)解析，然后將解析結(jié)果緩存到一個LRU緩存中，LRU緩存算法可以看前面的文章哈(LRU緩存淘汰算法，這次沒人再說你不會開發(fā))。這樣，如果我們使用這個域名的時候，就先從緩存中獲得對應(yīng)的 IP ，如果沒有的話，就再走整個DNS 的查詢過程。這個時候緩存中解析結(jié)果可能會變更，這樣就會緩存數(shù)據(jù)失效，我們可以起一個定時任務(wù)，去定期的更新緩存中的數(shù)據(jù)就行了。這種方案在解析性能上還是提升不少的，基本控制在200ms以內(nèi)。

通過上面我們已經(jīng)知道了用戶的請求是怎么到達CDN服務(wù)器的，并且針對DNS的解析進行了相關(guān)的講解同時對于性能問題也給出了自己開發(fā)中的建議，現(xiàn)在我們再來看看它的整體架構(gòu)圖，來整體回顧下。

怎么才能找到離用戶最近的CDN節(jié)點

現(xiàn)在，我相信大家肯定都掌握了如何讓用戶的請求怎么請求到CDN上了，接下來我們就要看另一個問題了，就是我們應(yīng)該怎么將最近的CDN節(jié)點分給用戶。

GSLB(Global Server Load Balance)這個組件就是對于部署在不同地理位置的服務(wù)器做負載均衡，其下面也可能管理了很多的本地負載均衡組件，主要有兩個作用：

是負載均衡器，這個不用多少，就是分攤流量的。 保證流量流經(jīng)的服務(wù)器與流量的源頭在地理上是很接近的。

GSLB它可以通過多種策略，來保證返回的CDN 服務(wù)器與用戶盡量保證在同一個地理區(qū)域。例如可以通過將用戶的 IP 分為n多不同的地理區(qū)域，然后將CDN 服務(wù)器對應(yīng)到各個區(qū)域里，這樣就可以根據(jù)用戶所在的區(qū)域來返回相應(yīng)的CDN節(jié)點�，F(xiàn)在再來看看其現(xiàn)在的架構(gòu)圖：

當(dāng)然，是否能夠從 CDN 節(jié)點上獲取到資源還取決于 CDN 的同步延時，一般在使用CDN時是這樣的流程：

我們先通過CDN廠商提供的接口將靜態(tài)資源寫到CDN的其中一個節(jié)點上。 CDN 自己內(nèi)部會將靜態(tài)資源同步到各個節(jié)點。

我們知道其實只要有同步，肯定是會有延時的，一旦我們無法從選定的 CDN 節(jié)點上獲取到數(shù)據(jù)，我們就不得不從源站獲取數(shù)據(jù)，而用戶網(wǎng)絡(luò)到源站的網(wǎng)絡(luò)可能會跨越多個主干網(wǎng)，這樣不僅性能上有損耗，也會消耗源站的帶寬，帶來更高的研發(fā)成本。所以，我們在使用 CDN 的時候需要關(guān)注 CDN 的命中率和我們自身服務(wù)器的帶寬情況。

總結(jié)，今天我們學(xué)習(xí)了使用CDN技術(shù)對我們的靜態(tài)資源進行加速，主要有兩個核心知識，一個是如何將用戶請求落到CDN節(jié)點上，另一個則是怎么才能選擇用戶最近的CDN節(jié)點給用戶。CDN技術(shù)并不是運維的專屬，我們開發(fā)人員應(yīng)該要掌握其核心知識，這樣我們在遇到這方面問題時才不會顯得那么不專業(yè)，如果今天的內(nèi)容對你有幫助