图片服务器设计

其实我没有专业做过图片的服务器, 只做过通用的对象存储. 简单说一下个人理解吧. 

做为使用最广泛, 最最基础的图床服务, 业界几乎每家大点的公司可能都有自己的解决方案. 
具体到某一家厂商, 对于图片存储的需求的层次 决定 图片服务系统设计的结构, 简要的分几个层次吧:

初级: 还有些人在乎的中小网站. 

图片偏多, 需要简单的组织和管理. 

一般可能还是把图片存储到文件系统里面 按照目录+ 文件的组织形式. 本地 或者 NFS 的文件系统里面, 这里是我理解的一些小点: 

1. 不要使用中文, 空格, 特殊字符...之类的做文件名!!!
2. 对于UGC网站, 不拿用户上传的图片文件名做为文件名直接存储.
   1. 用户的文件名会各种不规范, 容易有冲突, 另外存起来.
3. 按 时间 / 用户 等业务逻辑做目录的划分.
   
   1. 更利于组织和管理, 避免冲突文件名导致覆盖(用户头像存储等Case).
   2. 也避免一个目录下文件过多, 导致查询性能
   3. 必要时可能要多级的目录.
4. 避免过长的文件名.
5. 避免修改文件内容
   1. 修改后的图片存为另一个图片
6. 为缩略图做预处理
   1. 最好是就只用特定的几个尺寸.
   2. 不能满足需求的话, 可以预存大, 中, 小, 原图等几个级, 其他尺寸由邻近级去实时转换.
7. 不同尺寸的文件, 而且大小之间可以相互换算. 
   
   1. Eg: 图片大小命名的目录.
8. 不要用连续递增的数字做文件id
   1. 避免图片被直接遍历爬走了
9. logo 等常用图片独立存储.
10. 避免文件路径的变更.
    1. 各处本地缓存, 引用 都会失效...

中级: 适合较大型的网站 

普通的文件系统已经不能很好满足需求了: 

1. 运维管理的考虑
   1. 超过单机的容易, 多机来存储导致各种图片的增减, 管理成本非常的大
2. 性能的考虑
   1. 文件系统的开销过大
   2. 多次的IO和网络交互
3. 成本的考虑
4. 容灾的考虑

这个一般使用 通用的对象存储, 类似S3的服务, 会增加一些CDN之类的. 
在组织管理这一块, 虽然不再是本地的文件系统, 但是原理和想法 和 前面基本一样. 


高级: 适合大型的网站

相对于更强调通用性和业务灵活性的S3存储服务, 图片服务的文件名一般都是专有的规则, 因为就这个单一的服务就已经足够的大, 值得去做一些专门的定制和优化. 

比如说: 

1. 存储信息直接Encode进文件名, 省去文件名到存储路径的查询.
2. 更好的缓存支持, CDN的调度
3. 极端热点的处理
4. 冷数据的淘汰和Archive
5. 专门的硬件支持 (针对图片访问特别的机器定制.)
6. ...

国内做得比较好的分享应该是 章文嵩 博士的. 详见: 
揭秘淘宝286亿海量图片存储与处理架构-IT168 存储专区 和 淘宝图片存储与CDN系统

国外的如Facebook的Haystack的设计. 
http://www.stanford.edu/class/cs240/readings/haystack.pdf 和 https://www.facebook.com/note.php?note_id=76191543919