对海量小文件存储优化的一些理解和TFS介绍

在研究图片服务器问题时，了解到现在很多大公司基本上都是用分布式文件系统来存储海量小文件，比如Facebook有haystack，淘宝有TFS，京东有JFS。最近在研究TFS，结合之前学习的linux下的inode相关知识，了解到在ext文件系统中，对一个文件的读需要先从磁盘中读取到文件对应的Inode，然后根据inode获取到对应的block的位置信息，进行第二次磁盘读取目标文件的内容，这样就需要两次磁盘IO。在系统中会有inode缓存，这样可保证一些文件读取只需要一次磁盘IO。

在存储向图片这样的小文件时，一般不超过1M，一些可能之后几kb，这样就会是海量文件，总占用容量不大。linux在格式化磁盘时，会默认每1kB或2KB就分配一个inode，inode table 和 数据区分开存储，一个磁盘的大小为1GB，inode按128B算，inode占的总大小为128MB，这样在比较大的硬盘中，inode数会更多，占用的空间也会更大。inode可以放到cache中，加快文件读，当文件的数量少时，需要加入到内存中的inode数量少，可以全部缓存到内存中，减少一次磁盘IO，可以提升读取文件的性能，但是当是海量的小文件时，对应的inode数就比较多，几乎无法全部加载到内存中，那么文件的读可能是随机的，不在一个block中，那么会有很多文件inode无法在缓存中命中，需要两次磁盘IO，读文件性能会比较低。

先在应对海量小文件的优化策略，一般都会包括把小文件进行合并存储，比如Facebook开源的haystack和淘宝的TFS都采用了这样的优化策略，通过合并文件减少inode的数量，也就是原数据的大小减小，达到基本上可以全部加载到内存中，可以实现一次磁盘IO就可以读取到文件，大大提升读取文件的性能，解决了海量小文件的读取性能问题。

下边是TFS的官方文档，我就直接搬到这里了：

简介

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完成。