fdfs是一个开源分布式存储解决方案，整个集群节点分为storage和tracker

storage真正的存储文件的节点，集群中可以有很多个storage节点，每个节点都是平级的，互为备份。tracker负责协调和管理整个集群，集群中可以有多个tracker，它们都是平级的，为了提高系统的稳定性和吞吐量，建议部署多个tracker。

集群关系

多个(M)tracker对应多个(N)storage，一般M<N，当然为了节约服务器资源，一台机器上可以既有tracker也有storage存在；storage属于最基本的存储单元，每个storage隶属于一个group，每个group可以有很多storage，在同一个group的storage他们互为副本，存储的文件都是一样的；正因为它们互相备份，所以group的存储能力，取决于group里面的storage的最小存储能力。集群的存储能力由集群中group的数量决定，而group的存储能力是由storage的data目录的存储能力，也就是挂载的磁盘的大小决定，当然这个存储路径可以写多个，可以挂载多个磁盘，但是同一group的storage配置的data目录的路径数量必须一致，也就是不能有的配置了一个存储路径，有的配置了多个存储路径，由此看来，storage的存储能力进而也会影响着整个集群的存储能力。集群扩容，可以根据项目需求，增加group的数量或者增加storage的存储能力(磁盘扩容或者增加存储磁盘目录)，前者相对较简单，后者相对比较难，需要为同group的每个storage扩容。

上传流程

客户端根据自己持有的tracker server地址，轮询向tracker发送上传请求，每个tracker都是一样的，tracker根据每个group的存储能力以及group内storage的上传策略，选择一个storage返回给客户端。客户端直接和返回的storage建立连接上传文件，storage存储文件并返回文件的id，这个id其实是这个文件在这个服务器的存储路径。服务器接收到文件的时候先对文件生成新的名字，生成策略会加入本机的IP地址、时间戳、文件大小等信息，然后得到一个字符串就是文件名，然后再把这个文件名按照一定的算法得到一级目录和二次目录，最后拼上刚才的文件名就是返回给客户端的id；可以看到上传后不会保存文件的原始名，所以想保存文件的原始名的话，最好和上传后得到的id一块保存，以便需要的时候做展示。服务器在完成自己文件存储后，会向同group的其他storage同步刚才上传的文件。

下载流程

客户端拿着文件id去请求tracker要进行文件下载，tracker根据拿到的id解析出此文件被上传的原始storage，然后根据负载均衡策略和原始storage和其他节点的同步进度，返回一个合适的可以下载文件的节点。客户端和返回的storage节点建立连接下载文件。

新storage节点加入

storage启动后，向配置的tracker注册自己，然后向tracker询问自己从哪个机器同步数据。tracker收到请求后根据当前组内的机器状态分配一台ACTIVE的storage，加上当前的时间戳一块返回新加入节点；并且在本地记录该信息，同时将新机器状态设置成WAIT_SYNC。新节点收到返回的源storage和时间戳，记录到data/.data_init_flag文件的sync_src_server和sync_until_timestamp两个字段，并且将sync_old_done字段更新成1，表示已完成获取源主机的操作。由于其他的storage在不断的和tracker保持心跳，在心跳过程中得知新加入的节点以及对应的源storage节点、同步截至时间，然后检查自己是不是对应的源storage节点；如果不是，将信息写入到“新加入节点IP_端口号.mark”文件之中，其中need_sync_old=0，sync_old_done=0，util_timestamp = 源同步截止时间。然后等待新加入节点状态变更为ACTIVE，然后同步本机此时间戳以后的源文件，注意这个同步只同步此节点作为源的文件，也就是时间戳以后binglog文件中对应的大写操作符的文件。如果是的话，则将信息写入到“新加入节点IP_端口号.mark”文件之中，其中need_sync_old=1，sync_old_done=0，util_timestamp = 查询到的源同步截止时间，并请求tracker将新加入节点的状态设置成SYNING；然后启动一个线程从头开始读取binlog文件，同步时间戳之前的全部文件给新加入节点，同步过程中也会记录最后同步的binlog的offset，假如宕机了，下次启动后也可以根据offset继续进行同步。当源节点同步完成的时候，请求Tracker将新加入节点状态设置成OFFLINE，此时源同步完成。在下一个心跳中，tracker会将新加入节点状态设置成ACTIVE，此时新机器加入完毕。

