關於cdn原理(就是內容分發網絡)

cdn，我理解其本質就是爲了解決距離遠產生的速度問題，使用就近的服務。

從中國請求美國一臺服務器上的圖片。通常比較慢，由於距離這麼遠，網絡傳輸是存在損耗的，距離越遠，傳輸的時間就越長。通常會看到瀏覽器左下角顯示：「已響應,正在傳輸數據..」。這不是服務器自己問題了。實際上服務器早就響應請求，把數據發給客戶端，可是網絡問題，就一直在傳輸，沒傳完了。

 

在中國，是南北距離遠的問題。南北還會涉及到跨網，南方用戶使用電信居多，北方用戶網通居多。兩個線路須要跨越，會有時間延遲。北京到廣州的距離，若是直接請求

cdn加速就是適應這個需求產生的：如今不請求美國的服務器。直接在中國安放節點(節點是比較籠統的詞語，能夠理解成一臺服務器，也能夠理解成一個機房，就是一個點嘛)，請求距離近的節點。這樣子就不須要那麼遠的距離了。

 

記得之前在長沙的網站，團購以城市分站的形式。北京和長沙用的是同一套程序。服務器在長沙。北京用戶訪問北京站的時候,實際上須要遠距離訪問長沙的服務器。速度怎麼都快不起來。跟服務器性能徹底不要緊。當時不懂這些。不清楚怎麼折騰。看那本《前端優化技巧》，想辦法去作js代碼壓縮，瀏覽器緩存之類的。實際上瞎折騰。不是說這些前端優化不重要，哲學上有主次矛盾之分，瓶頸在哪裏就去突破哪裏。沒解決主要矛盾，問題並不會迎刃而解。當時也不是數據庫瓶頸。若是去優化數據庫。也不會明顯改善。就那點數據量。根本就達不到瓶頸。哪裏談得上主要矛盾。隨着後來去其餘公司工做，接觸一些東西，相似不找瓶頸的優化例子發生在身邊好幾回了，先沒找到瓶頸就瞎去優化。個人同事多是抱着多多益善的心態去作的，但主要矛盾(技術上說是瓶頸)沒找到，也沒改善。

 

當時若是沒想到是距離問題。也就不會想到cdn，當時其實我根本不知道cdn服務。我只知道，google這些網站確定在中國部署的服務器，要否則，中國用戶還去訪問美國的服務器，那再好的服務器都會速度慢的。

 

因爲本身搭建cdn環境和機房的資金比較大（須要大量的服務器），也須要人力維護。反正通常的公司弄不起，其實根本不划算。淘寶之前用商用的cdn服務，後來商用的扛不住了，就搭建了本身的cdn網。我不知道新浪有沒有本身搭建，但其實我以爲跟淘寶的特色有關，店鋪不少，不管是商品仍是交易記錄總計起來商品不少的圖片，圖片都是靜態的部分，cdn原本就是用來作靜態的(圖片，css，js等)請求分發用的。

我以前在網上看到一句話，cdn網絡不是通常的公司玩得起的。

通常的公司本身搭建cdn網絡成本高，因此就有商業的cdn提供付費租用服務，這是一項很成熟的業務，不少這樣的公司，大部分全國性的互聯網公司都會使用到cdn。

 

總結：cdn服務。對於靜態內容是很是適合的。因此像商品圖片，隨着訪問量大了後，租用cdn服務，只須要把圖片上傳到他們的服務器上去。

 

例子：北京訪問長沙服務器，距離太遠。我徹底能夠把商品圖片，放到北京的雲服務（我以爲如今提供給網站使用的雲存儲其實就是cdn，給網站提供分流和就近訪問）上去。這樣子北京用戶訪問的時候，實際上圖片就是就近獲取。不須要很長距離的傳輸。

本身用一個域名img.xxx.com來載入圖片。這個域名解析到北京的雲服務上去。

 

