博客访问： 2656379
博文数量： 272
博客积分： 11197
博客等级： 上将
技术积分： 6706
注册时间：
认证徽章：
@HUST张友东
work@taobao
APP发帖 享双倍积分
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： 服务器与存储
TFS（Taobao File System）是一个高可用、高性能、高可扩展的分布式文件系统，基于普通的Linux服务器构建，主要提供海量非结构化数据存储服务。TFS被广泛地的应用在淘宝的各项业务中，目前已部署的最大集群存储文件数已近千亿。 TFS已在TaoCode上开源 (项目主页：http://code.taobao.org/p/tfs/src/)，提供给外部用户使用。
TFS集群由名字服务器（namserver）和数据服务器（dataserver）组成，TFS以数据块（block）为单位存储和组织数据，block大小通常为64M（可配置），TFS会将多个小文件存储在同一个block中，并为block建立索引，以便快速在block中定位文件；每个block会存储多个副本到不同的机架上，以保证数据的高可靠性。每个block在集群中拥有全局唯一的数据块编号（block id），block id由nameserver创建时分配，block中的文件拥有一个block内唯一的文件编号（file id），file id由dataserver在存储文件时分配，block id和file id组成的二元组唯一标识一个集群里的文件。
Nameserver服务部署时采用HA来避免单点故障，2台nameserver服务器共享一个vip。正常情况下，主nameserver持有vip提供服务，并将block修改信息同步至备，HA agent负责监控主备nameserver的状态，当其检测到主宕机时，HA agent将vip切换到备上，备就切换为主来接管服务，以保证服务的高可用。
Dataserver服务部署时通常会在一台机器上部署多个dataserver进程，每个进程管理一块磁盘，以便充分利用磁盘IO资源。Dataserver启动后，会向nameserver汇报其存储的所有block信息，并周期性的给nameserver发送心跳信息，nameserver则根据心跳来管理所有的dataserver，当nameserver超过一定时间没有收到dataserver的信息，则认为dataserver已经宕机，会将该dataserver上存储的block进行复制，使得block副本数不低于集群配置值，保证系统存储数据的可靠性。
Namserver上的所有元信息都保存在内存，并不进行持久化存储，dataserver启动后，会汇报其拥有的block信息给nameserver，nameserver根据这些信息来构建block到server的映射关系表，根据该映射关系表，为写请求分配可写的block，为读请求查询block的位置信息。Nameserver有专门的后台线程轮询各个block和server的状态，在发现block缺少副本时复制block（通常是由dataserver宕机导致的）；在发现dataserver负载不均衡时，迁移数据来保证服务器间的负载均衡。
TFS写文件流程如上图所示，nameserver在分配可写block时，简单的采用round robin的策略分配，这种策略简单有效，其他根据dataserver负载来分配的策略，实现上较复杂，同时由于负载信息不是实时的，根据过时的信息来分配block，实践证明其均衡效果并不好。当文件成功写到多个dataserver后，会向client返回一个由集群号、block id、file id编码而成的文件名，以后client通过该文件名即可从TFS访问到存储的文件，在dataserver上，每个block对应一个索引文件，索引中记录了block中每个文件在block内部的偏移位置以及文件的大小。
当client读取文件时，首先根据文件名解析出文件所在的block信息，从nameserver上查询block所在的dataserver信息，并向dataserver发送读请求，如果从某个副本读取失败，client会重试其他的副本；dataserver接收到client的读请求时，通过查找block的索引就能快速得到文件的位置，从block相应位置读取数据并返回给client。
当client删除TFS里的文件时，服务器端并不会立即将文件数据从block里删除掉，只是为文件设置一个删除标记，当一个block内被删除的文件数量超过一定比例时，会对block进行整理（compact），以回收删除文件占用的空间，删除任务通常在访问低峰期进行，以避免其对正常的服务造成影响。
Client负责完成读写删TFS文件的基本逻辑，并在失败时主动进行failover。为了提高client读取文件的效率、并降低nameserver的负载，client会将block到dataserver的映射关系缓存到本地，由于block到dataserver的映射关系一般只会在发生数据迁移的时候才会发生变化，所以一旦本地cache命中，大部分情况下都能从cache里获取到的dataserver上访问到文件，如果cache已经失效（block被迁移到其他dataserver），客户端最终会从nameserver获取block最新的位置信息，从最新的位置上读取文件。在实际应用中，通常客户端能使用的系统资源比较有限，能够用于本地缓存的内存并不大，而集群中block的数量有数千万，从而导致本地缓存的命中率并不高，为此TFS还支持远端缓存，将block到dataserver的映射关系缓存在tair中（tair是淘宝开源的分布式key/value存储系统，http://code.taobao.org/p/tair/wiki/intro/），应用tair缓存的命中率非常高，使得绝大部分的读请求都不需要经过nameserver。
根据业务的需求，TFS还实现了对自定义文件名和大文件存储的支持，支持这两种业务场景并没有改变TFS服务器端的存储机制，而是通过提供新的服务、封装client来实现。对于自定义名的存储服务，TFS提供单独的元数据服务器（metaserver）来管理自定义文件名到TFS文件名的映射关系，当用户存储一个指定文件名的文件时，client首先将其存储到TFS中，得到一个由TFS分配的文件名，然后将用户指定的文件名与TFS文件名的映射关系，存储到metaserver，当读取自定文件名文件时，则会先从metaserver查询该文件名对应的TFS文件名，然后从TFS里读取文件。对于大文件的存储，client会将大文件切分为多个小文件（通常每个2M）分片，并将每个分片都存储到TFS，得到多个文件名，然后将多个文件名作为新的文件数据存储到TFS，得到一个新的文件名（该文件名与正常的TFS文件有着不同的前缀，以区分其存储的是大文件的分片信息），当用户访问大文件时，client会先读出各个分片对应的TFS文件名信息，再从TFS里读出各个分片的数据，重新组合成大文件。
TFS提供了标准的C++客户端供开发者使用，同时由于淘宝内部业务主要使用java进行开发，因此TFS也提供了java客户端，每增加一门新语言的支持，都是在重复的实现客户端访问后端服务器的逻辑。当客户端发布给用户使用后，一旦发现bug，需要通知已经在使用的数百个应用来升级客户端，升级成本非常之高。TFS通过开发nginx客户端模块（已在github开源，/alibaba/nginx-tfs）来解决该问题，该模块代理所有的TFS读写请求，向用户提供restful的访问接口，nginx模块上线使用后，TFS的所有组件升级都能做到对用户透明，同时需要支持一门新语言访问TFS的成本也变得非常低，只需要按照协议向nginx代理发送http请求即可。
对于存储系统而言，除了保证数据的可靠存储外，支持容量扩展也至关重要。TFS对集群的扩容支持非常友好，当集群需要扩容时，运维人员只需要准备好扩容的新机器，部署dataserver的运行环境，启动dataserver服务即可，当nameserver感知到新的dataserver加入集群时，会在新的dataserver上创建一批block用于提供写操作，此时新扩容的dataserver就可以开始提供读写服务了。
由于TFS前端有淘宝CDN缓存数据，最终回源到TFS上的文件访问请求非常随机，基本不存在文件热点现象， 所以dataserver的负载与其存储的总数据量基本呈正比关系。当新dataserver加入集群时，其容量使用上与集群里其他的dataserver差距很大，因此负载上差距也很大，针对这种情况nameserver会对整个集群进行负载均衡，将部分数据从容量较高的dataserver迁移到新扩容的dataserver里，最终使得集群里所有dataserver的容量使用情况保持在一个尽量接近的水位线上，让整个集群的服务效率最大化。
TFS集群通过多副本机制来保证数据的可靠性，同时支持多机房容灾，具体做法是在多个机房各部署一个TFS物理集群，多个物理集群的数据通过集群间的同步机制来保证数据互为镜像，构成一个大的逻辑集群。
典型的逻辑集群部署方式为一主多备，如上图所示，主集群同时提供读写服务，备集群只提供读服务，主集群上存储的所有文件都会由对应的dataserver记录同步日志，日志包含文件的block id和fileid以及文件操作类型（写、删除等），并由dataserver的后台线程重放日志，将日志里的文件操作应用到备集群上，保证主备集群上存储的文件数据保持一致的状态。
对于异地机房的容灾，如果多个机房的应用都对所在机房的TFS集群有写操作，则需要采用多个主集群的部署方式，即逻辑集群里每个物理集群是对等的，同时对外提供读写服务，并将写操作同步到其他的物理集群。为了避免多个主集群同时写一个block造成的写冲突，每个主集群按照指定的规则分配block id用于写操作，以两个主集群为例，1号主集群在写文件时只分配奇数号的block id，而2号主集群在写文件时只分配偶数号的block id；针对奇数号block的写操作由1号集群向2号集群同步，而针对偶数号block的写操作由2号集群向1号集群同步。
对于支持多机房容灾的集群，TFS客户端提供了failover的支持，客户端读取文件时，会选择离自己最近的物理集群进行读取，如果读取不到文件（该物理集群可能是备集群，该文件还没有从主集群同步过来），客户端会尝试从其他的物理集群读取文件。
TFS在淘宝内部部署有多个集群、上千台服务器，有数百个应用访问，TFS将所有的资源信息存储在mysql数据库里，通过资源管理服务器（rcserver）进行统一的管理。
独立的多个集群在配置上通常是不同的，比如有的集群要求block存储2个副本，而有的集群则要求更高的可靠性，每个block存储3个副本，为了避免配置文件错误，每个集群的在mysql数据库里都有一套配置模板，在机器上线时，直接根据模板来生成配置文件。
每个集群的部署信息会在集群上线时由运维管理人员添加到mysql数据库里，比如一个逻辑集群里有哪些物理集群，每个物理集群的访问权限等，当内部应用需要使用TFS时，TFS会给每个应用分配一个appkey，同时根据应用的需求为其分配集群存储资源。 当TFS客户端启动时，会根据appkey从rcserver上获取应用的所有配置信息，根据配置信息来访问TFS的服务；client与rcserver间会周期性的keepalive， client将应用读写文件的统计信息汇报给rcserver，rcserver将针对该应用的最新配置信息带回给client。比如当某个集群出现重大问题时，可以修改mysql的配置，将应用切换到正常的集群上访问。
为了尽早发现问题，运维人员会在所有的TFS机器上部署监控程序，监视服务器的服务状态、监控集群的容量使用情况等，当发现有磁盘或机器故障时，自动将其下线；当发现集群的容量使用超过警戒线时，主动进行扩容。
TFS主要发展方向一直是在保证数据可靠性的基础上提高服务效率、降低存储以及运维成本。目前TFS正准备将Erasure code技术应用到系统中，用于代替传统的副本备份策略，该项目的上线预计会使得TFS的存储成本降低25%-50%。
注：本文首发于ChinaUnix《IT架构实录》，转载请注明。
阅读(14371) | 评论(2) | 转发(4) |
相关热门文章
给主人留下些什么吧！~~
同样看不到图
图挂了，请补图
请登录后评论。您的位置： &
分布式文件系统现状探讨研究
优质期刊推荐1318人阅读
分布式系统（1）
原文地址：
TFS（Taobao File System）是一个高可用、高性能、高可扩展的分布式文件系统，基于普通的Linux服务器构建，主要提供海量非结构化数据存储服务。TFS被广泛地的应用在淘宝的各项业务中，目前已部署的最大集群存储文件数已近千亿。 TFS已在TaoCode上开源 (项目主页：http://code.taobao.org/p/tfs/src/)，提供给外部用户使用。
TFS集群由名字服务器（namserver）和数据服务器（dataserver）组成，TFS以数据块（block）为单位存储和组织数据，block大小通常为64M（可配置），TFS会将多个小文件存储在同一个block中，并为block建立索引，以便快速在block中定位文件；每个block会存储多个副本到不同的机架上，以保证数据的高可靠性。每个block在集群中拥有全局唯一的数据块编号（block id），block id由nameserver创建时分配，block中的文件拥有一个block内唯一的文件编号（file
id），file id由dataserver在存储文件时分配，block id和file id组成的二元组唯一标识一个集群里的文件。
Nameserver服务部署时采用HA来避免单点故障，2台nameserver服务器共享一个vip。正常情况下，主nameserver持有vip提供服务，并将block修改信息同步至备，HA agent负责监控主备nameserver的状态，当其检测到主宕机时，HA agent将vip切换到备上，备就切换为主来接管服务，以保证服务的高可用。
Dataserver服务部署时通常会在一台机器上部署多个dataserver进程，每个进程管理一块磁盘，以便充分利用磁盘IO资源。Dataserver启动后，会向nameserver汇报其存储的所有block信息，并周期性的给nameserver发送心跳信息，nameserver则根据心跳来管理所有的dataserver，当nameserver超过一定时间没有收到dataserver的信息，则认为dataserver已经宕机，会将该dataserver上存储的block进行复制，使得block副本数不低于集群配置值，保证系统存储数据的可靠性。
Namserver上的所有元信息都保存在内存，并不进行持久化存储，dataserver启动后，会汇报其拥有的block信息给nameserver，nameserver根据这些信息来构建block到server的映射关系表，根据该映射关系表，为写请求分配可写的block，为读请求查询block的位置信息。Nameserver有专门的后台线程轮询各个block和server的状态，在发现block缺少副本时复制block（通常是由dataserver宕机导致的）；在发现dataserver负载不均衡时，迁移数据来保证服务器间的负载均衡。
TFS写文件流程如上图所示，nameserver在分配可写block时，简单的采用round robin的策略分配，这种策略简单有效，其他根据dataserver负载来分配的策略，实现上较复杂，同时由于负载信息不是实时的，根据过时的信息来分配block，实践证明其均衡效果并不好。当文件成功写到多个dataserver后，会向client返回一个由集群号、block id、file id编码而成的文件名，以后client通过该文件名即可从TFS访问到存储的文件，在dataserver上，每个block对应一个索引文件，索引中记录了block中每个文件在block内部的偏移位置以及文件的大小。
当client读取文件时，首先根据文件名解析出文件所在的block信息，从nameserver上查询block所在的dataserver信息，并向dataserver发送读请求，如果从某个副本读取失败，client会重试其他的副本；dataserver接收到client的读请求时，通过查找block的索引就能快速得到文件的位置，从block相应位置读取数据并返回给client。
当client删除TFS里的文件时，服务器端并不会立即将文件数据从block里删除掉，只是为文件设置一个删除标记，当一个block内被删除的文件数量超过一定比例时，会对block进行整理（compact），以回收删除文件占用的空间，删除任务通常在访问低峰期进行，以避免其对正常的服务造成影响。
Client负责完成读写删TFS文件的基本逻辑，并在失败时主动进行failover。为了提高client读取文件的效率、并降低nameserver的负载，client会将block到dataserver的映射关系缓存到本地，由于block到dataserver的映射关系一般只会在发生数据迁移的时候才会发生变化，所以一旦本地cache命中，大部分情况下都能从cache里获取到的dataserver上访问到文件，如果cache已经失效（block被迁移到其他dataserver），客户端最终会从nameserver获取block最新的位置信息，从最新的位置上读取文件。在实际应用中，通常客户端能使用的系统资源比较有限，能够用于本地缓存的内存并不大，而集群中block的数量有数千万，从而导致本地缓存的命中率并不高，为此TFS还支持远端缓存，将block到dataserver的映射关系缓存在tair中（tair是淘宝开源的分布式key/value存储系统，http://code.taobao.org/p/tair/wiki/intro/），应用tair缓存的命中率非常高，使得绝大部分的读请求都不需要经过nameserver。
根据业务的需求，TFS还实现了对自定义文件名和大文件存储的支持，支持这两种业务场景并没有改变TFS服务器端的存储机制，而是通过提供新的服务、封装client来实现。对于自定义名的存储服务，TFS提供单独的元数据服务器（metaserver）来管理自定义文件名到TFS文件名的映射关系，当用户存储一个指定文件名的文件时，client首先将其存储到TFS中，得到一个由TFS分配的文件名，然后将用户指定的文件名与TFS文件名的映射关系，存储到metaserver，当读取自定文件名文件时，则会先从metaserver查询该文件名对应的TFS文件名，然后从TFS里读取文件。对于大文件的存储，client会将大文件切分为多个小文件（通常每个2M）分片，并将每个分片都存储到TFS，得到多个文件名，然后将多个文件名作为新的文件数据存储到TFS，得到一个新的文件名（该文件名与正常的TFS文件有着不同的前缀，以区分其存储的是大文件的分片信息），当用户访问大文件时，client会先读出各个分片对应的TFS文件名信息，再从TFS里读出各个分片的数据，重新组合成大文件。
TFS提供了标准的C++客户端供开发者使用，同时由于淘宝内部业务主要使用java进行开发，因此TFS也提供了java客户端，每增加一门新语言的支持，都是在重复的实现客户端访问后端服务器的逻辑。当客户端发布给用户使用后，一旦发现bug，需要通知已经在使用的数百个应用来升级客户端，升级成本非常之高。TFS通过开发nginx客户端模块（已在github开源，/alibaba/nginx-tfs）来解决该问题，该模块代理所有的TFS读写请求，向用户提供restful的访问接口，nginx模块上线使用后，TFS的所有组件升级都能做到对用户透明，同时需要支持一门新语言访问TFS的成本也变得非常低，只需要按照协议向nginx代理发送http请求即可。
对于存储系统而言，除了保证数据的可靠存储外，支持容量扩展也至关重要。TFS对集群的扩容支持非常友好，当集群需要扩容时，运维人员只需要准备好扩容的新机器，部署dataserver的运行环境，启动dataserver服务即可，当nameserver感知到新的dataserver加入集群时，会在新的dataserver上创建一批block用于提供写操作，此时新扩容的dataserver就可以开始提供读写服务了。
由于TFS前端有淘宝CDN缓存数据，最终回源到TFS上的文件访问请求非常随机，基本不存在文件热点现象， 所以dataserver的负载与其存储的总数据量基本呈正比关系。当新dataserver加入集群时，其容量使用上与集群里其他的dataserver差距很大，因此负载上差距也很大，针对这种情况nameserver会对整个集群进行负载均衡，将部分数据从容量较高的dataserver迁移到新扩容的dataserver里，最终使得集群里所有dataserver的容量使用情况保持在一个尽量接近的水位线上，让整个集群的服务效率最大化。
TFS集群通过多副本机制来保证数据的可靠性，同时支持多机房容灾，具体做法是在多个机房各部署一个TFS物理集群，多个物理集群的数据通过集群间的同步机制来保证数据互为镜像，构成一个大的逻辑集群。
典型的逻辑集群部署方式为一主多备，如上图所示，主集群同时提供读写服务，备集群只提供读服务，主集群上存储的所有文件都会由对应的dataserver记录同步日志，日志包含文件的block id和fileid以及文件操作类型（写、删除等），并由dataserver的后台线程重放日志，将日志里的文件操作应用到备集群上，保证主备集群上存储的文件数据保持一致的状态。
对于异地机房的容灾，如果多个机房的应用都对所在机房的TFS集群有写操作，则需要采用多个主集群的部署方式，即逻辑集群里每个物理集群是对等的，同时对外提供读写服务，并将写操作同步到其他的物理集群。为了避免多个主集群同时写一个block造成的写冲突，每个主集群按照指定的规则分配block id用于写操作，以两个主集群为例，1号主集群在写文件时只分配奇数号的block id，而2号主集群在写文件时只分配偶数号的block id；针对奇数号block的写操作由1号集群向2号集群同步，而针对偶数号block的写操作由2号集群向1号集群同步。
对于支持多机房容灾的集群，TFS客户端提供了failover的支持，客户端读取文件时，会选择离自己最近的物理集群进行读取，如果读取不到文件（该物理集群可能是备集群，该文件还没有从主集群同步过来），客户端会尝试从其他的物理集群读取文件。
TFS在淘宝内部部署有多个集群、上千台服务器，有数百个应用访问，TFS将所有的资源信息存储在mysql数据库里，通过资源管理服务器（rcserver）进行统一的管理。
独立的多个集群在配置上通常是不同的，比如有的集群要求block存储2个副本，而有的集群则要求更高的可靠性，每个block存储3个副本，为了避免配置文件错误，每个集群的在mysql数据库里都有一套配置模板，在机器上线时，直接根据模板来生成配置文件。
每个集群的部署信息会在集群上线时由运维管理人员添加到mysql数据库里，比如一个逻辑集群里有哪些物理集群，每个物理集群的访问权限等，当内部应用需要使用TFS时，TFS会给每个应用分配一个appkey，同时根据应用的需求为其分配集群存储资源。 当TFS客户端启动时，会根据appkey从rcserver上获取应用的所有配置信息，根据配置信息来访问TFS的服务；client与rcserver间会周期性的keepalive， client将应用读写文件的统计信息汇报给rcserver，rcserver将针对该应用的最新配置信息带回给client。比如当某个集群出现重大问题时，可以修改mysql的配置，将应用切换到正常的集群上访问。
为了尽早发现问题，运维人员会在所有的TFS机器上部署监控程序，监视服务器的服务状态、监控集群的容量使用情况等，当发现有磁盘或机器故障时，自动将其下线；当发现集群的容量使用超过警戒线时，主动进行扩容。
TFS主要发展方向一直是在保证数据可靠性的基础上提高服务效率、降低存储以及运维成本。目前TFS正准备将Erasure code技术应用到系统中，用于代替传统的副本备份策略，该项目的上线预计会使得TFS的存储成本降低25%-50%。
注：本文首发于ChinaUnix《IT架构实录》，转载请注明。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：700179次
积分：7122
积分：7122
排名：第2415名
原创：36篇
转载：449篇
评论：37条
(1)(3)(1)(3)(1)(4)(1)(1)(1)(36)(2)(4)(17)(21)(21)(53)(16)(40)(19)(32)(4)(24)(27)(16)(17)(12)(2)(34)(3)(18)(7)(3)(2)(5)(8)(7)(7)(2)(3)(7)(1)(1)后使用快捷导航没有帐号？
查看: 545|回复: 8
淘宝的分布式文件系统 tfs 简介
金牌会员, 积分 1353, 距离下一级还需 1647 积分
论坛徽章:13
简介TFS（Taobao !FileSystem）是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的Linux机器集群上，可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储，通常文件大小不超过1M，满足了淘宝对小文件存储的需求，被广泛地应用在淘宝各项应用中。它采用了HA架构和平滑扩容，保证了整个文件系统的可用性和扩展性。同时扁平化的数据组织结构，可将文件名映射到文件的物理地址，简化了文件的访问流程，一定程度上为TFS提供了良好的读写性能。
TFS的总体结构一个TFS集群由两个!NameServer节点（一主一备）和多个!DataServer节点组成。这些服务程序都是作为一个用户级的程序运行在普通Linux机器上的。
在TFS中，将大量的小文件(实际数据文件)合并成为一个大文件，这个大文件称为块(Block), 每个Block拥有在集群内唯一的编号(Block Id), Block Id在!NameServer在创建Block的时候分配, !NameServer维护block与!DataServer的关系。Block中的实际数据都存储在!DataServer上。而一台!DataServer服务器一般会有多个独立!DataServer进程存在，每个进程负责管理一个挂载点，这个挂载点一般是一个独立磁盘上的文件目录，以降低单个磁盘损坏带来的影响。
!NameServer主要功能是: 管理维护Block和!DataServer相关信息,包括!DataServer加入，退出, 心跳信息, block和!DataServer的对应关系建立，解除。正常情况下，一个块会在!DataServer上存在， 主!NameServer负责Block的创建，删除，复制，均衡，整理， !NameServer不负责实际数据的读写，实际数据的读写由!DataServer完成。!DataServer主要功能是: 负责实际数据的存储和读写。同时为了考虑容灾，!NameServer采用了HA结构，即两台机器互为热备，同时运行，一台为主，一台为备，主机绑定到对外vip，提供服务；当主机器宕机后，迅速将vip绑定至备份!NameServer，将其切换为主机，对外提供服务。图中的HeartAgent就完成了此功能。
TFS的块大小可以通过配置项来决定，通常使用的块大小为64M。TFS的设计目标是海量小文件的存储，所以每个块中会存储许多不同的小文件。!DataServer进程会给Block中的每个文件分配一个ID(File ID，该ID在每个Block中唯一)，并将每个文件在Block中的信息存放在和Block对应的Index文件中。这个Index文件一般都会全部load在内存，除非出现!DataServer服务器内存和集群中所存放文件平均大小不匹配的情况。
另外，还可以部署一个对等的TFS集群，作为当前集群的辅集群。辅集群不提供来自应用的写入，只接受来自主集群的写入。当前主集群的每个数据变更操作都会重放至辅集群。辅集群也可以提供对外的读，并且在主集群出现故障的时候，可以接管主集群的工作。
平滑扩容原有TFS集群运行一定时间后，集群容量不足，此时需要对TFS集群扩容。由于DataServer与NameServer之间使用心跳机制通信，如果系统扩容，只需要将相应数量的新!DataServer服务器部署好应用程序后启动即可。这些!DataServer服务器会向!NameServer进行心跳汇报。!NameServer会根据!DataServer容量的比率和!DataServer的负载决定新数据写往哪台!DataServer的服务器。根据写入策略，容量较小，负载较轻的服务器新数据写入的概率会比较高。同时，在集群负载比较轻的时候，!NameServer会对!DataServer上的Block进行均衡，使所有!DataServer的容量尽早达到均衡。
进行均衡计划时，首先计算每台机器应拥有的blocks平均数量，然后将机器划分为两堆，一堆是超过平均数量的，作为移动源；一类是低于平均数量的，作为移动目的。
移动目的的选择：首先一个block的移动的源和目的，应该保持在同一网段内，也就是要与另外的block不同网段；另外，在作为目的的一定机器内，优先选择同机器的源到目的之间移动，也就是同台!DataServer服务器中的不同!DataServer进程。
当有服务器故障或者下线退出时（单个集群内的不同网段机器不能同时退出），不影响TFS的服务。此时!NameServer会检测到备份数减少的Block，对这些Block重新进行数据复制。
在创建复制计划时，一次要复制多个block, 每个block的复制源和目的都要尽可能的不同，并且保证每个block在不同的子网段内。因此采用轮换选择(roundrobin)算法，并结合加权平均。
由于DataServer之间的通信是主要发生在数据写入转发的时候和数据复制的时候，集群扩容基本没有影响。假设一个Block为64M，数量级为1PB。那么NameServer上会有 1 * 1024 * 1024 * 1024 / 64 = 16.7M个block。假设每个Block的元数据大小为0.1K，则占用内存不到2G。
存储机制在TFS中，将大量的小文件(实际用户文件)合并成为一个大文件，这个大文件称为块(Block)。TFS以Block的方式组织文件的存储。每一个Block在整个集群内拥有唯一的编号，这个编号是由NameServer进行分配的，而DataServer上实际存储了该Block。在!NameServer节点中存储了所有的Block的信息，一个Block存储于多个!DataServer中以保证数据的冗余。对于数据读写请求，均先由!NameServer选择合适的!DataServer节点返回给客户端，再在对应的!DataServer节点上进行数据操作。!NameServer需要维护Block信息列表，以及Block与!DataServer之间的映射关系，其存储的元数据结构如下：
在!DataServer节点上，在挂载目录上会有很多物理块，物理块以文件的形式存在磁盘上，并在!DataServer部署前预先分配，以保证后续的访问速度和减少碎片产生。为了满足这个特性，!DataServer现一般在EXT4文件系统上运行。物理块分为主块和扩展块，一般主块的大小会远大于扩展块，使用扩展块是为了满足文件更新操作时文件大小的变化。每个Block在文件系统上以“主块+扩展块”的方式存储。每一个Block可能对应于多个物理块，其中包括一个主块，多个扩展块。
在DataServer端，每个Block可能会有多个实际的物理文件组成：一个主Physical Block文件，N个扩展Physical Block文件和一个与该Block对应的索引文件。Block中的每个小文件会用一个block内唯一的fileid来标识。!DataServer会在启动的时候把自身所拥有的Block和对应的Index加载进来。
容错机制集群容错
TFS可以配置主辅集群，一般主辅集群会存放在两个不同的机房。主集群提供所有功能，辅集群只提供读。主集群会把所有操作重放到辅集群。这样既提供了负载均衡，又可以在主集群机房出现异常的情况不会中断服务或者丢失数据。
!NameServer容错
Namserver主要管理了!DataServer和Block之间的关系。如每个!DataServer拥有哪些Block，每个Block存放在哪些!DataServer上等。同时，!NameServer采用了HA结构，一主一备，主NameServer上的操作会重放至备NameServer。如果主NameServer出现问题，可以实时切换到备NameServer。
另外!NameServer和!DataServer之间也会有定时的heartbeat，!DataServer会把自己拥有的Block发送给!NameServer。!NameServer会根据这些信息重建!DataServer和Block的关系。
!DataServer容错
TFS采用Block存储多份的方式来实现!DataServer的容错。每一个Block会在TFS中存在多份，一般为3份，并且分布在不同网段的不同!DataServer上。对于每一个写入请求，必须在所有的Block写入成功才算成功。当出现磁盘损坏!DataServer宕机的时候，TFS启动复制流程，把备份数未达到最小备份数的Block尽快复制到其他DataServer上去。 TFS对每一个文件会记录校验crc，当客户端发现crc和文件内容不匹配时，会自动切换到一个好的block上读取。此后客户端将会实现自动修复单个文件损坏的情况。
并发机制对于同一个文件来说，多个用户可以并发读。
现有TFS并不支持并发写一个文件。一个文件只会有一个用户在写。这在TFS的设计里面对应着是一个block同时只能有一个写或者更新操作。
TFS文件名的结构TFS的文件名由块号和文件号通过某种对应关系组成，最大长度为18字节。文件名固定以T开始，第二字节为该集群的编号(可以在配置项中指定，取值范围 1~9)。余下的字节由Block ID和File ID通过一定的编码方式得到。文件名由客户端程序进行编码和解码，它映射方式如下图：
TFS客户程序在读文件的时候通过将文件名转换为BlockID和FileID信息，然后可以在!NameServer取得该块所在!DataServer信息（如果客户端有该Block与!DataServere的缓存，则直接从缓存中取），然后与!DataServer进行读取操作。
金牌会员, 积分 1278, 距离下一级还需 1722 积分
论坛徽章:14
谢谢楼主分享，学习了
论坛徽章:45
谢谢分享.&&标记学习!!
金牌会员, 积分 2093, 距离下一级还需 907 积分
论坛徽章:9
谢谢楼主分享，学习了
中级会员, 积分 335, 距离下一级还需 165 积分
论坛徽章:8
学习了，非常！
顺便完成作业
中级会员, 积分 335, 距离下一级还需 165 积分
论坛徽章:8
学习了，非常！
顺便完成作业
中级会员, 积分 214, 距离下一级还需 286 积分
论坛徽章:6
TFS用在淘宝哪些业务上了呢？
注册会员, 积分 172, 距离下一级还需 28 积分
论坛徽章:2
谢谢分享.&&标记学习!!
金牌会员, 积分 1844, 距离下一级还需 1156 积分
论坛徽章:22
感谢楼主分享，学习了！