Facebook图片存储系统Haystack

Facebook图片存储系统Haystack

一篇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即可。 从而显著提高性能。

haystack架构

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

架构比较简单，分为三部份：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 中。