FastDFS架构分析.doc

FastDFS一个高效的分布式文件系统FastDFS是一款类GoogleFS的开源分布式文件系统，它用纯C语言实现，支持Linux、FreeBSD、AIX等UNIX系统。它只能通过专有API对文件进行存取访问，不支持POSIX接口方式，不能mount使用。准确地讲，GoogleFS以及FastDFS、mogileFS、HDFS、TFS等类GoogleFS都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。FastDFS的设计理念FastDFS是为互联网应用量身定做的分布式文件系统，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标。和现有的类GoogleFS分布式文件系统相比，FastDFS的架构和设计理念有其独到之处，主要体现在轻量级、分组方式和对等结构三个方面。轻量级FastDFS只有两个角色：Trackerserver和Storageserver。Trackerserver作为中心结点，其主要作用是负载均衡和调度。Trackerserver在内存中记录分组和Storageserver的状态等信息，不记录文件索引信息，占用的内存量很少。另外，客户端（应用）和Storageserver访问Trackerserver时，Trackerserver扫描内存中的分组和Storageserver信息，然后给出应答。由此可以看出Trackerserver非常轻量化，不会成为系统瓶颈。FastDFS中的Storageserver在其他文件系统中通常称作Trunkserver或Dataserver。Storageserver直接利用OS的文件系统存储文件。FastDFS不会对文件进行分块存储，客户端上传的文件和Storageserver上的文件一一对应。众所周知，大多数网站都需要存储用户上传的文件，如图片、视频、电子文档等。出于降低带宽和存储成本的考虑，网站通常都会限制用户上传的文件大小，例如图片文件不能超过5MB、视频文件不能超过100MB等。我认为，对于互联网应用，文件分块存储没有多大的必要。它既没有带来多大的好处，又增加了系统的复杂性。FastDFS不对文件进行分块存储，与支持文件分块存储的DFS相比，更加简洁高效，并且完全能满足绝大多数互联网应用的实际需要。在FastDFS中，客户端上传文件时，文件ID不是由客户端指定，而是由Storageserver生成后返回给客户端的。文件ID中包含了组名、文件相对路径和文件名，Storageserver可以根据文件ID直接定位到文件。因此FastDFS集群中根本不需要存储文件索引信息，这是FastDFS比较轻量级的一个例证。而其他文件系统则需要存储文件索引信息，这样的角色通常称作NameServer。其中mogileFS采用MySQL数据库来存储文件索引以及系统相关的信息，其局限性显而易见，MySQL将成为整个系统的瓶颈。FastDFS轻量级的另外一个体现是代码量较小。最新的V2.0包括了C客户端API、FastDHT客户端API和PHPextension等，代码行数不到5.2万行。分组方式类GoogleFS都支持文件冗余备份，例如GoogleFS、TFS的备份数是3。一个文件存储到哪几个存储结点，通常采用动态分配的方式。采用这种方式，一个文件存储到的结点是不确定的。举例说明，文件备份数是3，集群中有A、B、C、D四个存储结点。文件1可能存储在A、B、C三个结点，文件2可能存储在B、C、D三个结点，文件3可能存储在A、B、D三个结点。FastDFS采用了分组存储方式。集群由一个或多个组构成，集群存储总容量为集群中所有组的存储容量之和。一个组由一台或多台存储服务器组成，同组内的多台Storageserver之间是互备关系，同组存储服务器上的文件是完全一致的。文件上传、下载、删除等操作可以在组内任意一台Storageserver上进行。类似木桶短板效应，一个组的存储容量为该组内存储服务器容量最小的那个，由此可见组内存储服务器的软硬件配置最好是一致的。采用分组存储方式的好处是灵活、可控性较强。比如上传文件时，可以由客户端直接指定上传到的组。一个分组的存储服务器访问压力较大时，可以在该组增加存储服务器来扩充服务能力（纵向扩容）。当系统容量不足时，可以增加组来扩充存储容量（横向扩容）。采用这样的分组存储方式，可以使用FastDFS对文件进行管理，使用主流的Webserver如Apache、nginx等进行文件下载。对等结构FastDFS集群中的Trackerserver也可以有多台，Trackerserver和Storageserver均不存在单点问题。Trackerserver之间是对等关系，组内的Storageserver之间也是对等关系。传统的Master-Slave结构中的Master是单点，写操作仅针对Master。如果Master失效，需要将Slave提升为Master，实现逻辑会比较复杂。和Master-Slave结构相比，对等结构中所有结点的地位是相同的，每个结点都是Master，不存在单点问题。FastDFS的架构图1展示的是FastDFS的系统架构。图1 FastDFS的系统架构从图1可以看出，Trackerserver之间相互独立，不存在直接联系。客户端和Storageserver主动连接Trackerserver。Storageserver主动向Trackerserver报告其状态信息，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。Storageserver会连接集群中所有的Trackerserver，向他们报告自己的状态。Storageserver启动一个单独的线程来完成对一台Trackerserver的连接和定时报告。需要说明的是，一个组包含的Storageserver不是通过配置文件设定的，而是通过Trackerserver获取到的。不同组的Storageserver之间不会相互通信，同组内的Storageserver之间会相互连接进行文件同步。Storageserver采用binlog文件记录文件上传、删除等更新操作。binlog中只记录文件名，不记录文件内容。文件同步只在同组内的Storageserver之间进行，采用push方式，即源头服务器同步给目标服务器。只有源头数据才需要同步，备份数据并不需要再次同步，否则就构成环路了。有个例外，就是新增加一台Storageserver时，由已有的一台Storageserver将已有的所有数据（包括源头数据和备份数据）同步给该新增服务器。Storageserver中由专门的线程根据binlog进行文件同步。为了最大程度地避免相互影响以及出于系统简洁性考虑，Storageserver对组内除自己以外的每台服务器都会启动一个线程来进行文件同步。文件同步采用增量同步方式，系统记录已同步的位置（binlog文件偏移量）到标识文件中。标识文件名格式：deststorageIP_port.mark，例如：4_23000.mark。文件上传和下载的交互过程接下来我们一起看一下文件上传和下载的交互过程。文件上传和下载流程分别如图2、图3所示。文件上传流程的步骤如下：图2 文件上传流程图3 文件下载流程1.Client询问Trackerserver上传到的Storageserver；2.Trackerserver返回一台可用的Storageserver，返回的数据为该Storageserver的IP地址和端口；3.Client直接和该Storageserver建立连接，进行文件上传，Storageserver返回新生成的文件ID，文件上传结束。文件下载流程的步骤如下：1.Client询问Trackerserver可以下载指定文件的Storageserver，参数为文件ID（包含组名和文件名）；2.Trackerserver返回一台可用的Storageserver；3.Client直接和该Storageserver建立连接，完成文件下载。文件同步延迟问题的提出客户端将一个文件上传到一台Storageserver后，文件上传工作就结束了。由该Storageserver根据binlog中的上传记录将这个文件同步到同组的其他Storageserver。这样的文件同步方式是异步方式，异步方式带来了文件同步延迟的问题。新上传文件后，在尚未被同步过去的Storageserver上访问该文件，会出现找不到文件的现象。FastDFS是如何解决文件同步延迟这个问题的呢？文件的访问分为两种情况：文件更新和文件下载。文件更新包括设置文件附加属性和删除文件。文件的附加属性包括文件大小、图片宽度、图片高度等。FastDFS中，文件更新操作都会优先选择源Storageserver，也就是该文件被上传到的那台Storageserver。这样的做法不仅避免了文件同步延迟的问题，而且有效地避免了在多台Storageserver上更新同一文件可能引起的时序错乱的问题。那么文件下载是如何解决文件同步延迟这个问题的呢？要回答这个问题，需要先了解文件名中包含了什么样的信息。Storageserver生成的文件名中，包含了源Storageserver的IP地址和文件创建时间等字段。文件创建时间为UNIX时间戳，后面称为文件时间戳。从文件名或文件ID中，可以反解出这两个字段。然后我们再来看一下，Trackerserver是如何准确地知道一个文件已被同步到一台Storageserver上的。前面已经讲过，文件同步采用主动推送的方式。另外，每台storageserver都会定时向trackerserver报告它向同组的其他storageserver同步到的文件时间戳。当trackerserver收到一台storageserver的文件同步报告后，它会依次找出该组内各个storageserver（后称作为S）被同步到的文件时间戳最小值，作为S的一个属性记录到内存中。FastDFS对文件同步延迟问题的解决方案下面我们来看一下FastDFS采取的解决方法。一个最简单的解决办法，和文件更新一样，优先选择源Storageserver下载文件即可。这可以在Trackerserver的配置文件中设置，对应的参数名为download_server。另外一种选择Storageserver的方法是轮流选择（round-robin）。当Client询问Trackerserver有哪些Storageserver可以下载指定文件时，Trackerserver返回满足如下四个条件之一的Storageserver： 该文件上传到的源Storageserver，文件直接上传到该服务器上的； 文件创建时间戳一个文件同步完成需要的最大时间（如5分钟）； （当前时间文件创建时间戳）文件同步延迟阈值，比如我们把阈值设置为1天，表示文件同步在一天内肯定可以完成。 结束语看了上面的介绍，你是否认为FastDFS比较简洁高效呢？原雅虎同事一位比较资深的系统架构师听完FastDFS介绍后，作出这样的评价：“FastDFS是穷人的解决方案”。他的意思是说FastDFS把简洁和高效做到了极致，非常节约资源，中小网站完全用得起，这是对FastDFS的极大认可和褒奖。FastDFS从2008年7月发布至今，已推出31个版本，后续完善和优化工作正在持续进行中。目前已有多家公司在生产环境中使用FastDFS，相信通过我们的不懈努力，FastDFS一定会越来越好！作者简介：余庆，现在淘宝网Java中间件团队从事Java基础平台研发工作，有10年互联网开发和架构经历，曾担任新浪网开发工程师、雅虎中国架构师。开源分布式文件系统FastDFS和分布式哈希系统FastDHT的作者，对分布式数据存储架构有比较深入的研究。FastDFS同步機制在FastDFS的服务器端配置文件中，bind_addr这个参数用于需要绑定本机IP地址的场合。只有这个参数和主机特征相关，其余参数都是可以统一配置的。在不需要绑定本机的情况下，为了便于管理和维护，建议所有tracker server的配置文件相同，同组内的所有storage server的配置文件相同。tracker server的配置文件中没有出现storage server，而storage server的配置文件中会列举出所有的tracker server。这就决定了storage server和tracker server之间的连接由storage server主动发起，storage server为每个tracker server启动一个线程进行连接和通讯，这部分的通信协议请参阅FastDFS HOWTO - Protocol中的“2. storage server to tracker server command”。tracker server会在内存中保存storage分组及各个组下的storage server，并将连接过自己的storage server及其分组保存到文件中，以便下次重启服务时能直接从本地磁盘中获得storage相关信息。storage server会在内存中记录本组的所有服务器，并将服务器信息记录到文件中。tracker server和storage server之间相互同步storage server列表：1. 如果一个组内增加了新的storage server或者storage server的状态发生了改变，tracker server都会将storage server列表同步给该组内的所有storage server。以新增storage server为例，因为新加入的storage server主动连接tracker server，tracker server发现有新的storage server加入，就会将该组内所有的storage server返回给新加入的storage server，并重新将该组的storage server列表返回给该组内的其他storage server；2. 如果新增加一台tracker server，storage server连接该tracker server，发现该tracker server返回的本组storage server列表比本机记录的要少，就会将该tracker server上没有的storage server同步给该tracker server。同一组内的storage server之间是对等的，文件上传、删除等操作可以在任意一台storage server上进行。文件同步只在同组内的storage server之间进行，采用push方式，即源服务器同步给目标服务器。以文件上传为例，假设一个组内有3台storage server A、B和C，文件F上传到服务器B，由B将文件F同步到其余的两台服务器A和C。我们不妨把文件F上传到服务器B的操作为源头操作，在服务器B上的F文件为源头数据；文件F被同步到服务器A和C的操作为备份操作，在A和C上的F文件为备份数据。同步规则总结如下：1. 只在本组内的storage server之间进行同步；2. 源头数据才需要同步，备份数据不需要再次同步，否则就构成环路了；3. 上述第二条规则有个例外，就是新增加一台storage server时，由已有的一台storage server将已有的所有数据（包括源头数据和备份数据）同步给该新增服务器。storage server有7个状态，如下：# FDFS_STORAGE_STATUS_INIT :初始化，尚未得到同步已有数据的源服务器# FDFS_STORAGE_STATUS_WAIT_SYNC :等待同步，已得到同步已有数据的源服务器# FDFS_STORAGE_STATUS_SYNCING :同步中# FDFS_STORAGE_STATUS_DELETED :已删除，该服务器从本组中摘除（注：本状态的功能尚未实现）# FDFS_STORAGE_STATUS_OFFLINE :离线# FDFS_STORAGE_STATUS_ONLINE :在线，尚不能提供服务# FDFS_STORAGE_STATUS_ACTIVE :在线，可以提供服务当storage server的状态为FDFS_STORAGE_STATUS_ONLINE时，当该storage server向tracker server发起一次heart beat时，tracker server将其状态更改为FDFS_STORAGE_STATUS_ACTIVE。组内新增加一台storage server A时，由系统自动完成已有数据同步，处理逻辑如下：1. storage server A连接tracker server，tracker server将storage server A的状态设置为FDFS_STORAGE_STATUS_INIT。storage server A询问追加同步的源服务器和追加同步截至时间点，如果该组内只有storage server A或该组内已成功上传的文件数为0，则没有数据需要同步，storage server A就可以提供在线服务，此时tracker将其状态设置为FDFS_STORAGE_STATUS_ONLINE，否则tracker server将其状态设置为FDFS_STORAGE_STATUS_WAIT_SYNC，进入第二步的处理；2. 假设tracker server分配向storage server A同步已有数据的源storage server为B。同组的storage server和tracker server通讯得知新增了storage server A，将启动同步线程，并向tracker server询问向storage server A追加同步的源服务器和截至时间点。storage server B将把截至时间点之前的所有数据同步给storage server A；而其余的storage server从截至时间点之后进行正常同步，只把源头数据同步给storage server A。到了截至时间点之后，storage server B对storage server A的同步将由追加同步切换为正常同步，只同步源头数据；3. storage server B向storage server A同步完所有数据，暂时没有数据要同步时，storage server B请求tracker server将storage server A的状态设置为FDFS_STORAGE_STATUS_ONLINE；4 当storage server A向tracker server发起heart beat时，tracker server将其状态更改为FDFS_STORAGE_STATUS_ACTIVE。FastDFS通过HTTP下载