先看一下架構圖邏輯圖，這也是現在各大公司採用的方式。
這個是一個大致邏輯圖，具體佈署是根據模塊的性能消耗類型去混合部署。
第一點，分佈存儲的必要性：存儲原始圖片，用分佈式存儲有幾個好處，分佈式能自動提供冗餘，不需要我們去備份，擔心數據安全，在文件數量特別大的情況下，備份是一件很痛苦的事情，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平臺。多域名訪問方式，大多的瀏覽器都對單個域名進行了線程併發限制，採用多域名能夠加快圖片展示的速度。
轉自：http://my.oschina.net/beiyou/blog/83210