Facebook Haystack图片存储架构(2)

　　存储节点宕机时，需要恢复内存中的图片查找元信息表，扫描整个物理卷轴耗时太长，因此，对每个物理卷轴维护了一个索引文件(Index File)，保存每个Needle查找相关的元数据。写操作首先更新物理卷轴文件，然后异步更新索引文件。由于更新索引文件是异步的，可能出现索引文件和物理卷轴文件不一致的情况，不过由于对物理卷轴文件和索引文件的操作都是Append操作，只需要扫描物理卷轴文件最后写入的几个Needle补全索引文件即可。这种技术在Append-only的文件系统很常见。

　　Haystack Store存储节点采用延迟删除的回收策略，删除图片仅仅往卷轴中追加一个带有删除标记的Needle，定时执行Compaction任务回收已删除空间。

　　异常处理

　　可能出现的异常包括：

　　1, Haystack Store存储节点宕机：存储节点宕机时，存储节点上的未完成的写操作全部失败，客户端将重试;如果宕机的存储节点不可恢复，需要执行一个拷贝任务，从相应的备份机器上拷贝丢失的物理卷轴数据;由于物理卷轴一般很大，比如100GB，所以拷贝的过程会很长，一般为小时级别。

　　2, 写操作失败：客户端需要写逻辑卷轴对应的多个物理卷轴，所有备份全部写成功才算成功，否则不断重试。同一个物理卷轴可能多次写入同一个图片，类似GFS中的重复记录：对于每个成功的写操作，Haystack Store只需要保证每个物理卷轴至少写成功一次即可，Haystack Store存储节点对记录去重。

　　与其它系统的比较

　　Taobao TFS及CDN系统：Facebook Haystack和Taobao TFS都是解决大量的小图片文件的问题，因此架构很类似，不同点包括逻辑卷轴大小的选择，比如Haystack选择100GB的逻辑卷轴大小，TFS中 block大小一般为64MB;Haystack使用RAID 6，且底层文件系统使用性能更好的XFS，淘宝后期摈除了RAID机制，文件系统使用Ext3;Haystack使用了Akamai & Limelight的CDN服务，而Taobao已经使用自建的CDN，当然，Facebook也在考虑自?DN。Facebook Haystack及Taobao TFS这样的文件系统一般称为Blob文件系统。

　　GFS系统：Haystack Store的每个存储节点相当于一个Chunk Server，物理卷轴相当于一个Chunk。Haystack Directory相当于GFS Master。GFS系统的难点在于Append流程及动态分配Chunk的写Lease，而在Haystack这样的Blob系统中可以回避这样的问题，后续将专门详细论述Blob文件系统和GFS的差别。

原文转自：http://blogread.cn/it/article/3127?f=wb