图片服务器选型方案

  各个web项目要共享各种图片素材、手机软件，同时也需要处理用户自助上传的图片、软件在各个项目间的共享。采用了独立的图片服务器来集中存储各种图片资源，其他应用服务器通过NFS方式存取图片资源（ 在linux下使用nfs及软链接解决图片文件共享问题 ）。起初觉得这种模式相对简单且容易实现，也不是很在意图片服务器的容灾问题，最近在部署应用时候没有按照步骤操作，直接把通过NFS方式共享的目录删除了（由于要在应用上传图片时候实时同步到图片服务器上，因此NFS目录是read、write的），这才意识到容灾的问题。
    在当前的经济形势下，遵循“少花钱、多办事”的原则，采用纯Open Source的方案，不增加硬件及软件投入。简单整理了一下图片服务器的实现时候需要考虑的几个地方：

1、操作文件系统的选择：    非分布式文件系统方案：ReiserFS4、 Ext3 、JFS
    分布式文件系统方案：Redhat GFS、Lustre、ZFS、NFS

2、数据同步    采用操作系统层分布式文件系统本身的同步功能
    采用应用层分布式文件系统同步方案： FastDFS 、 MogileFS 、 Hadoop HDFS
    采用应用层第三方软件同步方案：csync2+inotify、 rsync 、 unison 、 DRBD 、 tsync

3、Web服务器的选择：     采用轻量级的Lighttpd、Nginx ，不采用apache4、Cache及反向代理：    
   Squid  Lighttpd+mod_mem_cache

5、单独多个图片服务器、单独的图片服务器域名6、数据压缩：     HTTP HEADER的Accept-Encoding

7、客户端缓存：     HTTP HEADER的Expires、Cache-Control、Etag、Last-Modified参数设置

8、应用层优化：    图片按需生成、图片预先生成、根据应用场景降低图片分辨率

采用 ReiserFS4+csync2+inotify 方案来满足当前需要，后续有空再测试一下 FastDFS 、 MogileFS 、 Hadoop HDFS   的方案。

Technorati 标签: 图片服务器,高性能服务器,csync2,inotify,lighttpd,hadoop,分布式文件系统,选型