山寨技术下的网站图片服务器

On 2011年04月9日, in linux, by netoearth

作者: H.E. | 您可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.javabloger.com/article/nginx-moosefs-hbase-haproxy.html

网站数据存储需要做好前期的规划,不然数据量上来以后无论是管理还是性能上都带来很多问,存储大量的文件、图片对一个中小网站来说也算是一个重点的 话题。网页的文字内容和网页上的图片所占用的存储空间相比较,显然图片存储占用的空间要远远超过网站文字内容存储的空间,从另外一个角度上来看访问图片所 占用的网络带宽要远远超过文字内容所占用的带宽。
在系统运行上的瓶颈对于互联网用户来说往往不是落在我们系统内部计算的I/O瓶颈上,而且落在了网络带宽的瓶颈上。如果把存储图片的服务器和访问的网络入 口独立出来,在条件允许的情况下给予图片访问的网络资源更高的带宽和独立的域名,这对于网站的扩展性和的性能很有帮助,把存储和带宽的资源做到合理分配, 并且互不影响速度和性能。

除此之外,还需要能做到:
1.使用廉价机器(老机器)构建分布式网络存储环境,支持150TB以上的存储容量,
2.数据在线同步,支持文件副本复制,无明显的单点问题,可快速恢复故障节点,
3.通用文件系统,不需要修改上层应用就可以使用(支持fuse),web服务器可以直接读取分布式存储空间,无中间转取。
4.支持在线不停机的情况下扩展存储的空间,
5.随机读写的高效,并且支持海量小文件(5k)的高效读写,
6.可监控运行时的存储使用状态,最好是web界面。

到了一些个解决方案,但我们依然不满足,对存储本身还有更高的期望:
1.需要避免图片文件重复的写入,建立图片存储的索引,根据唯一的图片文件名的查询后,再判断是否写入,
2.小图片,签名照,小头像,表情图片 放在缓存里读取,让数据更靠近cpu,设计的黄金原则,以我们尽量的让能放入Redis缓存中的数据就在Redis里读取。

架构介绍
1.负载均衡:HAproxy采用RoundRobin负载均衡算法,分载前端用户请求的压力到每个web图片服务器上,
2.web服务:采用Nginx-0.9.6 做图片的web服务器,对网站的大、中、小图片进行读取,加上Nginx的Redis模块对缓存中的微型(头像)图片进行读取,
3. 缓存服务器:存储网站的 微型图片,签名照,小头像,表情图片,通过Nginx的Redis模块直接读取,通过调用Redis的java API程序对数据进行写入,
4.存储单元:采用Moosefs 存储  大、中、小图片,并且提供监控管理界面,查看存储空间运行状态,
5.文件索引:将图片名和图片url路径作为键值对(Key/Value),放入HBase 中存储,并且进行数据查询,避免图片重复存储,
6.应用服务器:对图片进行写入的操作全部由Java应用服务器完成。

关系我们目前使用的图片存储的系统架构如图所示:

关于HBase的话题在这里就不多说了,可以参考我之前写的几篇文件文章,主要想说说Moosefs的体系
1 Master 管理服务器:负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复.多节点拷贝
2 Chunk 元数据日志服务器: 负责备份master服务器的变化日志文件,文件类型为changelog_ml.*.mfs,以便于在master server出问题的时候接替其进行工作
3 Metalogger  数据存储服务器:负责连接管理服务器,听从管理服务器调度,提供存储空间,并为客户提供数据传输.
4 Client  客户端: 通过fuse内核接口挂接远程管理服务器上所管理的数据存储服务器,看起来共享的文件系统和本地unix文件系统使用一样的效果.

最有代表性的成功案例
豆瓣网(Douban Inc),155 TB的存储空间,
Master server: Gentoo Linux / ReiserFS 3.6
24 chunk servers: Gentoo Linux / ReiserFS / XFS
3 metalogger(s): Gentoo Linux / ReiserFS 3.6
37 client machines: Gentoo Linux

其实,采用某种技术只是一种具体实现的手段,或许从外界的统计数据来看 mogileFS、ceph、FastDFS 等其他产品具有更高的读写性能,甚至可以到满足我上述的任何一项要求,但我们所关注的侧重点不一样,要需要简单,易上手,够用就行,所以在这里利用 Moosefs做了一个抛砖引玉。

–end–

Tagged with:  

Comments are closed.