為什麼CDN會出現圖片雲、視頻雲這樣的細分？

01-06

比如視頻雲是不是有更針對性的技術？

前TudouCDN作者。主要是文件大小會對會對CDN的服務策略產生很大的影響。

對於圖片，靜態前端文件等，主要特徵是文件小。這就決定了一台CDN伺服器上可以緩存的下很多這類文件。所以就算把整個CDN集群都宣稱可以服務這些文件也無所謂。各地用戶可以連接任何一台伺服器來請求任何一個小文件。

找不到這些文件，那就回源站取。且這個過程時間也不長，通常最多幾秒就完成了，所以在用戶請求時回源站的時間也是可以接受的。而且對源站來講，給幾百台CDN伺服器提供小文件訪問也是個很輕鬆的事情。

而對於視頻，文件巨大，遊戲規則就變了。

1、文件存儲容量。通常在線服務的視頻，大小從幾百KB到幾個GB都有。總量方面輕鬆超出一台伺服器的存儲能力。所以，必須要有策略來決定哪些伺服器存儲哪些視頻，這是個負載均衡策略。我那時全國分了4個組：東淫西賤南盪北色，每個組裡包含全部文件備份，組內部再按照文件ID的餘數來分配對應伺服器。

2、回源站時延。同樣因為文件大，回源站一次要動則分鐘級別的，用戶肯定不能忍。所以，都是在視頻準備好之後，推送到CDN伺服器的，推送好一台，就允許這個伺服器上這個文件對外服務。實際執行中用的是類似推送的方法，告知CDN伺服器執行一個回源站拿視頻的任務，而不是用戶觸發的。

3、回源站帶寬問題。源站一般帶寬也很小，一旦大量CDN伺服器回源站同步也會幹掉源站。所以，那時的策略是，生成同步任務時第一個copy首先生成，允許CDN伺服器回源站拿視頻。後續該文件的同步就都是走結點間同步了，沒啥特殊情況不允許回源站。

4、視頻分發。正因為不是所有CDN伺服器都包含所有視頻。所以用戶請求視頻時，往往返回一個可用URL列表供播放。客戶端應該按照順序嘗試。列表的順序會考慮到優先給距離用戶近的伺服器，當前各個伺服器負載，以及數十種其他策略。

所以，視頻CDN需要做如上一堆工作，才能有效的對外服務。這是需要區別於已有的小文件CDN的。

冒昧的說下，其實這個提問里有些概念上的模糊，至少做圖片雲和視頻雲的不會只說自己是CDN 更多說自己是雲計算，雲服務。

從模型上看CDN 更像是paas和iaas之間的一種服務，當然cdn早於iaas出來，而且沒有iaas也可以搭建cdn。cdn更多只是一種必要的分發技術，減壓，就近，擴充能力。只是現在cdn行業知道的多。

圖片雲是圖片服務（編輯，圖片壓縮，轉格式，水印，指紋等）+圖片存儲（本身就是分散式可以直接對外服務）+靜態小文件CDN（減少存儲，提升服務的標準配置）

視頻雲是視頻服務（上傳，轉碼，媒資，廣告，統計，分享，播放器等）+視頻存儲（海量存儲，DRM）+視頻cdn（標配，要不直接搭套s3得了，尤其對網民提供訪問，還需要支持拖拽，防盜鏈等）

CDN為了做好前端cache的優化以及存儲的分布必然針對不同的需求做出不同的細分方案來。

A先看看html和動態生成的一些文件：

.會變化和更新，需要前端及時的更新和變化

.大小都不大

.數量不大，熱點集中

B再看看js、圖片、文章類型的html：

.變化不大，生命周期較長

.都不大

.數量巨大，熱點分布較大

C視頻和音樂：

.變化不大，生命周期很久

.切片文件較大，數量較少

所以你會發現我們可以為AB做成一組，讓命中率提高，做好hash，可以讓每台伺服器有較高吞吐。但是因為文件系統的inode問題，一個很大容量的後端必然面對存儲碎片問題，所以可以將大部分存儲（按更新）分布到二級節點去。

C做的一組就不同了，沒有辦法在一個節點裡放所有的內容，必須把內容切到不同的節點。同時熱數據要不斷的做交換，放到二級節點的後端，而且更有意思的是，大多數視頻cdn會在前端的每台機器上都放置最熱的視頻內容。我在兩個視頻網站中都得到過一個有意思的數據：幾十G的內容能承擔起全網百分之幾十的流量。

宗上所述，AB和C必然從存儲、後端、分級和策略上不同。而在極端的情況下，A和B也有所有不同。國內某大型互聯網網站的XX應用平台，針對於A還做了更深入的架構改變。

做CDN就是天天切，從數據里切出最真實的架構適應性。

圖片雲主要是文件下載業務，視頻雲更關注直播流媒體，兩者關注的技術細節不一樣。舉個例子，視頻雲就需要為直播播放終端提供秒開加速，圖片雲無需這類功能考慮。