前幾天，我們講到了為何引入緩存且應該什么時候引入，并且講到了我們生產中緩存的讀寫策略是什么，忘記了的可以自行去文章列表看下，同時又單獨深入講解了redis哨兵機制（Redis 哨兵機制以及底層原理深入解析，這次終于搞清楚了）和緩存穿透問題的解決方案（緩存穿透問題，開發中真實解決方案）。至此，我們現在的系統架構已經是這樣子的了
于架構圖我們可以看出，我們現在使用了分布式緩存來加速動態請求的各種數據，但是，我們的系統中其實還有很多的靜態資源的，并且請求量也是超級大的。例如：
移動端App，有很多的圖片，小視頻以及流媒體等。 對于網站來說，不僅有上面那些資源之外，還有大量的html 文件，css文件以及JAVAscript文件等。現在我們的一個商城里面，有很多的商品圖片，并且詳情頁還有產品介紹視頻，目前這些靜態資源均是放在Nginx服務器上的，請求量很大，并且這些文件對于訪問速度要求極高，并且占據很高的帶寬。這里就會很有可能出現訪問速度變慢，將帶寬占滿從而影響我們后端動態請求。這個時候我們就需要考慮該怎么去對這些靜態資源做加速了。
如何思考加速首先我們想一下可不可以也用分布式緩存來存儲達到加速的目的呢？答案肯定是不行的，因為：
圖片或者視頻文件大小都不小，在幾兆到幾百兆之間。 我們的用戶是遍地全國各地的甚至還有國外用戶，需要讓用戶能很快的得到相應，即就近訪問，我們不能全國各地都建機房去部署緩存，不現實。 圖片或視頻信息文件很大，訪問量又極高，這樣，如果自建機房帶寬肯定是會面臨極大的風險。因此，我們不能自建機房來加速靜態資源，我們需要在我們的應用服務器外層加一層靜態資源處理的組件，并且還能遍地全國各地讓用戶能就近訪問，還能讓這些緩存命中率很高，以至于盡量減少回源到我們自己的業務服務器，這種技術就是我們下面要說的CDN。
CDN核心技術CDN 其實就是網絡分發的一種技術，它將我們的靜態資源分發到各個地理位置不同的機房服務器上，這樣就能實現用戶就近訪問的問題，且加快靜態資源的訪問速度。
你可能會說，cdn這玩意我們開發又用不到，不用去掌握的吧，其實不然，建議你不要只是將自己一直放在只是開發的位置，你要有掌控全局的決心，很多cdn排查的工作都是需要資深工程師才能干的，所以你要了解這門技術，現在假如讓你來配置cdn和排查CDN問題，你可能就會因為自身技術壁壘而感到束手無策。
首先，我們來看看搭建一個CDN系統需要考慮的兩個關鍵點：
怎樣才能讓用戶請求先映射到CDN服務器上，這應該是最基本的了。 怎樣根據用戶所處的地理位置，選出離他最近的CDN節點給用戶訪問。接下來，我們就基于上面考慮點來一起來看看CDN技術是怎么實現靜態資源的加速。
如何將用戶請求落到CDN服務器上12306網站我們應該都不陌生，它是有很多的cdn節點來讓我們就近訪問提供靜態資源加速的，而我們輸入的網址就是12306自己家的網址，并不是cdn的ip。這是為什么呢？因為如果直接提供給用戶cdn 節點IP的話，如果IP改變怎么辦，那所有的靜態資源都得改變地址，這種是很不靠譜的，所以都是直接給我們服務的自己家域名，然后隱藏住CDN 的IP，那這種機制該怎么做呢？其實大家應該能猜得到，就是運用DNS 進行域名映射。
DNS（Domain Name System）就是一個存儲域名和 IP 映射的分布式數據庫，其中域名解析返回的結果有兩種：
直接返回域名對應的 IP 地址。 返回另一個域名，即將當前域名解析到另一個域名，會跳轉到另一個域名解析上，現在我們就是通過這種方式來解決上面域名映射問題下面我們就來看看具體的是怎么操作的。
假設我們的一級域名為 a.com ，那么我們就可以將圖片服務域名定義為“img.a.com”，然后將這個域名的解析結果配置到CDN提供的域名上。例如，ucoud提供一個這樣的域名“78f98.cdn.ucloud.com.cn”，我們的系統圖片地址是這個樣子"img.a.com/100.jpg"。
用戶在請求100.jpg 地址的時候，DNS服務器就會將這個域名解析到78f98.cdn.ucloud.com.cn 域名上，然后再將這個域名解析到CDN的IP地址，這樣就得到了CDN上資源數據了。
我們知道其實DNS解析是有個問題的就是，因為域名解析過程是分好幾個級別的，每一級有專門的域名服務器承擔其解析的職責，所以，域名的解析過程有可能需要跨越公網做多次 DNS 查詢，在性能上是比較差的。
經過了向多個 DNS 服務器做查詢之后，整個 DNS 的解析的時間有可能會到秒級別，那我們應該解決這個問題呢？
這里，我就將我們在做數據抓取的時候是怎么解決這個性能問題告訴大家，希望給遇到同樣問題的朋友一點思路。即如果是APP的項目話，我們就在APP啟動的時候，對需要的域名進行預解析，然后將解析結果緩存到一個LRU緩存中，LRU緩存算法可以看前面的文章哈（LRU緩存淘汰算法，這次沒人再說你不會開發）。這樣，如果我們使用這個域名的時候，就先從緩存中獲得對應的 IP ，如果沒有的話，就再走整個DNS 的查詢過程。這個時候緩存中解析結果可能會變更，這樣就會緩存數據失效，我們可以起一個定時任務，去定期的更新緩存中的數據就行了。這種方案在解析性能上還是提升不少的，基本控制在200ms以內。
通過上面我們已經知道了用戶的請求是怎么到達CDN服務器的，并且針對DNS的解析進行了相關的講解同時對于性能問題也給出了自己開發中的建議，現在我們再來看看它的整體架構圖，來整體回顧下。
怎么才能找到離用戶最近的CDN節點
現在，我相信大家肯定都掌握了如何讓用戶的請求怎么請求到CDN上了，接下來我們就要看另一個問題了，就是我們應該怎么將最近的CDN節點分給用戶。
GSLB（Global Server Load Balance）這個組件就是對于部署在不同地理位置的服務器做負載均衡，其下面也可能管理了很多的本地負載均衡組件，主要有兩個作用：
是負載均衡器，這個不用多少，就是分攤流量的。 保證流量流經的服務器與流量的源頭在地理上是很接近的。GSLB它可以通過多種策略，來保證返回的CDN 服務器與用戶盡量保證在同一個地理區域。例如可以通過將用戶的 IP 分為n多不同的地理區域，然后將CDN 服務器對應到各個區域里，這樣就可以根據用戶所在的區域來返回相應的CDN節點。現在再來看看其現在的架構圖：
當然，是否能夠從 CDN 節點上獲取到資源還取決于 CDN 的同步延時，一般在使用CDN時是這樣的流程：
我們先通過CDN廠商提供的接口將靜態資源寫到CDN的其中一個節點上。 CDN 自己內部會將靜態資源同步到各個節點。我們知道其實只要有同步，肯定是會有延時的，一旦我們無法從選定的 CDN 節點上獲取到數據，我們就不得不從源站獲取數據，而用戶網絡到源站的網絡可能會跨越多個主干網，這樣不僅性能上有損耗，也會消耗源站的帶寬，帶來更高的研發成本。所以，我們在使用 CDN 的時候需要關注 CDN 的命中率和我們自身服務器的帶寬情況。
總結，今天我們學習了使用CDN技術對我們的靜態資源進行加速，主要有兩個核心知識，一個是如何將用戶請求落到CDN節點上，另一個則是怎么才能選擇用戶最近的CDN節點給用戶。CDN技術并不是運維的專屬，我們開發人員應該要掌握其核心知識，這樣我們在遇到這方面問題時才不會顯得那么不專業，如果今天的內容對你有幫助，恰好你又喜歡就關注我，我會持續更新開發中實戰案例方案，謝謝。
