|
4.3 Facebook Haystack
! P7 \) H% v1 V- }" NFacebook目前存储了2600亿张照片,总大小为20PB,通过计算可以得出每张照
4 O; M/ c: `: d% Q% q1 O' P片的平均大小为20PB/260GB,约为80KB。用户每周新增照片数为10亿(总大小为
3 N* Q+ \& e5 a: q60TB),平均每秒新增的照片数为10 9 /7/40000(按每天40000s计),约为每秒3500! B2 V) g, R2 l; r* T% C6 w/ a
次写操作,读操作峰值可以达到每秒百万次。- F7 Q6 y4 z* f5 o Y# U, H
Facebook相册后端早期采用基于NAS的存储,通过NFS挂载NAS中的照片文件来* ?- W" m7 [& n( D( k
提供服务。后来出于性能和成本考虑,自主研发了Facebook Haystack存储相册数据。! A; R% f1 K3 a' [7 z' m9 c
4.3.1 系统架构% H4 V! y% w4 ^5 r# s
Facebook Haystack的思路与TFS类似,也是多个逻辑文件共享一个物理文件。8 ]! W# M0 A- K2 V9 ]$ m
Haystack架构及读请求处理流程如图4-6所示。
( m: E! o! p/ z7 m% Y7 W" S图 4-6 Haystack架构图
0 ?$ c' L* L( D5 y( ?* vHaystack系统主要包括三个部分:目录(Directory)、存储(Store)以及缓存1 _0 t7 r L& J% Y1 W" L) r
(Cache)。Haystack存储是物理存储节点,以物理卷轴(physical volume)的形式组& A0 @8 s) U0 y1 x( B- @9 v
织存储空间,每个物理卷轴一般都很大,比如100GB,这样10TB的数据也只需100个# R( j; Y/ Q! e, d* k1 _% G- t4 i
物理卷轴。每个物理卷轴对应一个物理文件,因此,每个存储节点上的物理文件元
6 {2 q; y3 L( K' d数据都很小。多个物理存储节点上的物理卷轴组成一个逻辑卷轴(logical6 @; L E4 Y: Z9 R6 O
volume),用于备份。Haystack目录存放逻辑卷轴和物理卷轴的对应关系,以及照片) p8 g, ^/ F! D4 | t: `+ ^) `
id到逻辑卷轴之间的映射关系。Haystack缓存主要用于解决对CDN提供商过于依赖的
2 U4 x4 Z, F/ X% X, D; o问题,提供最近增加的照片的缓存服务。6 H4 r# {; k: n8 ~
Haystack照片读取请求大致流程为:用户访问一个页面时,Web服务器请求6 |: O+ S5 P' `# q" {1 ^
Haystack目录构造一个URL:http://<CDN>/<Cache>/<Machine id>/<Logical, N+ [( U a" e& C ]
volume,Photo>,后续根据各个部分的信息依次访问CDN、Haystack缓存和后端的
! j( g7 l- D" e) Q* y, FHaystack存储节点。Haystack目录构造URL时可以省略<CDN>部分从而使得用户直
, O) `3 d; o% T; H4 j3 G# h接请求Haystack缓存而不必经过CDN。Haystack缓存收到的请求包含两个部分:用户
8 C9 p# k; N+ t4 X' Y- R% a浏览器的请求及CDN的请求,Haystack缓存只缓存用户浏览器发送的请求且要求请求
; {( Z1 h- @/ {% h7 f. L的Haystack存储节点是可写的。一般来说,Haystack后端的存储节点写一段时间以后
) ^0 I) M3 `1 Q% B% ]- K达到容量上限变为只读,因此,可写节点的照片为最近增加的照片,是热点数据。
7 f7 G7 K5 a% H( U本节暂不讨论CDN,只讨论Haystack后端存储系统,包括Haystack目录和Haystack缓
# ^3 a$ X6 l |: b1 Z* S存两个部分。
1 F2 A" ]7 y" R" J- b8 B) e( z1.写流程2 |, r) W7 A, w) ?* w/ e* r; W
如图4-7所示,Haystack的写请求(照片上传)处理流程为:Web服务器首先请求) \3 w% z9 z3 `2 B L
Haystack目录获取可写的逻辑卷轴,接着生成照片唯一id并将数据写入每一个对应的) b: }, C' U) K
物理卷轴(备份数一般为3)。写操作成功要求所有的物理卷轴都成功,如果中间出
! q( Y4 B/ F5 q) ^现故障,需要重试。( S5 R, Y! { x: ~% t( d! F) X+ w
图 4-7 Haystack写流程3 k! s) K9 z# }* R
Haystack的一致性模型保证只要写操作成功,逻辑卷轴对应的所有物理卷轴都存1 N; [! g4 b) V, z: G
在一个有效的照片文件,但有效照片文件在不同物理卷轴中的偏移(offset)可能不
; | w- I9 I; ~. a" n同。3 i4 e) P9 G! U9 P8 k
Haystack存储节点只支持追加操作,如果需要更新一张照片,可以新增一张编号
8 ^$ T, S9 E5 v$ ]0 p9 m$ C# w相同的照片到系统中,如果新增照片和原有的照片在不同的逻辑卷轴,Haystack目录* J+ Z; ^, }5 P% i: t. c) A
的元数据会更新为最新的逻辑卷轴;如果新增照片和原有的照片在相同的逻辑卷. I9 K8 y7 _3 J; P' c" G
轴,Haystack存储会以偏移更大的照片文件为准。9 O5 r) h2 u5 j0 k- ] L
2.容错处理
5 f/ l7 c* d+ @(1)Haystack存储节点容错
9 S4 b: v2 c W% `; v检测到存储节点故障时,所有物理卷轴对应的逻辑卷轴都被标记为只读。存储, R/ f$ t- T7 b
节点上的未完成的写操作全部失败,写操作将重试;如果发生故障的存储节点不可! c: |: W, V2 W h8 K; J
恢复,需要执行一个拷贝任务,从其他副本所在的存储节点拷贝丢失的物理卷轴的2 ]) P( H( n/ l# Y
数据;由于物理卷轴一般很大,比如100GB,所以拷贝的过程会很长,一般为小时
* D/ }* n1 j- E& `/ [级别。
' y' z6 X& a- F; B4 |& ^(2)Haystack目录容错- ]9 b( @- A+ u0 X( S+ }
Haystack目录采用主备数据库(Replicated Database)做持久化存储,由主备数据; I% o% y3 x& B: z2 z
库提供容错机制。' l; x' a' l0 a: Y
3.Haystack目录
, B& ]* m. S- A6 G2 DHaystack目录的功能如下:! x$ a' X8 P) M9 H5 S6 A
1)提供逻辑卷轴到物理卷轴的映射,维护照片id到逻辑卷轴的映射;
8 t9 I2 b4 a' {+ d! |5 j2)提供负载均衡,为写操作选择逻辑卷轴,读操作选择物理卷轴;
5 p# b7 [4 a9 T. C7 {3)屏蔽CDN服务,可以选择某些图片请求直接走Haystack缓存;
# G: p5 u/ w* Q, H7 L- e4)标记某些逻辑卷轴为只读。
8 x4 Q1 l( I9 O" w根据前面的计算结果可知,Facebook相册系统每秒的写操作大约为3500次,每" R9 n' M2 Z4 R0 I
秒的读请求大约为100万次。每个写请求都需要通过Haystack缓存获取可写的卷轴,
- {% d: z+ N2 k. V- T9 I每个读请求需要通过Haystack缓存构造读取URL。这里需要注意,照片id到逻辑卷轴' H: v9 |0 }" b; A) J r D; M
的映射的数据量太大,单机内存无法存放,笔者猜测内部使用了MySQL Sharding集
" m( H0 O" e0 X- \& h群,另外,还增加了一个Memcache集群满足查询需求。+ |9 V2 b8 d( c O( Z" ]% R( f1 K g* s
4.Haystack存储
* H8 o* y, F: h2 x' p+ |$ n, e+ r- |Haystack存储保存物理卷轴,每个物理卷轴对应文件系统中的一个物理文件,每/ b6 X |, ?6 j* c" w5 l
个物理文件的格式如图4-8所示。
; u; g+ R; p+ x% l9 b& Y9 Y图 4-8 Haystack数据块格式# T+ P3 t3 R; }( A/ C
多个照片文件存放在一个物理卷轴中,每个照片文件是一个Needle,包含实际
; i. u" |+ X1 d( X数据及逻辑照片文件的元数据。部分元数据需要装载到内存中用于照片查找,包括
& W2 D# k8 L- eKey(照片id,8字节),Alternate Key(照片规格,包括Thumbnail、Small、Medium% _! K& c# Y* e$ Y
及Large,4字节),照片在物理卷轴的偏移Offset(4字节),照片的大小Size(4字2 {# R" Q S' _; _$ s& U% q
节),每张照片占用8+8+4=20字节的空间,假设每台机器的可用磁盘为8TB,照片8 h+ L3 O1 @6 b7 d5 |& i: c
平均大小为80KB,单机存储的照片数为8TB/80KB=100MB,占用内存
6 B9 W4 L! W; i7 \2 ^$ K2 f100MB×20=2GB。+ M1 I& z; m+ z4 S( T. y
存储节点宕机时,需要恢复内存中的逻辑照片查找表,扫描整个物理卷轴耗时
4 E% Q# w2 x" r: E8 m6 {+ }太长,因此,对每个物理卷轴维护了一个索引文件(Index File),保存每个Needle7 \3 _9 x4 D. P- L6 d9 W) [
查找相关的元数据。写操作首先更新物理卷轴文件,然后异步更新索引文件。由于
/ }3 H. W! x7 G; v1 g更新索引文件是异步的,所以可能出现索引文件和物理卷轴文件不一致的情况,不
; X( G* N) ~; ?' M2 c: G过由于对物理卷轴文件和索引文件的操作都是追加操作,只需要扫描物理卷轴文件
* z7 x1 r) t) X( p最后写入的几个Needle,然后补全索引文件即可。这种技术在仅支持追加的文件系9 `9 G9 v( Y! E, V7 N T7 A& k+ W
统很常见。
* n! |0 `- `! CHaystack Store存储节点采用延迟删除的回收策略,删除照片只是向卷轴中追加. y; Z) n% G0 E6 C- z
一个带有删除标记的Needle,定时执行Compaction任务回收已删除空间。所谓. p, l, k0 G5 Y% K+ V6 f
Compaction操作,即将所有老数据文件中的数据扫描一遍,以保留最新一个照片的原
0 n5 S7 W& F5 g3 E( K则进行删除,并生成新的数据文件。
) m3 M+ ~) {. ~+ S' m( l) ]4.3.2 讨论$ u; d, g- }- I b6 P5 ]
相比TFS,Haystack的一大特色就是磁盘空间回收。Blob文件在TFS中通过<Block
# B$ H7 b6 _, i: P+ X1 |2 ~id,Block offset>标识,因此,不能对TFS中的数据块进行重整操作;而Haystack中的
. f8 `: o; r: h元信息只能定位到Blob文件所在的逻辑卷轴,Haystack存储节点可以根据情况对物理0 k# `, W: r) ?' @$ a
卷轴进行Compaction操作以回收磁盘空间。
) a& X: P! Q0 X d/ ?; PFacebook Haystack中每个逻辑卷轴的大小为100GB,这样减少了元信息,但是增
' n! C- f. K) p4 C. [+ I/ D加了迁移的时间。假设限制内部网络带宽为20MB/s,那么迁移100GB的数据需要的5 `6 P5 o( S1 m. l# k
时间为100GB/20MB/s=5000s,大约是一个半小时。而TFS设计的数据规模相比
I0 G9 b8 K$ cHaystack要小,因此,可以选择64MB的块大小,有利于负载均衡。
# Q- X: k, N2 s( W w另外,Haystack使用RAID 6,并且底层文件系统使用性能更好的XFS,淘宝TFS h8 s) v) e' e/ X) Y, q( B5 D
不使用RAID机制,文件系统使用Ext3,由应用程序负责管理多个磁盘。Haystack使用( @2 I! W" y9 [8 c' p9 q
了Akamai&Limelight的CDN服务,而淘宝已经使用自建的CDN,当然,Facebook也在$ F- W; h6 Q( b, u8 c0 }
考虑自建CDN。
: P# q) O5 L4 l$ _
, P6 ~" [2 U$ T
M5 e. }. c) s) b7 ]8 X+ C |
|