作法:數據庫中保存的是」 images/2012/09/25/1343287394783.jpg」,

這些圖片實際上不存儲在web服務器上。上傳到北京的cdn服務器上去。

我從數據庫取出來，直接」img.xxx.com/」+」 images/2012/09/25/1343287394783.jpg」

 

好比若是還有多個，就命名img1.xx.com、img2.xx.com

反正能夠隨便。因此若是把域名直接保存進去。就顯得很麻煩了。遷移麻煩。

 

像淘寶，凡客，亞馬遜這些電子商務網站，咱們看到請求的時候，下面每每會有

img1.xxx.cdn.com

img2.xxx.cdn.com

其實他們保存在數據庫中的是相對路徑。有些是不須要在數據庫保存的，縮略圖能夠實時訪問的時候用程序生成(節省不少存儲空間)

 

實際上，把域名保存在數據庫中，很是不利於系統遷移。一旦換個域名的話，原來保存在數據庫中的是「www.abc.om/images/xxxxxx「,由於路徑都在數據庫中寫死了。下回換個域名就用不了了。那個時候本身去寫sql語句批量更新字段吧。

 

幾個術語：

icp，Internet Content Provider，也就是網絡內容提供者。聯想到咱們運營一個網站須要icp備案了嗎？你本身運營網站，你就是ｉｃｐ服務商

 

IDC（Internet Data Center)，互聯網數據中心。IDC的概念，目前尚未一個統一的標準。通俗點，就是提供機房託管(服務器租用和託管)，域名註冊之類的。

 

 

關於淘寶的圖片存儲

 

 

瞭解到：淘寶之前使用了商用的存儲。可是無法知足需求。聽說，到2010年，淘寶網後端保存着286億張圖片。商用的系統系統無法知足需求的時候。他們就本身開發了一個tfs。大規模的小文件在磁盤上讀取，須要磁盤磁頭頻繁的尋道和換道。大併發狀況下和大量的操做確實很麻煩。其實借鑑了當時google公佈的gfs設計論文。google有相冊服務。爲每一個用戶提供上傳圖片存儲。

估計，google是率先實現這種小文件網絡存儲系統的。

 

有個觀點比較好：對於老闆們而言，每每以爲，用錢能解決的都不算問題。但問題在於，你遇到的問題，別人都沒遇到過。那這個時候你就沒有經驗能夠參考或者直接拿來使用。只有本身參考一些思路去創造技術了。

 

3、關於圖片進行雲存儲(cdn加速)

 

曾經看過這個，這個是比較適合創業公司的。價格相對便宜

https://www.upyun.com/

介紹提到，咱們在全國各地部署了55個CDN節點，500多臺服務器，電信，聯通，移動和教育網的4線帶寬。

 

其實，如今的雲存儲本質就是一個cdn服務商。你把靜態的圖片上傳到他提供的服務器上去(ftp方式上傳或者api形式編寫程序上傳)。他爲你作就近節點訪問。

 

計費方式：按照流量付費，99元購買100g。怎麼算流量。每次訪問文件的大小累加，好比一個1m的文件，訪問一次流量就加1m。

 

 

我我的理解，對於圖片的量不大的狀況下，使用這種雲服務，好處不是節省存儲空間。你本身的服務器100g的空間可能創業型公司都沒用完，不是什麼存儲空間不夠用，而後去用雲存儲。之前我對cdn比較模糊，有這麼點理解，或者覺得是分散網站web服務器流壓力，服務器分流。這些好處是有的。可是，只要理解了cdn產生的背景和解決的關鍵問題後，就會明白雲存儲關鍵好處在於：給用戶就近節點訪問，加速。

 

我以爲，若是不是出於這個考慮，或者達不到這樣的目的。用其餘方案也徹底能夠替代。何須使用雲存儲呢？就是你無非有實力作到全國多個節點去部署服務，才須要租用cdn來幫你，畢竟他們是規模產生的效益，專一於解決這個領域。