《大规模分布式存储系统》 第4章 分布式文件系统【4.3】
4.3 Facebook HaystackFacebook目前存储了2600亿张照片，总大小为20PB，通过计算可以得出每张照
片的平均大小为20PB/260GB，约为80KB。用户每周新增照片数为10亿（总大小为
60TB），平均每秒新增的照片数为10 9 /7/40000（按每天40000s计），约为每秒3500
次写操作，读操作峰值可以达到每秒百万次。
Facebook相册后端早期采用基于NAS的存储，通过NFS挂载NAS中的照片文件来
提供服务。后来出于性能和成本考虑，自主研发了Facebook Haystack存储相册数据。
4.3.1 系统架构
Facebook Haystack的思路与TFS类似，也是多个逻辑文件共享一个物理文件。
Haystack架构及读请求处理流程如图4-6所示。
图 4-6 Haystack架构图
Haystack系统主要包括三个部分：目录（Directory）、存储（Store）以及缓存
（Cache）。Haystack存储是物理存储节点，以物理卷轴（physical volume）的形式组
织存储空间，每个物理卷轴一般都很大，比如100GB，这样10TB的数据也只需100个
物理卷轴。每个物理卷轴对应一个物理文件，因此，每个存储节点上的物理文件元
数据都很小。多个物理存储节点上的物理卷轴组成一个逻辑卷轴（logical
volume），用于备份。Haystack目录存放逻辑卷轴和物理卷轴的对应关系，以及照片
id到逻辑卷轴之间的映射关系。Haystack缓存主要用于解决对CDN提供商过于依赖的
问题，提供最近增加的照片的缓存服务。
Haystack照片读取请求大致流程为：用户访问一个页面时，Web服务器请求
Haystack目录构造一个URL：http://＜CDN＞/＜Cache＞/＜Machine id＞/＜Logical
volume,Photo＞，后续根据各个部分的信息依次访问CDN、Haystack缓存和后端的
Haystack存储节点。Haystack目录构造URL时可以省略＜CDN＞部分从而使得用户直
接请求Haystack缓存而不必经过CDN。Haystack缓存收到的请求包含两个部分：用户
浏览器的请求及CDN的请求，Haystack缓存只缓存用户浏览器发送的请求且要求请求
的Haystack存储节点是可写的。一般来说，Haystack后端的存储节点写一段时间以后
达到容量上限变为只读，因此，可写节点的照片为最近增加的照片，是热点数据。
本节暂不讨论CDN，只讨论Haystack后端存储系统，包括Haystack目录和Haystack缓
存两个部分。
1.写流程
如图4-7所示，Haystack的写请求（照片上传）处理流程为：Web服务器首先请求
Haystack目录获取可写的逻辑卷轴，接着生成照片唯一id并将数据写入每一个对应的
物理卷轴（备份数一般为3）。写操作成功要求所有的物理卷轴都成功，如果中间出
现故障，需要重试。
图 4-7 Haystack写流程
Haystack的一致性模型保证只要写操作成功，逻辑卷轴对应的所有物理卷轴都存
在一个有效的照片文件，但有效照片文件在不同物理卷轴中的偏移（offset）可能不
同。
Haystack存储节点只支持追加操作，如果需要更新一张照片，可以新增一张编号
相同的照片到系统中，如果新增照片和原有的照片在不同的逻辑卷轴，Haystack目录
的元数据会更新为最新的逻辑卷轴；如果新增照片和原有的照片在相同的逻辑卷
轴，Haystack存储会以偏移更大的照片文件为准。
2.容错处理
（1）Haystack存储节点容错
检测到存储节点故障时，所有物理卷轴对应的逻辑卷轴都被标记为只读。存储
节点上的未完成的写操作全部失败，写操作将重试；如果发生故障的存储节点不可
恢复，需要执行一个拷贝任务，从其他副本所在的存储节点拷贝丢失的物理卷轴的
数据；由于物理卷轴一般很大，比如100GB，所以拷贝的过程会很长，一般为小时
级别。
（2）Haystack目录容错
Haystack目录采用主备数据库（Replicated Database）做持久化存储，由主备数据
库提供容错机制。
3.Haystack目录
Haystack目录的功能如下：
1）提供逻辑卷轴到物理卷轴的映射，维护照片id到逻辑卷轴的映射；
2）提供负载均衡，为写操作选择逻辑卷轴，读操作选择物理卷轴；
3）屏蔽CDN服务，可以选择某些图片请求直接走Haystack缓存；
4）标记某些逻辑卷轴为只读。
根据前面的计算结果可知，Facebook相册系统每秒的写操作大约为3500次，每
秒的读请求大约为100万次。每个写请求都需要通过Haystack缓存获取可写的卷轴，
每个读请求需要通过Haystack缓存构造读取URL。这里需要注意，照片id到逻辑卷轴
的映射的数据量太大，单机内存无法存放，笔者猜测内部使用了MySQL Sharding集
群，另外，还增加了一个Memcache集群满足查询需求。
4.Haystack存储
Haystack存储保存物理卷轴，每个物理卷轴对应文件系统中的一个物理文件，每
个物理文件的格式如图4-8所示。
图 4-8 Haystack数据块格式
多个照片文件存放在一个物理卷轴中，每个照片文件是一个Needle，包含实际
数据及逻辑照片文件的元数据。部分元数据需要装载到内存中用于照片查找，包括
Key（照片id，8字节），Alternate Key（照片规格，包括Thumbnail、Small、Medium
及Large，4字节），照片在物理卷轴的偏移Offset（4字节），照片的大小Size（4字
节），每张照片占用8+8+4=20字节的空间，假设每台机器的可用磁盘为8TB，照片
平均大小为80KB，单机存储的照片数为8TB/80KB=100MB，占用内存
100MB×20=2GB。
存储节点宕机时，需要恢复内存中的逻辑照片查找表，扫描整个物理卷轴耗时
太长，因此，对每个物理卷轴维护了一个索引文件（Index File），保存每个Needle
查找相关的元数据。写操作首先更新物理卷轴文件，然后异步更新索引文件。由于
更新索引文件是异步的，所以可能出现索引文件和物理卷轴文件不一致的情况，不
过由于对物理卷轴文件和索引文件的操作都是追加操作，只需要扫描物理卷轴文件
最后写入的几个Needle，然后补全索引文件即可。这种技术在仅支持追加的文件系
统很常见。
Haystack Store存储节点采用延迟删除的回收策略，删除照片只是向卷轴中追加
一个带有删除标记的Needle，定时执行Compaction任务回收已删除空间。所谓
Compaction操作，即将所有老数据文件中的数据扫描一遍，以保留最新一个照片的原
则进行删除，并生成新的数据文件。
4.3.2 讨论
相比TFS,Haystack的一大特色就是磁盘空间回收。Blob文件在TFS中通过＜Block
id,Block offset＞标识，因此，不能对TFS中的数据块进行重整操作；而Haystack中的
元信息只能定位到Blob文件所在的逻辑卷轴，Haystack存储节点可以根据情况对物理
卷轴进行Compaction操作以回收磁盘空间。
Facebook Haystack中每个逻辑卷轴的大小为100GB，这样减少了元信息，但是增
加了迁移的时间。假设限制内部网络带宽为20MB/s，那么迁移100GB的数据需要的
时间为100GB/20MB/s=5000s，大约是一个半小时。而TFS设计的数据规模相比
Haystack要小，因此，可以选择64MB的块大小，有利于负载均衡。
另外，Haystack使用RAID 6，并且底层文件系统使用性能更好的XFS，淘宝TFS
不使用RAID机制，文件系统使用Ext3，由应用程序负责管理多个磁盘。Haystack使用
了Akamai＆Limelight的CDN服务，而淘宝已经使用自建的CDN，当然，Facebook也在
考虑自建CDN。
页:
[1]