|
|
4.2 Taobao File System- l& u1 F2 @2 F) C) |& q' J
互联网应用经常需要存储用户上传的文档、图片、视频等，比如Facebook相
: s: N9 K. I; j册、淘宝图片、Dropbox文档等。文档、图片、视频一般称为Blob数据，存储Blob数
9 T7 o4 C: m" Y/ x7 M A" a据的文件系统也相应地称为Blob存储系统。每个Blob数据一般都比较大，而且多个( q) R/ ^4 A d3 Z
Blob之间没有关联。Blob文件系统的特点是数据写入后基本都是只读，很少出现更
' @- o7 y4 j5 S9 i新操作。这两节分别以Taobao File System和Facebook Haystack为例说明Blob文件系统$ B2 B" y6 s6 o1 b
的架构。
9 U6 @& i/ H0 e" Z! O4 T2007年以前淘宝的图片存储系统使用了昂贵的NetApp存储设备，由于淘宝数据1 w+ d5 W) q& D1 o! B" Z
量大且增长很快，出于性能和成本的考虑，淘宝自主研发了Blob存储系统Tabao File
: c$ j- I+ J9 I: ~0 ]0 eSystem（TFS）。目前，TFS中存储的图片规模已经达到百亿级别。
- h9 @2 e' j- V( HTFS架构设计时需要考虑如下两个问题：
& n- O( k U' {●Metadata信息存储。由于图片数量巨大，单机存放不了所有的元数据信息，假
3 [0 t1 {& r! k0 D/ Y: _设每个图片文件的元数据占用100字节，100亿图片的元数据占用的空间为
0 P5 v& n/ L! I10G×0.1KB=1TB，单台机器无法提供元数据服务。
7 z: _% \. J8 v3 r" T% n, ]●减少图片读取的IO次数。在普通的Linux文件系统中，读取一个文件包括三次
. @ y- @5 L) s, h磁盘IO：首先读取目录元数据到内存，其次把文件的inode节点装载到内存，最后读0 P, O2 G) E, c
取实际的文件内容。由于小文件个数太多，无法将所有目录及文件的inode信息缓存5 y4 g- d* P' V1 O+ \( R q
到内存，因此磁盘IO次数很难达到每个图片读取只需要一次磁盘IO的理想状态。
3 g% P7 v; p* F- Z2 Z因此，TFS设计时采用的思路是：多个逻辑图片文件共享一个物理文件。
4 }5 q7 n; @) D; K, q: w4.2.1 系统架构+ a2 Y+ t3 r' |
TFS架构上借鉴了GFS，但与GFS又有很大的不同。首先，TFS内部不维护文件1 A% c, i- s' j/ T' W- f# `
目录树，每个小文件使用一个64位的编号表示；其次，TFS是一个读多写少的应用，1 F( W' d' q$ }8 }, t! l
相比GFS,TFS的写流程可以做得更加简单有效。
4 d! u$ p+ v/ ? J; I" r如图4-4所示，一个TFS集群由两个NameServer节点（一主一备）和多个4 ]) }1 A( Q9 @. \* [
DataServer节点组成，NameServer通过心跳对DataSrver的状态进行监测。NameServer
; A/ v: \% p% o" I# Z2 Y相当于GFS中的Master,DataServer相当于GFS中的ChunkServer。NameServer区分为主/ [2 }1 e6 C8 S6 A) l. k7 S
NameServer和备NameServer，只有主NameServer提供服务，当主NameServer出现故障
" O. A+ [! E5 ]1 H8 ~8 f( _( H时，能够被心跳守护进程检测到，并将服务切换到备NameServer。每个DataServer上6 |2 t3 D& C' O- }- ` j4 E$ Z. L
会运行多个dsp进程，一个dsp对应一个挂载点，这个挂载点一般对应一个独立磁盘，2 D9 x) L5 G5 @. z
从而管理多块磁盘。1 W1 S' ?2 n7 |5 {: u
图 4-4 TFS整体架构
0 v; I5 y% u2 p/ ]在TFS中，将大量的小文件（实际数据文件）合并成一个大文件，这个大文件称3 M0 ^8 n6 u% F _
为块（Block），每个Block拥有在集群内唯一的编号（块ID），通过＜块ID，块内偏
6 L" ~" P5 ^. M. o9 i7 i移＞可以唯一确定一个文件。TFS中Block的实际数据都存储在DataServer中，大小一
$ E: ~- D' H2 ?/ }9 j般为64MB，默认存储三份，相当于GFS中的chunk。应用客户端是TFS提供给应用程
- @7 Q8 @3 [, N. C序的访问接口，应用客户端不缓存文件数据，只缓存NameServer的元数据。
- m# V1 l+ T# D7 c* P G" i/ K( c1.追加流程
: E& T& f) T K7 M3 L tTFS中的追加流程相比GFS要简单有效很多。GFS中为了减少对Master的压力， C6 q: l$ ~, y9 @
引入了租约机制，从而将修改权限下放到主ChunkServer，很多追加操作都不需要
9 i a% _3 P$ V& k5 q. wMaster参与。然而，TFS是写少读多的应用，即使每次写操作都需要经过NameNode
+ z( G/ K: g% q3 O$ [也不会出现问题，大大简化了系统的设计。另外，TFS中也不需要支持类似GFS的多8 S4 J4 W' x% y: N: D; ^% Y) R2 r- p
客户端并发追加操作，同一时刻每个Block只能有一个写操作，多个客户端的写操作
$ _' l# y8 X3 M会被串行化。
- ^% h) g6 R% b+ N+ s: m如图4-5所示，客户端首先向NameServer发起写请求，NameServer需要根据
3 h" d+ y4 b) g; v+ h3 A: gDataServer上的可写块、容量和负载加权平均来选择一个可写的Block，并且在该
* Q4 I, K/ M, t% T& w% `1 F$ mBlock所在的多个DataServer中选择一个作为写入的主副本（Primary），其他的作为
: U" [ }+ l3 C: O6 J6 w' T备副本（Secondary）。接着，客户端向主副本写入数据，主副本将数据同步到多个+ ]2 ?4 {% ?5 |- r
备副本。如果所有的副本都修改成功，主副本会首先通知NameServer更新Block的版" L/ l# [6 n: C. {* t
本号，成功以后才会返回客户端操作结果。如果中间发生任何错误，客户端都可以) B6 [/ A( x/ f, Y$ H6 w+ Q3 l) K) m
从第一步开始重试。相比GFS,TFS的写流程不够优化，第一，每个写请求都需要多次
: D* \# g' ^- l5 z( m- |% b; n& c( Y访问NameServer；第二，数据推送也没有采用流水线方式减小延迟。淘宝的系统是/ u D: i6 Z' s
需求驱动的，用最简单的方式解决用户面临的问题。
6 Z9 F' ^; ]/ g5 F图 4-5 TFS追加流程 I! ~, s6 x. u6 s; J, m" x& J
每个写操作返回后，会返回客户端两个信息，小文件在TFS中的Block编号
7 k* c" n5 d( _2 q5 I（Block id）以及Block偏移（Block offset）。应用系统会将这些信息保存到数据库
0 a- |) G! U F# T- z4 W! z中，图片读取的时候首先根据Block编号从NameServer查找Block所在的DataServer，* E7 [% e7 }( A/ n# `
然后根据Block偏移读取图片数据。TFS的一致性模型保证所有返回给客户端的＜7 ]# h3 x( M, v' H- [- d; x
Blockid,Block offset＞标识的图片数据在TFS中的所有副本都是有效的。* z2 N: V- r9 d
2.NameServer6 p( v9 H) c* p' w
NameServer主要功能是：Block管理，包括创建、删除、复制、重新均衡；Data-" n& J" {' d) I! M2 x1 i# s& S
Server管理，包括心跳、DataServer加入及退出；以及管理Block与所在DataServer之
; {/ k' ?, j7 h- a! _间的映射关系。与GFS Master相比，TFS NameServer最大的不同就是不需要保存文件
& S n a- D% Z0 p5 |( @3 ?2 c目录树信息，也不需要维护文件与Block之间的映射关系。
) F. M0 V6 o( g- o2 x! x, s" B+ ]NameServer与DataServer之间保持心跳，如果NameServer发现某台DataServer发. _. X2 M/ U2 \; r7 p
生故障，需要执行Block复制操作；如果新DataServer加入，NameServer会触发Block
: e* [" j5 p% v" w/ L( X负载均衡操作。和GFS类似，TFS的负载均衡需要考虑很多因素，如机架分布、磁盘
6 u% O& D7 M, x. d2 I利用率、DataServer读写负载等。另外，新DataServer加入集群时也需要限制同时迁$ y( a8 O, K" v( z6 s7 _
入的Block数量防止被压垮。2 N' q; t$ {3 v' n
NameServer采用了HA结构，一主一备，主NameServer上的操作会重放至备
5 X& |, n ]* \; V" F, rNameServer。如果主NameServer出现问题，可以实时切换到备NameServer。
0 b0 B( i, b5 j, c9 C/ `/ j4.2.2 讨论+ Y- G. A% T; U1 H4 b& k
图片应用中有几个问题，第一个问题是图片去重，第二个问题是图片更新与删
7 h2 n+ Y$ k) B, ]# m除。
' c/ m; _) f* m/ `由于用户可能上传大量相同的图片，因此，图片上传到TFS前，需要去重。一般/ o1 L* ~- V6 w0 N+ r# _: s
在外部维护一套文件级别的去重系统（Dedup），采用MD5或者SHA1等Hash算法为
; N( S) _( Q( n+ d* D6 q# |图片文件计算指纹（FingerPrint）。图片写入TFS之前首先到去重系统中查找是否存
- O0 b0 ~# Q3 W* ]! i. F( {在指纹，如果已经存在，基本可以认为是重复图片；图片写入TFS以后也需要将图片" V+ w' k9 y4 \ G
的指纹以及在TFS中的位置信息保存到去重系统中。去重是一个键值存储系统，淘宝+ S, n3 S- e: v* ^4 q; u* L
内部使用5.2节中的Tair来进行图片去重。; G8 ]* p9 @8 _; B% ~
图片的更新操作是在TFS中写入新图片，并在应用系统的数据库中保存新图片的: Z/ ^* R4 ]: P( Y
位置，图片的删除操作仅仅在应用系统中将图片删除。图片在TFS中的位置是通过＜
( B H$ B/ }1 f* W. Q2 {2 p( C8 FBlock id,Block offset＞标识的，且Block偏移是在Block文件中的物理偏移，因此，每2 K- A% Y! f6 ]6 l
个Block中只要还有一个有效的图片文件就无法回收，也无法对Block文件进行重整。
& f2 d& R6 X3 ?& B& T" R如果系统的更新和删除比较频繁，需要考虑磁盘空间的回收，这点会在Facebook8 _, L- k; g8 n5 L
Haystack系统中具体说明。
9 t) n! r+ }. B$ E# p# h9 e* o
; T7 Q/ ~1 [0 J2 O' y. c" G. z- ~# f7 U6 M5 H
|
|
发表于 2017-3-3 20:23:20
