T级图片数据Cache思路以及图片服务器搭建方法

通过 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