通過 pp.sohu.com，淘寶，拍拍網的域名分析：
1871.img.pp.sohu.com.cn ，1872.img.pp.sohu.com.cn，1873.img.pp.sohu.com.cn ...
大致分析，是通過squid 集羣的方式實現：
大致的結構圖如下：
分析的理由如下：
（一 ）
一般 Squid Server 集羣 簡單的運作模式是：
1. 當 Squid Server (parent) 沒有資料時，會先向 Sibling 的 Squid Server 要資料。
2. 如果都拿不到資料，才向用戶端回報拿不到資料。
（二）
從pp.sohu.com網站上網頁相關返回頭信息分析：
X-Cache
MISS from 12237950.14924987.21130635.sohu.com, HIT from 14087629.19002952.22596629.sohu.comAge32282
Via1.1 12237950.14924987.21130635.sohu.com:80 (squid), 1.0 14087629.19002952.22596629.sohu.com:80 (squid)
說明，它確實是squid集羣，第一個squid中沒有找到，跑到相鄰的squid server 去查找資料。
具體的集羣方式，到底是 Sibling 在前，還是parent在前，不太清楚，或者沒有parent，全都是由sibling組成。都有可能。
但是 有時候可以看到：
X-Cache
HIT from 10011260.10470073.18905479.sohu.com,
HIT from 14087629.19002952.22596629.sohu.com
所以設想，他可能有一個 parent squid server。
從 14087629.19002952.22596629 估計，他們是三個squid 一小組之類的。
圖有可能是如下所示：
s
（三）
有一遍關於 paipai網的圖片架構，由於他們是網上c@c
類型的網站，商品的圖片數量肯定是巨大的，他們的解決方案是：
試用了squid 磁盤cache集羣技術。
以下是他們們對squid cache集羣的配置方面的一些階段性的經驗：
A、 需要ulimit增加打開文件句柄的數量，以滿足大併發訪問的要求。
B、 編譯的時候需要加入epoll支持。
C、 編譯時打開cachemgr管理功能，以便運營時的監控數據獲取。
D、 編譯時加入GDSF淘汰策略。淘汰策略對CPU消耗和命中率有明顯影響。
相關文獻（John Dilley的Enhancement and Validation of Squid’s Cache Replacement Policy）中也有這方面的數據：
E、 編譯是加入異步IO支持參數。
F、 根據cache對象的大小設定cache的介質是內存還是磁盤。
由於squid可控內存有限，我們設置大量小文件（小於25K的圖片）cache在內存中，設置大文件（大於25K的圖片）cache在磁盤。
G、 磁盤cache不是越大越好。根據現在的訪問情況看，如果目前一個省的用戶的訪問行爲足夠代表性。對於拍拍圖片的訪問命中率大概是：5G可以達到54％；20G可以達到 80％（以上磁盤cache容量是單機設置，測試時用了2臺服務器做集羣，所以總容量是上述的1倍）。
H、 做磁盤cache的分區的文件系統最好使用reiserfs。
I、 不要記錄cache_access_log和cache_store_log，這些log會嚴重影響磁盤IO性能。
J、 使用ICP協議作爲集羣服務器間的通信協議，雖然比較老，但比較穩定。
K、 對於32位的suse系統，內存cache大小不能超過1.8G
參考網址：
一下這篇文章，和我們的問題，非常相似。
（拍拍網的圖片架構）
http://blog.csdn.net/sutine/archive/2009/09/28/4606490.aspx
（四）
再到拍拍網和淘寶的網站查看網頁頭部返回的信息：
他們相似的地方，都是利用 圖片服務器多域名這樣的方式，實現的集羣，
不同的是拍拍網使用的是nginx在最前端，淘寶好像是squid直接定在前面，沒仔細看。
由於感覺squid直接在前，還是比較危險，而且，squid集羣維護比較麻煩，抗壓能力也不怎麼強，所以，
根據推測，自己設計了一個圖片服務器搭建的方案：
解釋如下：
（1）
假設現在有 十個域名：
Img01.xxx.com 到img10.xxx.com 每個域名後面都帶有一一臺或者幾臺nginx。利用nginx抗壓力和利用它的url_hash. 然後在後方再帶上一組squid集羣。
(2）
Squid 集羣，使用memDisk 和harddiskCache 同時使用。 針對不同的機器，加以調整，好機器內存大一點的話，多放點內存，比如5G內存cache，20G diskCache。由於我們現在的機器比較少，所以每臺物理機器上安裝2-3臺squid。由於它消耗的主要是內存和磁盤，對cpu影響，不是非常的明顯，應該可以扛得住。
10臺機器*2 *20 +10*5*2 = 500G ，至少可以cache將近 我們 1/8的數據。
（3）
同時，如果其中的一臺squid死掉的話，還可以使用後被的nginx和squid頂上去，不會出現訪問不到的情況。
（4）
單獨拿出一臺 nginx 當做 perge Server。在內網使用，外網發來的perge指令，全部攔截。Real Server 使用lighthpppd 等對圖片處理比較強的server來承擔。
（5）
前端機器上傳圖片的時候，將現有的這10個域名（可以隨時添加），均勻的按照照片名稱分散，保存到數據庫裏。
（6） 這樣做的好處是：
如果我添加一組 圖片服務器域名，以前所有圖片的cache不會失效。
如果有一個盤櫃的磁盤 滿了的話，我可以添加一組 圖片服務器域名 ，將以前的 域名從上傳前端去除，這樣，就可以實現 只讀不寫的功能，而且不用帶來遷移的問題。
同時，由於上傳的用戶，大部分肯定是活躍用戶，所以，我們可以將現在上傳使用的 這組 圖片服務器域名對應的機器以及它的cache集羣，使用性能比較好的機器來頂，這樣，就解決了最活躍的用戶，讓他的訪問速度，比不活躍用戶訪問速度要快。
然後按照時間，一年或者半年一次輪詢切換最新使用的圖片上傳域名，也不會出現圖片遷移的問題。
以上純屬 自己的看法，如有錯誤，請留言指教。