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是率先實現這種小文件網絡存儲系統的。
有個觀點比較好：對於老板們而言，往往覺得，用錢能解決的都不算問題。但問題在於，你遇到的問題，別人都沒遇到過。那這個時候你就沒有經驗可以參考或者直接拿來使用。只有自己參考一些思路去創造技術了。
三、關於圖片進行雲存儲(cdn加速)
曾經看過這個，這個是比較適合創業公司的。價格相對便宜
介紹提到，我們在全國各地部署了55個CDN節點，500多台服務器，電信，聯通，移動和教育網的4線帶寬。
其實，現在的雲存儲本質就是一個cdn服務商。你把靜態的圖片上傳到他提供的服務器上去(ftp方式上傳或者api形式編寫程序上傳)。他為你做就近節點訪問。
計費方式：按照流量付費，99元購買100g。怎么算流量。每次訪問文件的大小累加，比如一個1m的文件，訪問一次流量就加1m。
我個人理解，對於圖片的量不大的情況下，使用這種雲服務，好處不是節省存儲空間。你自己的服務器100g的空間可能創業型公司都沒用完，不是什么存儲空間不夠用，然后去用雲存儲。以前我對cdn比較模糊，有這么點理解，或者以為是分散網站web服務器流壓力，服務器分流。這些好處是有的。但是，只要理解了cdn產生的背景和解決的關鍵問題后，就會明白雲存儲關鍵好處在於：給用戶就近節點訪問，加速。
我覺得，如果不是出於這個考慮，或者達不到這樣的目的。用其他方案也完全可以替代。何必使用雲存儲呢？就是你無非有實力做到全國多個節點去部署服務，才需要租用cdn來幫你，畢竟他們是規模產生的效益，專注於解決這個領域。