T级图片数据Cache思路以及图片服务器搭建方法
通過 pp.sohu.com，淘寶，拍拍網(wǎng)的域名分析：
1871.img.pp.sohu.com.cn ，1872.img.pp.sohu.com.cn，1873.img.pp.sohu.com.cn ...
大致分析，是通過squid 集群的方式實現(xiàn)：
大致的結(jié)構(gòu)圖如下：
?
?
分析的理由如下：
（一 ）
一般 Squid Server 集群 簡單的運作模式是：
1. 當(dāng) Squid Server (parent) 沒有資料時，會先向 Sibling 的 Squid Server 要資料。
2. 如果都拿不到資料，才向用戶端回報拿不到資料。?
（二）
從pp.sohu.com網(wǎng)站上網(wǎng)頁相關(guān)返回頭信息分析：
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
所以設(shè)想，他可能有一個 parent squid server。
從 14087629.19002952.22596629 估計，他們是三個squid 一小組之類的。
圖有可能是如下所示：
?
?
?
s
（三）
有一遍關(guān)于 paipai網(wǎng)的圖片架構(gòu)，由于他們是網(wǎng)上c@c 類型的網(wǎng)站，商品的圖片數(shù)量肯定是巨大的，他們的解決方案是：
試用了squid 磁盤cache集群技術(shù)。
以下是他們們對squid cache集群的配置方面的一些階段性的經(jīng)驗：
??? A、 需要ulimit增加打開文件句柄的數(shù)量，以滿足大并發(fā)訪問的要求。
??? B、 編譯的時候需要加入epoll支持。
??? C、 編譯時打開cachemgr管理功能，以便運營時的監(jiān)控數(shù)據(jù)獲取。
??? D、 編譯時加入GDSF淘汰策略。淘汰策略對CPU消耗和命中率有明顯影響。
??? 相關(guān)文獻（John Dilley的Enhancement and Validation of Squid’s Cache Replacement Policy）中也有這方面的數(shù)據(jù)：
E、 編譯是加入異步IO支持參數(shù)。
??? F、 根據(jù)cache對象的大小設(shè)定cache的介質(zhì)是內(nèi)存還是磁盤。
??? 由于squid可控內(nèi)存有限，我們設(shè)置大量小文件（小于25K的圖片）cache在內(nèi)存中，設(shè)置大文件（大于25K的圖片）cache在磁盤。
?G、 磁盤cache不是越大越好。根據(jù)現(xiàn)在的訪問情況看，如果目前一個省的用戶的訪問行為足夠代表性。對于拍拍圖片的訪問命中率大概是：5G可以達到 54％；20G可以達到 80％（以上磁盤cache容量是單機設(shè)置，測試時用了2臺服務(wù)器做集群，所以總?cè)萘渴巧鲜龅?倍）。
H、 做磁盤cache的分區(qū)的文件系統(tǒng)最好使用reiserfs。
I、 不要記錄cache_access_log和cache_store_log，這些log會嚴(yán)重影響磁盤IO性能。
J、 使用ICP協(xié)議作為集群服務(wù)器間的通信協(xié)議，雖然比較老，但比較穩(wěn)定。
K、 對于32位的suse系統(tǒng)，內(nèi)存cache大小不能超過1.8G
參考網(wǎng)址：
一下這篇文章，和我們的問題，非常相似。
（拍拍網(wǎng)的圖片架構(gòu)）
http://blog.csdn.net/sutine/archive/2009/09/28/4606490.aspx
?
（四）
再到拍拍網(wǎng)和淘寶的網(wǎng)站查看網(wǎng)頁頭部返回的信息：
他們相似的地方，都是利用 圖片服務(wù)器多域名這樣的方式，實現(xiàn)的集群，
不同的是拍拍網(wǎng)使用的是nginx在最前端，淘寶好像是squid直接定在前面，沒仔細看。
由于感覺squid直接在前，還是比較危險，而且，squid集群維護比較麻煩，抗壓能力也不怎么強，所以，
根據(jù)推測，自己設(shè)計了一個圖片服務(wù)器搭建的方案：
?
?
?
?
?
解釋如下：
（1）
假設(shè)現(xiàn)在有 十個域名：
Img01.xxx.com 到img10.xxx.com?? 每個域名后面都帶有一一臺或者幾臺nginx。利用nginx抗壓力和利用它的url_hash. 然后在后方再帶上一組squid集群。
(2）
Squid 集群，使用memDisk 和harddiskCache 同時使用。 針對不同的機器，加以調(diào)整，好機器內(nèi)存大一點的話，多放點內(nèi)存，比如5G內(nèi)存cache，20G diskCache。由于我們現(xiàn)在的機器比較少，所以每臺物理機器上安裝2-3臺squid。由于它消耗的主要是內(nèi)存和磁盤，對cpu影響，不是非常的明 顯，應(yīng)該可以扛得住。
10臺機器*2 *20 +10*5*2 = 500G ，至少可以cache將近 我們 1/8的數(shù)據(jù)。
（3）
同時，如果其中的一臺squid死掉的話，還可以使用后被的nginx和squid頂上去，不會出現(xiàn)訪問不到的情況。
（4）
單獨拿出一臺 nginx 當(dāng)做 perge Server。在內(nèi)網(wǎng)使用，外網(wǎng)發(fā)來的perge指令，全部攔截。Real Server 使用lighthpppd? 等對圖片處理比較強的server來承擔(dān)。
（5）
前端機器上傳圖片的時候，將現(xiàn)有的這10個域名（可以隨時添加），均勻的按照照片名稱分散，保存到數(shù)據(jù)庫里。
（6） 這樣做的好處是：
如果我添加一組 圖片服務(wù)器域名，以前所有圖片的cache不會失效。
如果有一個盤柜的磁盤 滿了的話，我可以添加一組 圖片服務(wù)器域名 ，將以前的 域名從上傳前端去除，這樣，就可以實現(xiàn) 只讀不寫的功能，而且不用帶來遷移的問題。
同時，由于上傳的用戶，大部分肯定是活躍用戶，所以，我們可以將現(xiàn)在上傳使用的 這組 圖片服務(wù)器域名對應(yīng)的機器以及它的cache集群，使用性能比較好的機器來頂，這樣，就解決了最活躍的用戶，讓他的訪問速度，比不活躍用戶訪問速度要快。
然后按照時間，一年或者半年一次輪詢切換最新使用的圖片上傳域名，也不會出現(xiàn)圖片遷移的問題。
?
以上純屬 自己的看法，如有錯誤，請留言指教。http://blog.csdn.net/iinel/article/details/4669448
轉(zhuǎn)載于:https://www.cnblogs.com/seanxyh/archive/2013/04/16/3023452.html
總結(jié)
以上是生活随笔為你收集整理的T级图片数据Cache思路以及图片服务器搭建方法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 数据结构与算法-ADT-Array
- 下一篇： 试用百度云计算平台