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

最新推荐文章于 2025-09-05 10:26:29 发布

原创最新推荐文章于 2025-09-05 10:26:29 发布 · 8.3k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#cache #服务器 #集群 #server #磁盘 #nginx

系统服务架构专栏收录该内容

3 篇文章

订阅专栏

通过 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 一小组之类的。

图有可能是如下所示：

（三）
有一遍关于 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.youkuaiyun.com/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集群，使用性能比较好的机器来顶，这样，就解决了最活跃的用户，让他的访问速度，比不活跃用户访问速度要快。
然后按照时间，一年或者半年一次轮询切换最新使用的图片上传域名，也不会出现图片迁移的问题。

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