取巧：如果新增副本节点B，可以先人工选择一节点A作为拷贝源，把A节点自身的data/sync目录下的同步时间比较相近(也就是偏移量最大)的mark文件复制一份为B_port.mark，同时把同group的其他storage的data/sync/A_port.mark文件复制一份为B_port.mark，然后把A节点的数据手动复制到B节点，然后启动B节点，最后让节点之间自动完成最近的增量同步，这样效率会比较高，因为节点间的单线程同步太慢。

新增加tracker

如果新增加一台tracker server，storage server连接该tracker server，发现该tracker server返回的本组storage server列表比本机记录的要少，就会将该tracker server上没有的storage server同步给该tracker server。

fdfs空间扩容

在集群创建初期，集群的存储能力肯定是有限的，那么随着业务的增长，fdfs的空闲空间肯定会越来越小，如果剩余空间小于磁盘的10%(默认)的话，就会导致上传异常(errno code:28)不能再继续往集群中上传文件，由于上传失败会导致大量的重试，最糟糕的情况就是大量的上传重试导致集群崩溃，此时本能正常提供读取文件的服务也会收到影响。如果说很不幸，你们的磁盘没有做 LVM的话，那么就不能在线扩容磁盘空间，所以能做的只有增加group数量或者同时增加group内的storage的数据存储目录Path，这样的话需要为每台机器新增加一块磁盘。

fdfs数据迁移

如果迁移后，机器IP不变的话，那很好弄，就像关机开机一样简单。如果说迁移后IP发生了变化，默认安装，那么需要注意，tracker server上需要调整的文件data/storage_groups_new.dat，data/storage_servers_new.dat，data/storage_sync_timestamp.dat；在数据复制到新机器后，需要在新机器storage上更改.data_init_flag文件，把sync_src_server置空。另外把属于同一group的其他storage的data/sync目录下对应的“迁移前IP_端口号.mark”这个文件改为“迁移后IP_端口号.mark”，然后重启迁移后的机器就可以了。如果IP变化，采用自定义server ID模式安装，那么只需要修改stroage_ids.conf文件(据说未验证)

fdfs的最早时间原则

假如group1下面有3个storage，一个文件F被上传到As，如果配置的下载策略是轮询的话，那么被轮询的s怎么确定已经同步到了F呢？

每个s会定期告知tracker，自己往其他节点上已经同步的文件时间戳，这个时间戳列表存在tracker的/data/storage_sync_timestamp.dat文件中。前面说了，从文件的Id可以解析出源s以及文件的上传的时间戳等信息，那么如果说往其中一个节点上同步的时间戳大于接续出来的时间戳，那么就可以肯定这个文件肯定在这个节点上，进而可以通过轮询负载服务器压力。

fdfs常见的文件说明(非配置文件)

data/.data_init_flag这个文件在s节点加入的时候创建；

storage_join_time=1000000000  #节点加入的时间sync_old_done=1			      #表示已完成获取源主机的操作sync_src_server=			 #已获取源主机IPsync_until_timestamp=0			#源s同步此时间戳之前的全量文件

data/sync/IP_Port.mark

binlog_index=2   #已经同步到的binlog indexbinlog_offset=986836772  #同步的偏移量need_sync_old=1			#是否需要全量同步sync_old_done=1			#是否已完成全量同步until_timestamp=1483511493	#全量同步的截至时间scan_row_count=53124322		#扫描多少行binglogsync_row_count=9180742		#同步多少行binlog

欢迎大家点赞评论关注收藏转发，关注微信公众号：芝麻技术栈