小兔网

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

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

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

一般可能还是把图片存储到文件系统里面 按照目录+ 文件的组织形式. 本地 或者 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. ...