一、淘宝网的困境

　　对于淘宝网这样的大型电子商务网站，对于图片服务的要求特别的高。而且对于卖家来说，图片远胜于文字描述，因此卖家也格外看重图片的显示质量、访问速度等问题。根据淘宝网的流量分析，整个淘宝网流量中，图片的访问流量会占到90%以上，而主站的网页则占到不到10%。同时大量的图片需要根据不同的应用位置，生成不同大小规格的缩略图。考虑到多种不同的应用场景以及改版的可能性，一张原图有可能需要生成20多个不同尺寸规格的缩略图。

　　淘宝整体图片存储系统容量1800TB(1.8PB)，已经占用空间990TB(约1PB)。保存的图片文件数量达到286亿多个，这些图片文件包括根据原图生成的缩略图。平均图片大小是17.45K;8K以下图片占图片数总量的61%，占存储容量的11%。对于如此大规模的小文件存储与读取需要频繁的寻道和换道，在大量高并发访问量的情况下，非常容易造成读取延迟。

　　2007年之前淘宝采用NetApp公司的文件存储系统。至2006年， NetApp公司最高端的产品也不能满足淘宝存储的要求。首先是商用的存储系统没有对小文件存储和读取的环境进行有针对性的优化;其次，文件数量大，网络存储设备无法支撑;另外，整个系统所连接的服务器也越来越多，网络连接数已经到达了网络存储设备的极限。此外，商用存储系统扩容成本高，10T的存储容量需要几百万，而且存在单点故障，容灾和安全性无法得到很好的保证。

　　二、淘宝网自主开发的目的

　　商用软件很难满足大规模系统的应用需求，无论存储还是CDN还是负载均衡，因为在厂商实验室端，很难实现如此大的数据规模测试。 研发过程中，将开源和自主开发相结合，会有更好的可控性，系统出问题了，完全可以从底层解决问题，系统扩展性也更高。 在一定规模效应基础上，研发的投入都是值得的。当规模超过交叉点后自主研发才能收到较好的经济效果。实际上淘宝网的规模已经远远超过了交叉点。 自主研发的系统可在软件和硬件多个层次不断的优化。

　　三、淘宝TFS的介绍

　　1、 TFS 1.0版本

　　从2006年开始，淘宝网决定自己开发一套针对海量小文件存储难题的文件系统，用于解决自身图片存储的难题。到2007年6月，TFS(淘宝文件系统，Taobao File System)正式上线运营。在生产环境中应用的集群规模达到了200台PC Server(146G*6 SAS 15K Raid5)，文件数量达到上亿级别;系统部署存储容量: 140 TB;实际使用存储容量: 50 TB;单台支持随机IOPS 200+，流量3MBps。

　　图为淘宝集群文件系统TFS 1.0第一版的逻辑架构：集群由一对Name Server和多台Data Server构成，Name Server的两台服务器互为双机，就是集群文件系统中管理节点的概念。

　　每个Data Server运行在一台普通的Linux主机上 以block文件的形式存放数据文件(一般64M一个block) block存多份保证数据安全 利用ext3文件系统存放数据文件 磁盘raid5做数据冗余 文件名内置元数据信息，用户自己保存TFS文件名与实际文件的对照关系–使得元数据量特别小。

　　TFS最大的特点就是将一部分元数据隐藏到图片的保存文件名上，大大简化了元数据，消除了管理节点对整体系统性能的制约，这一理念和目前业界流行的 “对象存储”较为类似。传统的集群系统里面元数据只有1份，通常由管理节点来管理，因而很容易成为瓶颈。而对于淘宝网的用户来说，图片文件究竟用什么名字来保存实际上用户并不关心，因此TFS在设计规划上考虑在图片的保存文件名上暗藏了一些元数据信息，例如图片的大小、时间、访问频次等等信息，包括所在的逻辑块号。而在元数据上，实际上保存的信息很少，因此元数据结构非常简单。仅仅只需要一个fileID，能够准确定位文件在什么地方。由于大量的文件信息都隐藏在文件名中，整个系统完全抛弃了传统的目录树结构，因为目录树开销最大。拿掉后，整个集群的高可扩展性极大提高。

　　2、 TFS 1.3版本

　　到2009年6月，TFS 1.3版本上线，集群规模大大扩展，部署到淘宝的图片生产系统上，整个系统已经从原有200台PC服务器扩增至440台PC Server(300G*12 SAS 15K RPM) + 30台PC Server (600G*12 SAS 15K RPM)。支持文件数量也扩容至百亿级别;系统部署存储容量：1800TB(1.8PB);当前实际存储容量：995TB;单台Data Server支持随机IOPS 900+，流量15MB+;目前Name Server运行的物理内存是217MB(服务器使用千兆网卡)。

　　图为TFS1.3版本的逻辑结构图，在TFS1.3版本中，淘宝网的软件工作组重点改善了心跳和同步的性能，最新版本的心跳和同步在几秒钟之内就可完成切换，同时进行了一些新的优化：包括元数据存内存上，清理磁盘空间，性能上也做了优化，包括：

　　完全扁平化的数据组织结构，抛弃了传统文件系统的目录结构。 在块设备基础上建立自有的文件系统，减少EXT3等文件系统数据碎片带来的性能损耗 单进程管理单块磁盘的方式，摒除RAID5机制 带有HA机制的中央控制节点，在安全稳定和性能复杂度之间取得平衡。 尽量缩减元数据大小，将元数据全部加载入内存，提升访问速度。 跨机架和IDC的负载均衡和冗余安全策略。 完全平滑扩容。

　　TFS主要的性能参数不是IO吞吐量，而是单台PCServer提供随机读写IOPS。由于硬件型号不同，很难给出一个参考值来说明性能。但基本上可以达到单块磁盘随机IOPS理论最大值的60%左右，整机的输出随盘数增加而线性增加。

　　3、 TFS 2.0版本

　　TFS 2.0(下面简称TFS，目前已经开源)是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的 Linux机器集群上，可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储，通常文件大小不超过1M，满足了淘宝对小文件存储的需求，被广泛地应用在淘宝各项应用中。它采用了HA架构和平滑扩容，保证了整个文件系统的可用性和扩展性。同时扁平化的数据组织结构，可将文件名映射到文件的物理地址，简化了文件的访问流程，一定程度上为TFS提供了良好的读写性能。

　　一个TFS集群由两个!NameServer节点(一主一备)和多个!DataServer节点组成。这些服务程序都是作为一个用户级的程序运行在普通Linux机器上的。在TFS中，将大量的小文件(实际数据文件)合并成为一个大文件，这个大文件称为块(Block), 每个Block拥有在集群内唯一的编号(Block Id), Block Id在!NameServer在创建Block的时候分配, !NameServer维护block与!DataServer的关系。Block中的实际数据都存储在!DataServer上。而一台!DataServer服务器一般会有多个独立!DataServer进程存在，每个进程负责管理一个挂载点，这个挂载点一般是一个独立磁盘上的文件目录，以降低单个磁盘损坏带来的影响。正常情况下，一个块会在!DataServer上存在，主!NameServer负责Block的创建，删除，复制，均衡，整理， !NameServer不负责实际数据的读写，实际数据的读写由!DataServer完成。

　　!NameServer主要功能是: 管理维护Block和!DataServer相关信息,包括!DataServer加入，退出, 心跳信息, block和!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平均数量，然后将机器划分为两堆，一堆是超过平均数量的，作为移动源;一类是低于平均数量的，作为移动目的。<