H.E.'s Blog

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

除此之外，还需要能做到：
  1.使用廉价机器(老机器)构建分布式网络存储环境，支持150TB以上的存储容量，
  2.数据在线同步，支持文件副本复制，无明显的单点问题，可快速恢复故障节点，
  3.通用文件系统，不需要修改上层应用就可以使用(支持fuse)，web服务器可以直接读取分布式存储空间，无中间转取。
  4.支持在线不停机的情况下扩展存储的空间，
  5.随机读写的高效，并且支持海量小文件(5kb)的高效读写，
  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–