一、淘宝网的困境

对于淘宝网这样的大型电子商务网站，对于图片服务的要求特别的高。而且对于卖家来说，图片远胜于文字描述，因此卖家也格外看重图片的显示质量、访问速度等问题。根据淘宝网的流量分析，整个淘宝网流量中，图片的访问流量会占到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，能够准确定位文件在什么地方。由于大量的文件信息都隐藏在文件名中，整个系统完全抛弃了传统的目录树结构，因为目录树开销最大。拿掉后，整个集群的高可扩展性极大提高。

注：相关网站建设技巧阅读请移步到建站教程频道。