架構高性能海量圖片服務器的技術要素

在筆者的另外一篇文章《nginx性能改進一例》有講到，在圖片規模比大的狀況，nginx處理能力受制於文件系統的io，意味着，在大規模圖片的場景，若是運維還依舊採用傳統文件系統的方式，不管是備份成本，仍是前端成本，將是沒法去衡量，不要去期望調優一點文件系統的一些參數，能帶來多大的性能收益，也不要去目錄hash+rewrite的方式，改進不大，由於新版的文件系統默認開啓了dir_index，解決了同一個目錄下文件過多而過慢的問題。不過還有一種方案就是採購SSD盤、fusion-io卡之類高性能的硬件去解決隨機io，固然你得容忍備份的痛苦。
先看一下架構圖邏輯圖，這也是如今各大公司採用的方式。

這個是一個大體邏輯圖，具體佈署是根據模塊的性能消耗類型去混合部署。
第一點，分佈存儲的必要性：存儲原始圖片，用分佈式存儲有幾個好處，分佈式能自動提供冗餘，不須要咱們去備份，擔憂數據安全，在文件數量特別大的狀況下，備份是一件很痛苦的事情，rsync掃一次多是就是好幾個小時。還有一點就是分佈式存儲動態擴容方便。不過惟一遺憾的是目前適合於存小文件系統比較少，我瞭解的只有fastdfs，以及淘寶的tfs，還有mongodb這幾個，tfs經歷過淘寶那種規模的考驗，文檔和工具都太少，若是能駕馭tfs，我以爲值得嘗試一下。。

第二點，上傳和下載分開處理：一般圖片服務器上傳的壓力與下載的壓力相差很大，大多數的公司都是下載的壓力是上傳壓力的n倍。業務邏輯的處理也區別明顯，上傳服務器對圖片重命名，記錄入庫信息，下載服務器對圖片添加水印、修改尺寸之類的動態處理。從數據的角度，咱們能容忍部分圖片下載失敗，但毫不能有圖片上傳失敗，由於上傳失敗，意味着數據的丟失。上傳與下載分開，能保證不會因下載的壓力影響圖片的上傳，並且還有一點，下載入口和上傳入口的負載均衡策略也不一樣，下面有說明。

第三點，使用cache作緩層：分佈式存儲解決了存儲安全問題，但性能問題還須要用cache去解決，直接從分佈式存儲取文件給用戶提供服務，每秒的request高不到哪裏去，像淘寶之類的網站，都作了二層cache。對於cache的開源軟件選型要考慮二點，1，緩存的量級大，儘量讓熱點圖片緩存在cache中，像varnish之類的，純內存的cache，雖然性能很好，但能cache的量級很限於內存，用來作圖片的緩存不太適合；2，避免文件系統式的緩存，在個人另外一篇文章中有測過，在文件量很是的狀況下，文件系統的型能不好，像squid,nginx的proxy_store,proxy_cache之類的方式緩存，當緩存的量級上來後，性能將不能知足要求。開源的traffic server直接用裸盤緩存，是一個不錯的選擇，固然使用leveldb之類的作緩存，我估計也能達到很好的效果。這裏說明一下cache緩存最好不要去依賴第三方CDN，如今不少第三的CDN業務，不只提供內容分發外，還額外提供第一個二級緩存之類的服務，但這裏面就一個最大的風險就是若是第三調整帶來的回源壓力暴增，此時你的架構可否支撐，須要認真評估一下，若是成本容許，服務控制在本身手中最靠譜。

第四點，使用一致性哈希（consistent hashing）作下載負載均衡：雖公司的業務的增長帶來流量的增長，一個階段後，一個cache一般不能解決問題，這時擴容cache就是常作的一件事，傳統的哈希不足就是每擴容一次，哈希策略將從新分配，大部分cache將失效，帶來的問題是後端壓力暴增。對uri進行一性能哈希負載均衡，能避免增長或者減小cache引發哈希策略變化，目前大多開源的負載均衡軟件都有這個功能，像haproxy都有，至於一致性哈希的最優化，能夠參考一下下圖(摘自網上的一張圖，表示的是怎樣的物理節點和虛擬節點數量關係，哈希最均勻)。

第五點，利用CDN分發和多域名訪問入口：想要得到好的用戶體驗，利用CDN的快速分發是有必要的，從成本上考慮能夠購買使用第三方的CDN平臺。多域名訪問方式，大多的瀏覽器都對單個域名進行了線程併發限制，採用多域名可以加快圖片展現的速度。

關於圖片服務器的部署基本算完了，其它的細節性調優這裏就不說明了。