开源分布式文件系统FastDFS和MogileFS
2009-11-22 17:27:48 
阿炯
FastDFS是一个开源的轻量级分布式文件系统，她对文件进行管理，功能包括：文件存储、文件同步、文件访问(文件上传、文件下载)等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。
FastDFS服务端有两个角色：跟踪器(tracker)和存储节点(storage)。跟踪器主要做调度工作，在访问上起负载均衡的作用。存储节点存储文件，完成文件管理的所有功能：存储、同步和提供存取接口，FastDFS同时对文件的metadata进行管理。所谓文件的meta data就是文件的相关属性，以键值对(key valuepair)方式表示，如：width=1024，其中的key为width，value为1024。文件metadata是文件属性列表，可以包含多个键值对。
FastDFS系统结构如下图所示：
跟踪器和存储节点都可以由一台多台服务器构成。跟踪器和存储节点中的服务器均可以随时增加或下线而不会影响线上服务。其中跟踪器中的所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。
为了支持大容量，存储节点(服务器)采用了分卷(或分组)的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。
当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。FastDFS中的文件标识分为两个部分：卷名和文件名，二者缺一不可。
FastDFS file upload
上传文件交互过程：
1. client询问tracker上传到的storage，不需要附加参数；
2. tracker返回一台可用的storage；
3. client直接和storage通讯完成文件上传。
FastDFS file download
下载文件交互过程：
1. client询问tracker下载文件的storage，参数为文件标识(卷名和文件名)；
2. tracker返回一台可用的storage；
3. client直接和storage通讯完成文件下载。
需要说明的是，client为使用FastDFS服务的调用方，client也应该是一台服务器，它对tracker和storage的调用均为服务器间的调用。下面就其架构做一个简要的介绍。
1、FastDFS原理介绍
FastDFS是一个C语言实现的开源轻量级分布式文件系统。支持 Linux、FreeBSD等Unix系统，解决了大容量的文件存储和高并发访问问题，文件存取实现了负载均衡，适合存储 4KB~500MB 之间的小文件，特别适合以文件为载体的在线服务，如图片、视频、文档等等。
2、FastDFS 架构
FastDFS 由三个部分构成：
客户端(Client)
跟踪服务器(TrackerServer)
存储服务器(StorageServer)
2.1 Tracker Server (跟踪服务器)
Tracker Server (跟踪服务器) 主要是做调度工作，起到负载均衡的作用。
(1)[服务注册]管理StorageServer存储集群，StorageServer启动时，会把自己注册到TrackerServer上，并且定期报告自身状态信息，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。
(2)[服务发现]Client访问StorageServer之前，必须先访问TrackerServer，动态获取到StorageServer的连接信息，最终数据是和一个可用的StorageServer进行传输。
(3)[负载均衡]
store group分配策略：
0：轮询方式
1：指定组
2：平衡负载(选择最大剩余空间的组(卷)上传)
store server分配策略：
0：轮询方式
1：根据 IP 地址进行排序选择第一个服务器( IP 地址最小者)
2：根据优先级进行排序(上传优先级由storage server来设置，参数名为upload_priority)
stroe path分配 ：
0：轮流方式，多个目录依次存放文件
2：选择剩余空间最大的目录存放文件(注意：剩余磁盘空间是动态的，因此存储到的目录或磁盘可能也是变化的)
2.2 Tracker Server (跟踪服务器)
Tracker Server (跟踪服务器) 主要提供容量和备份服务。
[分组管理]以Group为单位，每个Group包含多台Storage Server，数据互为备份，存储容量以Group内容量最小的 storage 为准，以 Group 为单位组织存储方便应用隔离、负载均衡和副本数据定制。
缺点：Group容量受单机存储容量的限制，数据恢复只能依赖Group其他机器重新同步。
[数据同步]文件同步只能在 Group 内的Storage Server之间进行，采用push方式，即源服务器同步给目标服务器。源服务器读取 binlog 文件，将文件内容解析后，按操作命令发送给目标服务器，有目标服务按命令进行操作。
3、上传下载流程
3.1 上传流程解析
3.1.1 选择Tracker Server
集群中的 tracker 之间都是对等的，客户端在上传文件时可任意选择一个 tracker 即可。
3.1.2 分配Group、Stroage Server 和storage path(磁盘或者挂载点)
tracker 接收到上传请求时会先给该文件分配一个可以存储的 Group ，然后在Group中分配一个Storage Server给客户端，最后在接收到客户端写文件请求时，Storage Server 会分配一个数据存储目录并写入。
(该过程中的分配策略详见：[负载均衡])
3.1.3 生成file_id写入并返回
Storage 会生成一个 file_id 来作为当前文件名，file_id 采用 base64 编码，包含：源 storage server ip、文件创建时间、文件大小、文件CRC32校验码 和 随机数。每个存储目录下 有两个256*256个子目录。
Storage 会根据 file_id 进行两次 hash 路由到其中一个子目录中。
最后以file_id为文件名存储文件到该子目录下并返回文件路径给客户端。
最终文件存储路径：
分组|磁盘|子目录|文件名
group1/M00/00/89/eQ6h3FKJf_PRl8p4AUz4wO8tqaA688.apk
[分组]：文件上传时分配 Group。
[磁盘路径]：存储服务器配置的虚拟路径，对应配置参数 store_path 例如：M00对应store_path0，M01对应store_path1。
[两级目录]：存储服务器在每个虚拟磁盘路径下创建的两级目录，用于存储文件。
3.2 下载流程解析
3.2.1 解析路径并路由
tracker 接收 client 发送的下载请求时，tracker 从文件名中解析出 Group、大小、创建时间等信息，然后根据Group 选择一个 storage server 返回。
3.2.2 校验读取并返回
客户端和 Storage Server 建立链接，校验文件是否存在，最终返回文件数据。
缺点：Group之间文件同步是异步进行的，可能上传的文件还未同步到当前访问的 Storage Server 这台机器上或者延迟原因，将导致下载文件出现404。所以引入nginx_fastdfs_module 可以很好的解决同步和延迟问题。
3.3 引入fastdfs_nginx_module组件后的下载架构
FastDFS Nginx Module功能介绍
(1)[防盗链检查]
利用 FastDFS nginx 扩展功能动态生成token，设置http.conf 配置。
开启防盗链功能
http.default_content_type=application/octet-stream
http.mime_types_filename=mime.types
开启token防盗链功能
http.anti_steal.check_token=true
token过期时间
http.anti_steal.token_ttl=900
密钥
http.anti_steal.secret_key=xxx
token 过期后返回的内容
http.anti_steal.token_check_fail=/etc/fdfs/anti-steal.jpg
[token 生成算法]：md5(fileid_without_group + privKey + ts) 同时ts没有超过 ttl 范围。
服务器会自动根据token,st 以及设置的秘钥来验证合法性。访问链接形式如：
http://localhost/G1/M00/00/01/wKgBD01c15nvKU1cAABAOeCdFS466570.jpg?token=b64cd06a53dea4376e43d71cc882f9cb&ts=1297930139
(2)[文件元数据解析]
根据 file_id 获取元数据信息, 包括：源storage ip，文件路径，名称，大小 等。
(3)[文件访问路由]
因文件的file_Id 包含了上传文件时的源 Storage Server IP ，所以在获取不到本机下的文件时(未同步或者延迟情况下)FastDFS 扩展组件，会根据源服务器IP 来重定向或者代理方式获取文件。
重定向模式
配置项response_mode = redirect，服务器返回302，重定向url
http://源storage-ip:port/文件路径?redirect=1
代理模式
配置项response_mode = proxy，使用源storage 地址作为代理proxy的host，其他部分不变
4、同步机制
4.1 同步规则
同步只发生在本组的 Storage Server 之间。源头数据才需要同步，备份数据不需要再次同步。
新增 Storage Server 时，会由已有一台 Storage Server 将已有的所有数据(源头数据和备份数据)同步给新增服务器。
4.2 Binlog 复制
FastDFS 文件同步采用binlog异步复制方式，Storage Server 使用binlog文件记录文件上传、删除等操作，根据Binlog进行文件同步。Binlog中只记录文件ID和操作，不记录文件内容 .binlog 格式如下：
时间戳 | 操作类型 | 文件名
1490251373 C M02/52/CB/CtAqWVjTbm2AIqTkAAACd_nIZ7M797.jpg
操作类型(部分)：
C表示源创建、c表示副本创建
A表示源追加、a表示副本追加
D表示源删除、d表示副本删除
. . . . . . .
4.3 同步流程
新增 Storage Server 后，组内其他 Storage Server 服务器会启动同步线程，在 tracker的协调下向新增服务器发起全量和增量同步操作。
(1)Storage C启动后向tracker 上报所属group、ip、port、版本号、存储目录数、子目录数、启动时间、老数据是否同步完成，当前状态等信息。
(2)tracker 收到Storage C 加入申请请求后，更新本地storage list，返回给C，并适时同步给A、B。
(3)storage C向tracker 申请同步请求，响应后变更自身状态为WAIT_SYNC。
(4)storage A 和B 在心跳周期内从同步到的新storage list 发现没有C，则启动同步线程，先向tracker发起同步申请(TRACKER_PROTO_CMD_STORAGE_SYNC_SRC_REQ),tracker会把同步源IP级同步时间戳返回给A和B,如果源IP和自己本地IP一致，则标记自己作为同步源用来做老数据同步(全量同步源)，如果不一致，则标记自己作为增量同步源(只有在C节点状态为Active时才同步)。该决策是由tracker 选择产生的，不可A、B同时作为同步源，同时同步给C。
(5)同步源(假设是storage A)以 .mark为后缀的文件记录目标机器同步信息，并上报变更storage C状态为SYNCING。
(6)从/data.sync目录下读取binlog.index 中的，binlog文件Id，binlog.000读取逐行读取，进行解析.(详见上面binlog 内格式) 发送数据给storage C ，C接收并保存。
(7)数据同步过程中 storage C 的状态变更过程OFFLINE->ONLINE->ACTIVE。ACTIVE 是最终状态，表示storage C 已对外提供服务。
5、文件存储
5.1 LOSF问题
小文件存储(LOSF)面临的问题：
本地文件系统innode梳理优先，存储小文件数量受限。
目录层级和目录中文件数量会导致访问文件开销很大(IO次数多)。
小文件存储，备份和恢复效率低。
针对小文件存储问题，FastDFS 提供了文件合并解决方案。FastDFS 默认创建大文件为 64M，大文件可以存储很多小文件，容纳一个小文件的空间叫slot，solt 最小256字节，最大16M。小于256字节当256字节存储，超过16M文件单独存储。
5.2 存储方式
(1)[默认存储方式]未开启合并 ，FastDFS生成的file_id 和磁盘上实际存储的文件一一对应。
(2)[合并存储方式]多个file_id对应文件被存储成了一个大文件 。trunk文件名格式：/fastdfs/data/00/000001 文件名从1开始递增。而生成的file_id 更长，会新增16个字节额外内容用来保存偏移量等信息。
如下：
[file_size]：占用大文件的空间(注意按照最小slot-256字节进行对齐)
[mtime]：文件修改时间
[crc32]：文件内容的crc32码
[formatted_ext_name]：文件扩展名
[alloc_size]：文件大小与size相等
[id]：大文件ID如000001
[offset]：文件内容在trunk文件中的偏移量
[size]：文件大小。
5.3 存储空间管理
(1)[Trunk Server]由tracker leader 在一组Storage Server 选择出来的，并通知给该组内所有Storage Server，负责为该组内所有upload操作分配空间。
(2)[空闲平衡树]trunk server 会为每个store_path构造一个空闲平衡树，相同大小的空闲块保存在链表中，每次上传请求时会到根据上传的文件大小到平衡树中查找获取大于或者接近的空闲块，然后从空闲块中分割出多余的作为新的空闲块，重新加入平衡树。如果找不到则会重建一个新的trunk文件，并加入到平衡树中。该分配过程即是一个维护空闲平衡树的过程。
(3)[Trunk Binlog]开启了合并存储后，Trunk Server 会多出一个TrunkBinlog同步。TrunkBinlog记录了TrunkServer 所有分配与回收的空闲块操作，并由Trunk Server同步给同组中其他storage server。
TrunkBinlog格式如下：
时间戳 | 操作类型 | store_path_index | sub_path_high| sub_path_low | file.id| offset | size 1410750754 A 0 0 0 1 0 67108864
各字段含义如下：
[file.id]：TrunkFile文件名，比如 000001
[offset]：在TrunkFile文件中的偏移量
[size]：占用的大小，按照slot对齐
6、文件去重
FastDFS不具备文件去重能力，必须引入FastDHT 来配合完成。FastDHT 是一个键值对的高效分布式hash系统，底层采用Berkeley DB 来做数据库持久化，同步方式使用binlog复制方式。在FastDFS去重场景中，对文件内容做hash，然后判断文件是否一致。在文件上传成功后，查看 Storage存储对应存储路径，会发现返回的是一个软链接，之后每次重复上传都是返回一个指向第一次上传的文件的软链接。也就保证了文件只保存了一份。
(注意：FastDFS不会返回原始文件的索引，返回的全部都是软链接，当所有的软链接都被删除的时候，原始文件也会从FastDFS中被删除)。
7、小结
FastDFS 真正意义上只是一个管理文件的系统(应用级文件系统)，比如管理上传文件、图片等。并不像系统磁盘文件系统NTFS或者FAT 等这种系统级文件系统。
MogileFS一个开源的分布式文件系统
1.应用层——没有特殊的组件要求
2.无单点失败——MogileFS启动的三个组件(存储节点、跟踪器、跟踪用的数据库)，均可运行在多个 机器上，因此没有单点失败。(你也可以将跟踪器和存储节点运行在同一台机器上，这样你就没有必要用4台机器)推荐至少两台机器。
3. 自动的文件复制——文件是基于他们的“类”，文件可以自动的在多个存储节点上复制，这是为了尽量少的复制，才使用“类”的。加入你有的图片站点有三份JPEG图片的拷贝，但实际只有1or2份拷贝，那么Mogile可以重新建立遗失的拷贝数。用这种办法，MogileFS(不做RAID)可以节约在磁盘，否则你将存储同样的拷贝多份，完全没有必要。
4.“比RAID好多了”——在一个非存储区域网络的RAID(non-SAN RAID)的建立中，磁盘是冗余的，但主机不是，如果你整个机器坏了，那么文件也将不能访问。 MogileFS在不同的机器之间进行文件复制，因此文件始终是可用的。
5.传输中立，无特殊协议——MogileFS客户端可以通过NFS或HTTP来和MogileFS的存储节点来通信，但首先需要告知跟踪器一下。
6.简单的命名空间——文件通过一个给定的key来确定，是一个全局的命名空间。你可以自己生成多个命名空间，只要你愿意，但是这样可能在同一MogileFS中，会造成冲突key。
7.不用共享任何东西——MogileFS不需要依靠昂贵的SAN来共享磁盘，每个机器只用维护好自己的磁盘。
8.不需要RAID——在MogileFS中的磁盘可以是做了RAID的也可以是没有，如果是为了安全性着想的话RAID没有必要买了，因为MogileFS已经提供了。
9. 不会碰到文件系统本身的不可知情况——在MogileFS中的存储节点的磁盘可以被格式化成多种格(ext3,reiserFS等等)。 MogilesFS会做自己内部目录的哈希，所以它不会碰到文件系统本身的一些限制，比如一个目录中的最大文件数。你可以放心的使用。
FastFDS和MogileFS的对比
FastDFS设计时借鉴了MogileFS的一些思路。FastDFS是一个完善的分布式文件存储系统，通过客户端API对文件进行读写。可以说，MogileFS的所有功能特性FastDFS都具备，MogileFS网址：http://www.danga.com/mogilefs/。
另外，相对于MogileFS，FastDFS具有如下特点和优势：
1. FastDFS完善程度较高，不需要二次开发即可直接使用；
2. 和MogileFS相比，FastDFS裁减了跟踪用的数据库，只有两个角色：tracker和storage。FastDFS的架构既简化了系统，同时也消除了性能瓶颈；
3. 在系统中增加任何角色的服务器都很容易：增加tracker服务器时，只需要修改storage和client的配置文件(增加一行tracker配置)；增加storage服务器时，通常不需要修改任何配置文件，系统会自动将该卷中已有文件复制到该服务器；
4. FastDFS比MogileFS更高效。表现在如下几个方面：
1)参见上面的第2点，FastDFS和MogileFS相比，没有文件索引数据库，FastDFS整体性能更高；
2)从采用的开发语言上看，FastDFS比MogileFS更底层、更高效。FastDFS用C语言编写，代码量不到2万行，没有依赖其他开源软件或程序包，安装和部署特别简洁；而MogileFS用perl编写；
3)FastDFS直接使用socket通信方式，相对于MogileFS的HTTP方式，效率更高。并且FastDFS使用sendfile传输文件，采用了内存零拷贝，系统开销更小，文件传输效率更高。
5. FastDFS有着详细的设计和使用文档，而MogileFS的文档相对比较缺乏。
6. FastDFS的日志记录非常详细，系统运行时发生的任何错误信息都会记录到日志文件中，当出现问题时方便管理员定位错误所在。
7. FastDFS还对文件附加属性(即meta data，如文件大小、图片宽度、高度等)进行存取，应用不需要使用数据库来存储这些信息。
8. FastDFS从V1.14开始支持相同文件内容只保存一份，这样可以节省存储空间，提高文件访问性能。
MogileFS分布式文件存储解决方案
mogileFS是一个分布式文件存储的解决方案，他由Six Apart开发下面列出了他的一些特性(由mogileFS页面http://www.danga.com/mogilefs/ 介绍翻译而来)
* 应用层——不需要特殊的核心组件
* 无单点失败——MogileFS安装的三个组件(存储节点、跟踪器、跟踪用的数据库)，均可运行在多个 机器上，因此没有单点失败。(你也可以将跟踪器和存储节点运行在同一台机器上，这样你就没有必要用4台机器)推荐至少两台机器。
* 自动的文件复制——基于不同的文件“分类”，文件可以被自动的复制到多个有足够存储空间的存储节点上，这样可以满足这个“类别”的最少复制要求。比如你有一个图片网站，你可以设置原始的JPEG图片需要复制至少三份，但实际只有1or2份拷贝，如果丢失了数据，那么Mogile可以重新建立遗失的拷贝数。用这种办法，MogileFS(不做RAID)可以节约磁盘，否则你将存储同样的拷贝多份，完全没有必要。
* “比RAID好多了”——在一个非存储区域网络的RAID(non-SAN RAID)的建立中，磁盘是冗余的，但主机不是，如果你整个机器坏了，那么文件也将不能访问。 MogileFS在不同的机器之间进行文件复制，因此文件始终是可用的。
* 传输中立，无特殊协议——MogileFS客户端可以通过NFS或HTTP来和MogileFS的存储节点来通信，但首先需要告知跟踪器一下。
* 简单的命名空间——文件通过一个给定的key来确定，是一个全局的命名空间。你可以自己生成多个命名空间，只要你愿意，不过这样可能在同一MogileFS中会造成key冲突。
* 不用共享任何东西——MogileFS不需要依靠昂贵的SAN来共享磁盘，每个机器只用维护好自己的磁盘。
* 不需要RAID——在MogileFS中的磁盘可以是做了RAID的也可以是没有，如果是为了安全性着想的话RAID没有必要买了，因为MogileFS已经提供了。
* 不会碰到文件系统本身的不可知情况——在MogileFS中的存储节点的磁盘可以被格式化成多种格式(ext3,reiserFS等等)。MogilesFS会做自己内部目录的哈希，所以它不会碰到文件系统本身的一些限制，比如一个目录中的最大文件数。你可以放心的使用。
Mogilefs 的网站地址(http:// www.danga.com /mogilefs)
mogileFS 安装步骤( http://durrett.net/mogilefs_setup.html
mogileFS 使用perl 编写的，在安装前你应该先安装好perl。同时mogileFS也需要一个数据库用来保存文件数据的跟踪信息(目前好像可以使用MySQL推荐 , SQLite,Oracle,Postsql)。
mogileFS 适合于静态存储，就是那种一次保存，多次读取型的资源，比如以html方式静态化处理的动态文件，图片文件，其他只提供下载的文件等。
组成MogileFS的组件
1) 数据库(MySQL)部分
你可以用mogdbsetup程序来初始化数据库。数据库保存了Mogilefs的所有元数据，你可以单独拿数据库服务器来做，也可以跟其他程序跑在一起，数据库部分非常重要，类似邮件系统的认证中心那么重要，如果这儿挂了，那么整个Mogilefs将处于不可用状态。因此最好是HA结构。
2)存储节点
mogstored程序的启动将使本机成为一个存储节点。启动时默认去读/etc/mogilefs/mogstored.conf ，具体配置可以参考配置部分。mogstored启动后，便可以通过mogadm增加这台机器到cluster中。一台机器可以只运行一个 mogstored作为存储节点即可，也可以同时运行其他程序。
3)trackers(跟踪器)
mogilefsd即trackers程序，类似mogilefs的wiki上介绍的，trackers做了很多工作，Replication ，Deletion，Query，Reaper，Monitor等等。mogadm,mogtool的所有操作都要跟trackers打交道，Client的一些操作也需要定义好trackers，因此最好同时运行多个trackers来做负载均衡。trackers也可以只运行在一台机器上，也可以跟其他程序运行在一起，只要你配置好他的配置文件即可，默认在/etc/mogilefs/mogilefsd.conf。
4)工具
主要就是mogadm，mogtool这两个工具了，用来在命令行下控制整个mogilefs系统以及查看状态等等。
5)Client
Client实际上是一个Perl的pm，可以写程序调用该pm来使用mogilefs系统，对整个系统进行读写操作。
MogileFS应用中的几个重要概念
domain：最高域，在一个域下key是唯一的。
class：包含在domain中，可以针对每一个class定义保存的份数。
key：对文件的唯一标识。
file：文件。
MogileFS的适用性
由于Mogilefs不支持对一个文件的随机读写，因此注定了只适合做一部分应用。比如图片服务，静态HTML服务。即文件写入后基本上不需要修改的应用，当然你也可以生成一个新的文件覆盖上去。
MogileFS的工作方式
MogileFS由如下一些部分构成:
* Application: 想要 保存/加载 文件的应用
* Tracker (the mogilefsd process): 基于事件的(event-based) 父 进程/消息 总线来管理所有来之于客户端应用的交互(requesting operations to be performed), 包括将请求负载平衡到 “query workers” 中，让mogilefsd的子进程去处理. 你可以在不同的机器上运行两个Tracker, 为了高可用性, 或使用更多的Tracker为了负载平衡(你需要运行多于两个的Tracker). mogilefsd的子进程有:
o Replication — 个机器间复制文件
o Deletion — 从命名空间删除是立即的，从文件系统删除是异步的
o Query — 响应客户端的请求
o Reaper — 在磁盘失败后将文件复制请求重新放到队列中
o Monitor — 监测主机和设配的健康度和状态
o …
* Database — 数据库用来存放MogileFS的元数据 (命名空间, 和文件在哪里). 这应该设置一个高可用性(HA)的环境以防止单点失败.
* Storage Nodes — 实际文件存放的地方. 存储节点是一个HTTP服务器，用来做 删除，存放等事情，任何WebDAV服务器都可以, 不过推荐使用 mogstored 。 mogilefsd 可以配置到两个机器上使用不同端口… mogstored 为所有 DAV 操作 (和流量监测), 并且你自己选择的快速的HTTP服务器用来做 GET 操作(给客户端提供文件). 典型的用户没一个加载点有一个大容量的 SATA 磁盘，他们被加载到 /var/mogdata/devNN.
High-level 流程:
* 应用程序请求打开一个文件 (通过RPC 通知到 tracker, 找到一个可用的机器). 做一个 “create_open” 请求.
* tracker 做一些负载均衡(load balancing)处理，决定应该去哪儿，然后给应用程序一些可能用的位置。
* 应用程序写到其中的一个位置去 (如果写失败，他会重新尝试并写到另外一个位置去).
* 应用程序 (client) 通过”create_close” 告诉tracker文件写到哪里去了.
* tracker 将该名称和域命的名空间关联 (通过数据库来做的)
* tracker, 在后台, 开始复制文件，知道他满足该文件类别设定的复制规则
* 然后,应用程序通过 “get_paths” 请求 domain+key (key == “filename”) 文件, tracker基于每一位置的I/O繁忙情况回复(在内部经过 database/memcache/etc 等的一些抉择处理), 该文件可用的完整 URLs地址列表.
* 应用程序然后按顺序尝试这些URL地址. (tracker’持续监测主机和设备的状态，因此不会返回死连接,默认情况下他对返回列表中的第一个元素做双重检查，除非你不要他这么做..)
FastDFS服务端有两个角色：跟踪器(tracker)和存储节点(storage)。跟踪器主要做调度工作，在访问上起负载均衡的作用。存储节点存储文件，完成文件管理的所有功能：存储、同步和提供存取接口，FastDFS同时对文件的metadata进行管理。所谓文件的meta data就是文件的相关属性，以键值对(key valuepair)方式表示，如：width=1024，其中的key为width，value为1024。文件metadata是文件属性列表，可以包含多个键值对。
FastDFS系统结构如下图所示：
跟踪器和存储节点都可以由一台多台服务器构成。跟踪器和存储节点中的服务器均可以随时增加或下线而不会影响线上服务。其中跟踪器中的所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。
为了支持大容量，存储节点(服务器)采用了分卷(或分组)的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。
当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。FastDFS中的文件标识分为两个部分：卷名和文件名，二者缺一不可。
FastDFS file upload
上传文件交互过程：
1. client询问tracker上传到的storage，不需要附加参数；
2. tracker返回一台可用的storage；
3. client直接和storage通讯完成文件上传。
FastDFS file download
下载文件交互过程：
1. client询问tracker下载文件的storage，参数为文件标识(卷名和文件名)；
2. tracker返回一台可用的storage；
3. client直接和storage通讯完成文件下载。
需要说明的是，client为使用FastDFS服务的调用方，client也应该是一台服务器，它对tracker和storage的调用均为服务器间的调用。下面就其架构做一个简要的介绍。
1、FastDFS原理介绍
FastDFS是一个C语言实现的开源轻量级分布式文件系统。支持 Linux、FreeBSD等Unix系统，解决了大容量的文件存储和高并发访问问题，文件存取实现了负载均衡，适合存储 4KB~500MB 之间的小文件，特别适合以文件为载体的在线服务，如图片、视频、文档等等。
2、FastDFS 架构
FastDFS 由三个部分构成：
客户端(Client)
跟踪服务器(TrackerServer)
存储服务器(StorageServer)
2.1 Tracker Server (跟踪服务器)
Tracker Server (跟踪服务器) 主要是做调度工作，起到负载均衡的作用。
(1)[服务注册]管理StorageServer存储集群，StorageServer启动时，会把自己注册到TrackerServer上，并且定期报告自身状态信息，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。
(2)[服务发现]Client访问StorageServer之前，必须先访问TrackerServer，动态获取到StorageServer的连接信息，最终数据是和一个可用的StorageServer进行传输。
(3)[负载均衡]
store group分配策略：
0：轮询方式
1：指定组
2：平衡负载(选择最大剩余空间的组(卷)上传)
store server分配策略：
0：轮询方式
1：根据 IP 地址进行排序选择第一个服务器( IP 地址最小者)
2：根据优先级进行排序(上传优先级由storage server来设置，参数名为upload_priority)
stroe path分配 ：
0：轮流方式，多个目录依次存放文件
2：选择剩余空间最大的目录存放文件(注意：剩余磁盘空间是动态的，因此存储到的目录或磁盘可能也是变化的)
2.2 Tracker Server (跟踪服务器)
Tracker Server (跟踪服务器) 主要提供容量和备份服务。
[分组管理]以Group为单位，每个Group包含多台Storage Server，数据互为备份，存储容量以Group内容量最小的 storage 为准，以 Group 为单位组织存储方便应用隔离、负载均衡和副本数据定制。
缺点：Group容量受单机存储容量的限制，数据恢复只能依赖Group其他机器重新同步。
[数据同步]文件同步只能在 Group 内的Storage Server之间进行，采用push方式，即源服务器同步给目标服务器。源服务器读取 binlog 文件，将文件内容解析后，按操作命令发送给目标服务器，有目标服务按命令进行操作。
3、上传下载流程
3.1 上传流程解析
3.1.1 选择Tracker Server
集群中的 tracker 之间都是对等的，客户端在上传文件时可任意选择一个 tracker 即可。
3.1.2 分配Group、Stroage Server 和storage path(磁盘或者挂载点)
tracker 接收到上传请求时会先给该文件分配一个可以存储的 Group ，然后在Group中分配一个Storage Server给客户端，最后在接收到客户端写文件请求时，Storage Server 会分配一个数据存储目录并写入。
(该过程中的分配策略详见：[负载均衡])
3.1.3 生成file_id写入并返回
Storage 会生成一个 file_id 来作为当前文件名，file_id 采用 base64 编码，包含：源 storage server ip、文件创建时间、文件大小、文件CRC32校验码 和 随机数。每个存储目录下 有两个256*256个子目录。
Storage 会根据 file_id 进行两次 hash 路由到其中一个子目录中。
最后以file_id为文件名存储文件到该子目录下并返回文件路径给客户端。
最终文件存储路径：
分组|磁盘|子目录|文件名
group1/M00/00/89/eQ6h3FKJf_PRl8p4AUz4wO8tqaA688.apk
[分组]：文件上传时分配 Group。
[磁盘路径]：存储服务器配置的虚拟路径，对应配置参数 store_path 例如：M00对应store_path0，M01对应store_path1。
[两级目录]：存储服务器在每个虚拟磁盘路径下创建的两级目录，用于存储文件。
3.2 下载流程解析
3.2.1 解析路径并路由
tracker 接收 client 发送的下载请求时，tracker 从文件名中解析出 Group、大小、创建时间等信息，然后根据Group 选择一个 storage server 返回。
3.2.2 校验读取并返回
客户端和 Storage Server 建立链接，校验文件是否存在，最终返回文件数据。
缺点：Group之间文件同步是异步进行的，可能上传的文件还未同步到当前访问的 Storage Server 这台机器上或者延迟原因，将导致下载文件出现404。所以引入nginx_fastdfs_module 可以很好的解决同步和延迟问题。
3.3 引入fastdfs_nginx_module组件后的下载架构
FastDFS Nginx Module功能介绍
(1)[防盗链检查]
利用 FastDFS nginx 扩展功能动态生成token，设置http.conf 配置。
开启防盗链功能
http.default_content_type=application/octet-stream
http.mime_types_filename=mime.types
开启token防盗链功能
http.anti_steal.check_token=true
token过期时间
http.anti_steal.token_ttl=900
密钥
http.anti_steal.secret_key=xxx
token 过期后返回的内容
http.anti_steal.token_check_fail=/etc/fdfs/anti-steal.jpg
[token 生成算法]：md5(fileid_without_group + privKey + ts) 同时ts没有超过 ttl 范围。
服务器会自动根据token,st 以及设置的秘钥来验证合法性。访问链接形式如：
http://localhost/G1/M00/00/01/wKgBD01c15nvKU1cAABAOeCdFS466570.jpg?token=b64cd06a53dea4376e43d71cc882f9cb&ts=1297930139
(2)[文件元数据解析]
根据 file_id 获取元数据信息, 包括：源storage ip，文件路径，名称，大小 等。
(3)[文件访问路由]
因文件的file_Id 包含了上传文件时的源 Storage Server IP ，所以在获取不到本机下的文件时(未同步或者延迟情况下)FastDFS 扩展组件，会根据源服务器IP 来重定向或者代理方式获取文件。
重定向模式
配置项response_mode = redirect，服务器返回302，重定向url
http://源storage-ip:port/文件路径?redirect=1
代理模式
配置项response_mode = proxy，使用源storage 地址作为代理proxy的host，其他部分不变
4、同步机制
4.1 同步规则
同步只发生在本组的 Storage Server 之间。源头数据才需要同步，备份数据不需要再次同步。
新增 Storage Server 时，会由已有一台 Storage Server 将已有的所有数据(源头数据和备份数据)同步给新增服务器。
4.2 Binlog 复制
FastDFS 文件同步采用binlog异步复制方式，Storage Server 使用binlog文件记录文件上传、删除等操作，根据Binlog进行文件同步。Binlog中只记录文件ID和操作，不记录文件内容 .binlog 格式如下：
时间戳 | 操作类型 | 文件名
1490251373 C M02/52/CB/CtAqWVjTbm2AIqTkAAACd_nIZ7M797.jpg
操作类型(部分)：
C表示源创建、c表示副本创建
A表示源追加、a表示副本追加
D表示源删除、d表示副本删除
. . . . . . .
4.3 同步流程
新增 Storage Server 后，组内其他 Storage Server 服务器会启动同步线程，在 tracker的协调下向新增服务器发起全量和增量同步操作。
(1)Storage C启动后向tracker 上报所属group、ip、port、版本号、存储目录数、子目录数、启动时间、老数据是否同步完成，当前状态等信息。
(2)tracker 收到Storage C 加入申请请求后，更新本地storage list，返回给C，并适时同步给A、B。
(3)storage C向tracker 申请同步请求，响应后变更自身状态为WAIT_SYNC。
(4)storage A 和B 在心跳周期内从同步到的新storage list 发现没有C，则启动同步线程，先向tracker发起同步申请(TRACKER_PROTO_CMD_STORAGE_SYNC_SRC_REQ),tracker会把同步源IP级同步时间戳返回给A和B,如果源IP和自己本地IP一致，则标记自己作为同步源用来做老数据同步(全量同步源)，如果不一致，则标记自己作为增量同步源(只有在C节点状态为Active时才同步)。该决策是由tracker 选择产生的，不可A、B同时作为同步源，同时同步给C。
(5)同步源(假设是storage A)以 .mark为后缀的文件记录目标机器同步信息，并上报变更storage C状态为SYNCING。
(6)从/data.sync目录下读取binlog.index 中的，binlog文件Id，binlog.000读取逐行读取，进行解析.(详见上面binlog 内格式) 发送数据给storage C ，C接收并保存。
(7)数据同步过程中 storage C 的状态变更过程OFFLINE->ONLINE->ACTIVE。ACTIVE 是最终状态，表示storage C 已对外提供服务。
5、文件存储
5.1 LOSF问题
小文件存储(LOSF)面临的问题：
本地文件系统innode梳理优先，存储小文件数量受限。
目录层级和目录中文件数量会导致访问文件开销很大(IO次数多)。
小文件存储，备份和恢复效率低。
针对小文件存储问题，FastDFS 提供了文件合并解决方案。FastDFS 默认创建大文件为 64M，大文件可以存储很多小文件，容纳一个小文件的空间叫slot，solt 最小256字节，最大16M。小于256字节当256字节存储，超过16M文件单独存储。
5.2 存储方式
(1)[默认存储方式]未开启合并 ，FastDFS生成的file_id 和磁盘上实际存储的文件一一对应。
(2)[合并存储方式]多个file_id对应文件被存储成了一个大文件 。trunk文件名格式：/fastdfs/data/00/000001 文件名从1开始递增。而生成的file_id 更长，会新增16个字节额外内容用来保存偏移量等信息。
如下：
[file_size]：占用大文件的空间(注意按照最小slot-256字节进行对齐)
[mtime]：文件修改时间
[crc32]：文件内容的crc32码
[formatted_ext_name]：文件扩展名
[alloc_size]：文件大小与size相等
[id]：大文件ID如000001
[offset]：文件内容在trunk文件中的偏移量
[size]：文件大小。
5.3 存储空间管理
(1)[Trunk Server]由tracker leader 在一组Storage Server 选择出来的，并通知给该组内所有Storage Server，负责为该组内所有upload操作分配空间。
(2)[空闲平衡树]trunk server 会为每个store_path构造一个空闲平衡树，相同大小的空闲块保存在链表中，每次上传请求时会到根据上传的文件大小到平衡树中查找获取大于或者接近的空闲块，然后从空闲块中分割出多余的作为新的空闲块，重新加入平衡树。如果找不到则会重建一个新的trunk文件，并加入到平衡树中。该分配过程即是一个维护空闲平衡树的过程。
(3)[Trunk Binlog]开启了合并存储后，Trunk Server 会多出一个TrunkBinlog同步。TrunkBinlog记录了TrunkServer 所有分配与回收的空闲块操作，并由Trunk Server同步给同组中其他storage server。
TrunkBinlog格式如下：
时间戳 | 操作类型 | store_path_index | sub_path_high| sub_path_low | file.id| offset | size 1410750754 A 0 0 0 1 0 67108864
各字段含义如下：
[file.id]：TrunkFile文件名，比如 000001
[offset]：在TrunkFile文件中的偏移量
[size]：占用的大小，按照slot对齐
6、文件去重
FastDFS不具备文件去重能力，必须引入FastDHT 来配合完成。FastDHT 是一个键值对的高效分布式hash系统，底层采用Berkeley DB 来做数据库持久化，同步方式使用binlog复制方式。在FastDFS去重场景中，对文件内容做hash，然后判断文件是否一致。在文件上传成功后，查看 Storage存储对应存储路径，会发现返回的是一个软链接，之后每次重复上传都是返回一个指向第一次上传的文件的软链接。也就保证了文件只保存了一份。
(注意：FastDFS不会返回原始文件的索引，返回的全部都是软链接，当所有的软链接都被删除的时候，原始文件也会从FastDFS中被删除)。
7、小结
FastDFS 真正意义上只是一个管理文件的系统(应用级文件系统)，比如管理上传文件、图片等。并不像系统磁盘文件系统NTFS或者FAT 等这种系统级文件系统。
MogileFS一个开源的分布式文件系统
1.应用层——没有特殊的组件要求
2.无单点失败——MogileFS启动的三个组件(存储节点、跟踪器、跟踪用的数据库)，均可运行在多个 机器上，因此没有单点失败。(你也可以将跟踪器和存储节点运行在同一台机器上，这样你就没有必要用4台机器)推荐至少两台机器。
3. 自动的文件复制——文件是基于他们的“类”，文件可以自动的在多个存储节点上复制，这是为了尽量少的复制，才使用“类”的。加入你有的图片站点有三份JPEG图片的拷贝，但实际只有1or2份拷贝，那么Mogile可以重新建立遗失的拷贝数。用这种办法，MogileFS(不做RAID)可以节约在磁盘，否则你将存储同样的拷贝多份，完全没有必要。
4.“比RAID好多了”——在一个非存储区域网络的RAID(non-SAN RAID)的建立中，磁盘是冗余的，但主机不是，如果你整个机器坏了，那么文件也将不能访问。 MogileFS在不同的机器之间进行文件复制，因此文件始终是可用的。
5.传输中立，无特殊协议——MogileFS客户端可以通过NFS或HTTP来和MogileFS的存储节点来通信，但首先需要告知跟踪器一下。
6.简单的命名空间——文件通过一个给定的key来确定，是一个全局的命名空间。你可以自己生成多个命名空间，只要你愿意，但是这样可能在同一MogileFS中，会造成冲突key。
7.不用共享任何东西——MogileFS不需要依靠昂贵的SAN来共享磁盘，每个机器只用维护好自己的磁盘。
8.不需要RAID——在MogileFS中的磁盘可以是做了RAID的也可以是没有，如果是为了安全性着想的话RAID没有必要买了，因为MogileFS已经提供了。
9. 不会碰到文件系统本身的不可知情况——在MogileFS中的存储节点的磁盘可以被格式化成多种格(ext3,reiserFS等等)。 MogilesFS会做自己内部目录的哈希，所以它不会碰到文件系统本身的一些限制，比如一个目录中的最大文件数。你可以放心的使用。
FastFDS和MogileFS的对比
FastDFS设计时借鉴了MogileFS的一些思路。FastDFS是一个完善的分布式文件存储系统，通过客户端API对文件进行读写。可以说，MogileFS的所有功能特性FastDFS都具备，MogileFS网址：http://www.danga.com/mogilefs/。
另外，相对于MogileFS，FastDFS具有如下特点和优势：
1. FastDFS完善程度较高，不需要二次开发即可直接使用；
2. 和MogileFS相比，FastDFS裁减了跟踪用的数据库，只有两个角色：tracker和storage。FastDFS的架构既简化了系统，同时也消除了性能瓶颈；
3. 在系统中增加任何角色的服务器都很容易：增加tracker服务器时，只需要修改storage和client的配置文件(增加一行tracker配置)；增加storage服务器时，通常不需要修改任何配置文件，系统会自动将该卷中已有文件复制到该服务器；
4. FastDFS比MogileFS更高效。表现在如下几个方面：
1)参见上面的第2点，FastDFS和MogileFS相比，没有文件索引数据库，FastDFS整体性能更高；
2)从采用的开发语言上看，FastDFS比MogileFS更底层、更高效。FastDFS用C语言编写，代码量不到2万行，没有依赖其他开源软件或程序包，安装和部署特别简洁；而MogileFS用perl编写；
3)FastDFS直接使用socket通信方式，相对于MogileFS的HTTP方式，效率更高。并且FastDFS使用sendfile传输文件，采用了内存零拷贝，系统开销更小，文件传输效率更高。
5. FastDFS有着详细的设计和使用文档，而MogileFS的文档相对比较缺乏。
6. FastDFS的日志记录非常详细，系统运行时发生的任何错误信息都会记录到日志文件中，当出现问题时方便管理员定位错误所在。
7. FastDFS还对文件附加属性(即meta data，如文件大小、图片宽度、高度等)进行存取，应用不需要使用数据库来存储这些信息。
8. FastDFS从V1.14开始支持相同文件内容只保存一份，这样可以节省存储空间，提高文件访问性能。
MogileFS分布式文件存储解决方案
mogileFS是一个分布式文件存储的解决方案，他由Six Apart开发下面列出了他的一些特性(由mogileFS页面http://www.danga.com/mogilefs/ 介绍翻译而来)
* 应用层——不需要特殊的核心组件
* 无单点失败——MogileFS安装的三个组件(存储节点、跟踪器、跟踪用的数据库)，均可运行在多个 机器上，因此没有单点失败。(你也可以将跟踪器和存储节点运行在同一台机器上，这样你就没有必要用4台机器)推荐至少两台机器。
* 自动的文件复制——基于不同的文件“分类”，文件可以被自动的复制到多个有足够存储空间的存储节点上，这样可以满足这个“类别”的最少复制要求。比如你有一个图片网站，你可以设置原始的JPEG图片需要复制至少三份，但实际只有1or2份拷贝，如果丢失了数据，那么Mogile可以重新建立遗失的拷贝数。用这种办法，MogileFS(不做RAID)可以节约磁盘，否则你将存储同样的拷贝多份，完全没有必要。
* “比RAID好多了”——在一个非存储区域网络的RAID(non-SAN RAID)的建立中，磁盘是冗余的，但主机不是，如果你整个机器坏了，那么文件也将不能访问。 MogileFS在不同的机器之间进行文件复制，因此文件始终是可用的。
* 传输中立，无特殊协议——MogileFS客户端可以通过NFS或HTTP来和MogileFS的存储节点来通信，但首先需要告知跟踪器一下。
* 简单的命名空间——文件通过一个给定的key来确定，是一个全局的命名空间。你可以自己生成多个命名空间，只要你愿意，不过这样可能在同一MogileFS中会造成key冲突。
* 不用共享任何东西——MogileFS不需要依靠昂贵的SAN来共享磁盘，每个机器只用维护好自己的磁盘。
* 不需要RAID——在MogileFS中的磁盘可以是做了RAID的也可以是没有，如果是为了安全性着想的话RAID没有必要买了，因为MogileFS已经提供了。
* 不会碰到文件系统本身的不可知情况——在MogileFS中的存储节点的磁盘可以被格式化成多种格式(ext3,reiserFS等等)。MogilesFS会做自己内部目录的哈希，所以它不会碰到文件系统本身的一些限制，比如一个目录中的最大文件数。你可以放心的使用。
Mogilefs 的网站地址(http:// www.danga.com /mogilefs)
mogileFS 安装步骤( http://durrett.net/mogilefs_setup.html
mogileFS 使用perl 编写的，在安装前你应该先安装好perl。同时mogileFS也需要一个数据库用来保存文件数据的跟踪信息(目前好像可以使用MySQL推荐 , SQLite,Oracle,Postsql)。
mogileFS 适合于静态存储，就是那种一次保存，多次读取型的资源，比如以html方式静态化处理的动态文件，图片文件，其他只提供下载的文件等。
组成MogileFS的组件
1) 数据库(MySQL)部分
你可以用mogdbsetup程序来初始化数据库。数据库保存了Mogilefs的所有元数据，你可以单独拿数据库服务器来做，也可以跟其他程序跑在一起，数据库部分非常重要，类似邮件系统的认证中心那么重要，如果这儿挂了，那么整个Mogilefs将处于不可用状态。因此最好是HA结构。
2)存储节点
mogstored程序的启动将使本机成为一个存储节点。启动时默认去读/etc/mogilefs/mogstored.conf ，具体配置可以参考配置部分。mogstored启动后，便可以通过mogadm增加这台机器到cluster中。一台机器可以只运行一个 mogstored作为存储节点即可，也可以同时运行其他程序。
3)trackers(跟踪器)
mogilefsd即trackers程序，类似mogilefs的wiki上介绍的，trackers做了很多工作，Replication ，Deletion，Query，Reaper，Monitor等等。mogadm,mogtool的所有操作都要跟trackers打交道，Client的一些操作也需要定义好trackers，因此最好同时运行多个trackers来做负载均衡。trackers也可以只运行在一台机器上，也可以跟其他程序运行在一起，只要你配置好他的配置文件即可，默认在/etc/mogilefs/mogilefsd.conf。
4)工具
主要就是mogadm，mogtool这两个工具了，用来在命令行下控制整个mogilefs系统以及查看状态等等。
5)Client
Client实际上是一个Perl的pm，可以写程序调用该pm来使用mogilefs系统，对整个系统进行读写操作。
MogileFS应用中的几个重要概念
domain：最高域，在一个域下key是唯一的。
class：包含在domain中，可以针对每一个class定义保存的份数。
key：对文件的唯一标识。
file：文件。
MogileFS的适用性
由于Mogilefs不支持对一个文件的随机读写，因此注定了只适合做一部分应用。比如图片服务，静态HTML服务。即文件写入后基本上不需要修改的应用，当然你也可以生成一个新的文件覆盖上去。
MogileFS的工作方式
MogileFS由如下一些部分构成:
* Application: 想要 保存/加载 文件的应用
* Tracker (the mogilefsd process): 基于事件的(event-based) 父 进程/消息 总线来管理所有来之于客户端应用的交互(requesting operations to be performed), 包括将请求负载平衡到 “query workers” 中，让mogilefsd的子进程去处理. 你可以在不同的机器上运行两个Tracker, 为了高可用性, 或使用更多的Tracker为了负载平衡(你需要运行多于两个的Tracker). mogilefsd的子进程有:
o Replication — 个机器间复制文件
o Deletion — 从命名空间删除是立即的，从文件系统删除是异步的
o Query — 响应客户端的请求
o Reaper — 在磁盘失败后将文件复制请求重新放到队列中
o Monitor — 监测主机和设配的健康度和状态
o …
* Database — 数据库用来存放MogileFS的元数据 (命名空间, 和文件在哪里). 这应该设置一个高可用性(HA)的环境以防止单点失败.
* Storage Nodes — 实际文件存放的地方. 存储节点是一个HTTP服务器，用来做 删除，存放等事情，任何WebDAV服务器都可以, 不过推荐使用 mogstored 。 mogilefsd 可以配置到两个机器上使用不同端口… mogstored 为所有 DAV 操作 (和流量监测), 并且你自己选择的快速的HTTP服务器用来做 GET 操作(给客户端提供文件). 典型的用户没一个加载点有一个大容量的 SATA 磁盘，他们被加载到 /var/mogdata/devNN.
High-level 流程:
* 应用程序请求打开一个文件 (通过RPC 通知到 tracker, 找到一个可用的机器). 做一个 “create_open” 请求.
* tracker 做一些负载均衡(load balancing)处理，决定应该去哪儿，然后给应用程序一些可能用的位置。
* 应用程序写到其中的一个位置去 (如果写失败，他会重新尝试并写到另外一个位置去).
* 应用程序 (client) 通过”create_close” 告诉tracker文件写到哪里去了.
* tracker 将该名称和域命的名空间关联 (通过数据库来做的)
* tracker, 在后台, 开始复制文件，知道他满足该文件类别设定的复制规则
* 然后,应用程序通过 “get_paths” 请求 domain+key (key == “filename”) 文件, tracker基于每一位置的I/O繁忙情况回复(在内部经过 database/memcache/etc 等的一些抉择处理), 该文件可用的完整 URLs地址列表.
* 应用程序然后按顺序尝试这些URL地址. (tracker’持续监测主机和设备的状态，因此不会返回死连接,默认情况下他对返回列表中的第一个元素做双重检查，除非你不要他这么做..)
该文章最后由 阿炯 于 2022-05-04 11:32:02 更新，目前是第 3 版。