一篇14页的论文Facebook-Haystack， 看完之后我的印象里就四句话：

• 因为【传统文件系统的弊端】
• 因为【缓存无法解决长尾问题】
• 所以【多个图片信息(Needle)存在同一个文件(SuperBlock)中】
• 所以【显著提高性能】

传统文件系统的弊端

传统的 POSIX 文件系统不适合高性能的图片存储， 主要原因是基于该文件系统来存储的话，是讲每个图片存储成某目录下的一个文件， 每次读取文件的时候需要有N次磁盘IO，当目录下文件数是K级别是， 读取一次文件需要超过10次的文件IO，即使目录下的文件数是0.1K级别时， 也需要3次的文件IO（1:读取目录元数据,2:读取inode,3:读取文件内容）。

缓存无法解决长尾问题

图片存储的应用场景如图：

在 PhotoStorage 之前还有一些 CDN 保驾护航， CDN 就是靠缓存吃饭的，对于那些热门的图片都能被 CDN 很好的缓存下来， 所以需要访问的 PhotoStorage 一般都是非热门图片， 所以在这样的场景之下， 在 PhotoStorage 改进缓存显然是无法解决问题的。 你懂的，缓存对于长尾问题基本上都是束手无策的。 因为如果缓存能解决的问题，就不叫长尾问题了。

多个图片信息存在同一个文件中

每次读取一个图片需要多次磁盘IO的原因是因为一个图片存成一个文件， 文件系统里面每次读取文件需要先读取文件的元信息等，导致多次磁盘IO， 而当我们将多个图片信息存在同一个文件中， 当然这个文件会很大， 然后在内存中存储该图片存储在文件中的偏移地址和图片大小， 所以每次读取图片的时候， 根据偏移地址直接读取读取， 大部分情况下能做到只需要一次磁盘IO即可。 从而显著提高性能。

转载请注明出处: Facebook图片存储系统Haystack

基于这个思想，haystack 设计者绕过了 POSIX 文件系统这块，把 haystack 变成了一个 KV FS，即 NOFS。每个图片对应一个 FID，不再单独存放文件系统中，而是同一个物理卷 Volume 图片全部写入一个文件中，由 Volume Server 内存维护 FID : <Volume Machine, Offset, Size> 映射关系，Volume Server 内存中维护打开的文件句柄，读取图片时只需一次 IO 顺序读操作。

haystack架构图

架构比较简单，分为三部份：Haystack Directory, Haystack Cache, Haystack Store

Directory: 即所谓的 Meta Server

1. 生成 FID，维护 logical volume 与 physical volume 映射关系，解决上传时的负载均衡问题。

2. 新加入的 Store Server 要在这里注册。

3. 维护 logical volume 的 read-only 属性，只读的 logical volume 不再接受 upload 请求。

4. 决定请求走 CDN 还是内部 Haystack Cache Server.

Cache: 所谓的内部 CDN

1. 对图片 FID 采用一致性 hash 算法保存。

2. 只缓存用户请求，而不是来自 CDN 的请求。

3. 只缓存 write-enabled store 图片，由于上传的时间序，相当于只缓存最新生成的图片。比如说用户刚上传的图片，可能就会存到 Cache 中预热。

Store: 最终落地存储服务

1. 图片顺序追加到一个大文件中，内存中维护图片在文件中的 Offset 和 Size 的索引信息。

2. 为了解决重启快速加载问题，索引信息会单独保存到一个 Index File 中。