淘宝从无到有技术发展 - 图文(4)

2007年6月，TFS正式上线运营。在生产环境中应用的集群规模达到了200台PC Server(146G*6 SAS 15K Raid5)，文件数量达到上亿级别；系统部署存储容量：140TB；实际使用存储容量： 50TB；单台支持随机IOPS 200+，流量3MBps。

要讲TFS的系统架构，首先要描述清楚业务需求，淘宝对图片存储的需求大概可以描述如下：

文件比较小；并发量高；读操作远大于写操作；访问随机；没有文件修改的操作；要求存储成本低；能容灾能备份。应对这种需求，显然要用分布式存储系统；由于文件大小比较

统一，可以采用专有文件系统；并发量高，读写随机性强，需要更少的IO操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾，需要能平滑扩容。

参照GFS并做了适度的优化之后，TFS1.0版的架构图如下：

从上面架构图上看：集群由一对Name Server和多台Data Server构成，Name Server 的两台服务器互为双机，就是集群文件系统中管理节点的概念。

在这个架构中：

每个Data Server运行在一台普通的Linux主机上 以block文件的形式存放数据文件(一般64M一个block) block存多份保证数据安全 利用ext3文件系统存放数据文件 磁盘raid5做数据冗余

文件名内置元数据信息，用户自己保存TFS文件名与实际文件的对照关系–使得元数据

量特别小。

淘宝TFS文件系统在核心设计上最大的取巧的地方就在，传统的集群系统里面元数据只有1份，通常由管理节点来管理，因而很容易成为瓶颈。而对于淘宝网的用户来说，图片文件究竟用什么名字来保存实际上用户并不关心，因此TFS在设计规划上考虑在图片的保存文件名上暗藏了一些元数据信息，例如图片的大小、时间、访问频次等等信息，包括所在的逻辑块号。而在元数据上，实际上保存的信息很少，因此元数据结构非常简单。仅仅只需要一个fileID，能够准确定位文件在什么地方。

由于大量的文件信息都隐藏在文件名中，整个系统完全抛弃了传统的目录树结构，因为目录树开销最大。拿掉后，整个集群的高可扩展性极大提高。实际上，这一设计理念和目前业界的―对象存储‖较为类似，淘宝网TFS文件系统已经更新到1.3版本，在生产系统的性能已经得到验证，且不断得到了完善和优化，淘宝网目前在对象存储领域的研究已经走在前列。

在TFS上线之前，淘宝网每个商品只允许上传一张图片，大小限定在120K之内，在商品详情里面的图片必须使用外站的服务。那时侯发布一件商品确实非常麻烦，笔者曾经想卖一台二手电脑，先把照片上传到google相册，在发布到淘宝网之后发现google相册被墙了，我的图片别人看不到，当时郁闷的不行。TFS上线后，商品展示图片开放到5张，商品描述里面的图片也可以使用淘宝的图片服务，到现在为止，淘宝网给每个用户提供了1G的图片空间，这下大家都满足了。技术和业务就是这么互相用力的推动着，业务满足不了的时候，技术必须创新，技术创新之后，业务有了更大的发展空间。

1.3版本的架构见阿里味（阿里巴巴内网）?? 本文将于作者同步更新，请留意。

原文链接：http://blog.sina.com.cn/s/blog_633219970100x9cc.html

【编辑推荐】

1 、Java中常见IO的读写效率对比 2 、Java几款性能分析工具的对比

3 、栈的Java实现和栈的应用举例 4 、实战是硬道理：记Java技术面试 5 、Java中的Enum的使用与分析