通過 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集群，使用性能比較好的機器來頂，這樣，就解決了最活躍的用戶，讓他的訪問速度，比不活躍用戶訪問速度要快。
然后按照時間，一年或者半年一次輪詢切換最新使用的圖片上傳域名，也不會出現圖片遷移的問題。

?

以上純屬 自己的看法，如有錯誤，請留言指教。http://blog.csdn.net/iinel/article/details/4669448

轉載于:https://www.cnblogs.com/seanxyh/archive/2013/04/16/3023452.html

總結

以上是生活随笔為你收集整理的T级图片数据Cache思路以及图片服务器搭建方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。