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集群，使用性能比较好的机器来顶，这样，就解决了最活跃的用户，让他的访问速度，比不活跃用户访问速度要快。

然后按照时间，一年或者半年一次轮询切换最新使用的图片上传域名，也不会出现图片迁移的问题。

以上纯属 自己的看法，如有错误，请留言指教。