Facebook Haystack图片存储架构(2)

发表于:2013-12-06来源:IT博客大学习作者:chuanhui点击数: 标签:Facebook
存储节点宕机时,需要恢复内存中的图片查找元信息表,扫描整个物理卷轴耗时太长,因此,对每个物理卷轴维护了一个索引文件(Index File),保存每个Ne

  存储节点宕机时,需要恢复内存中的图片查找元信息表,扫描整个物理卷轴耗时太长,因此,对每个物理卷轴维护了一个索引文件(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