纯干货分享 | 不懂的快来，五分钟带你了解FastDFS:03---fastdfs的工作原理

一、文件上传
FastDFS 提供基本的文件访问接口，如 upload、download、append、delete 等

①选择 tracker server
集群中 tracker 之间是对等关系，客户端在上传文件时可用任意选择一个tracker
②选择存储 group
当 tracker 接收到 upload file 的请求时，会为该文件分配一个可以存储文件的group
目前支持选择 group 的规则为：
round robin（对所有的组进行轮询使用）
load balance（选择最大剩余空间的组上传文件）
specify group（指定group上传）
③选择 storage server
当选定 group 后，tracker会在group内选择一个storage server给客户端
目前支持选择 server 的规则为：
round robin（所有 server 轮询使用(默认)）
根据IP地址进行排序选择第一个服务器(IP 地址最小者)
根据优先级进行排序（上传优先级由storage server来设置，参数为upload_priority）
④选择 storage path(磁盘或者挂载点)
当分配好 storage server 后，客户端将向storage发送写文件请求，storage会将文件分配一 个数据存储目录
目前支持选择存储路径的规则为：
round robin（轮询(默认)）
load balance，选择使用剩余空间最大的存储路径
⑤选择下载服务器
目前支持的规则为：
轮询方式，可以下载当前文件的任一storage server
从源storage server下载
⑥生成 file_id
选择存储目录后，storage会生成一个file_id，采用 Base64 编码，包含字段包括：storage server ip、文件创建时间、文件大小、文件CRC32校验码和随机数
每个存储目录下有两个256*256=65536个子目录，storage会按文件file_id进行两次hash，路由到其中一个子目录，然后将文件已 file_id为文件名存储到该子目录下，最后生成文件路径：group名称、虚拟磁盘路径、数据两级目录、file_id。例如：
group1/M00/02/44/wKgDre34E8wAAAAAAAAGkEIYJK42378.sh

例如下面是一个storage的存储数据的目录（由store_path0选项指定），data目录下有255个目录，每个目录下又有255个目录：

其中：
组名：文件上传后所在的存储组的名称，在文件上传成功后由存储服务器返回，需要客户端自行保存
虚拟磁盘路径：存储服务器配置的虚拟路径，与磁盘选项store_path*参数对应
数据两级目录：存储服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件
二、同步机制
新增tracker服务器数据同步问题
由于storage上配置了所有的tracker，storage和tracker之间的通信是由 storage server 主动发起的，storage为每个tracker启动一个线程进行通信
在通信过程中，若发现该tracker返回的本组storage列表比本机记录少，就会将该tracker上没有的storage同步给该 tracker，这样的机制使得tracker之间是对等关系，数据保持一致
新增storage服务器数据同步问题
若新增storage或者其状态发生变化，tracker都会将storage列表同步给该组内所有storage
以新增storage为例，因为新加入的storage会主动连接tracker，tracker发现有新的storage加入，就会将该组内所有的storage返回给新加入的storage，并重新将该组的storage列表返回给该组内的其他storage
组内storage数据同步问题
组内storage之间是对等的，文件上传、删除等操作可以在组内任意一台storage上进行。文件同步只能在同组内的storage之间进行，采用push方式， 即源服务器同步到目标服务器
A. 只在同组内的storage server之间进行同步
B. 源数据才需要同步，备份数据不再同步
C. 特例：新增storage server时，由其中一台将已有所有数据（包括源数据和备份数据）同步到新增服务器
storage server的7种状态，通过命令fdfs_monitor /etc/fdfs/client.conf可以查看ip_addr选项显示storage server当前状态
INIT：初始化，尚未得到同步已有数据的源服务器
WAIT_SYNC：等待同步，已得到同步已有数据的源服务器
SYNCING：同步中
DELETED：已删除，该服务器从本组中摘除
OFFLINE：离线
ONLINE：在线，尚不能提供服务
ACTIVE：在线，可以提供服务
例如，现在在组内增加storage serverA状态变化过程如下：
①storage server A主动连接tracker，此时tracker将storage serverA状态设置为INIT
②storage server A向tracker询问追加同步的源服务器和追加同步截止时间点(当前时间)，若组内只有storage server A或者上传文件数为0，则告诉新机器不需要数据同步，storage server A状态设置为ONLINE ；若组内没有active状态机器，就返回错误给新机器，新机器睡眠尝试；否则tracker将其状态设置为 WAIT_SYNC
③假如分配了storage server B为同步源服务器和截至时间点，那么storage server B会将截至时间点之前的所有数据同步给 storage server A，并请求 tracker 设置 storage server A 状态为 SYNCING；到了截至时间点后，storage server B 向 storage server A 的同步将由追加同步切换为正常 binlog 增量同步，当取不到更多的 binlog 时，请求tracker将 storage server A 设置为OFFLINE状态，此时源同步完成
④storage server B 向 storage server A 同步完所有数据，暂时没有数据要同步时， storage server B 请求tracker将 storage server A 的状态设置为 ONLINE
⑤当storage server A向tracker发起心跳时，tracker将其状态更 改为 ACTIVE，之后就是增量同步(binlog)

备注：
1.整个源同步过程是源机器启动一个同步线程，将数据 push 到新机器，最大达到一个磁盘的IO，不能并发
2.由于源同步截止条件是取不到binlog，系统繁忙，不断有新数据写入的情况，将会导致一直无法完成源同步过程
三、文件下载
流程如下：
client发送下载请求给某个tracker，必须带上文件名信息，tracker从文件名中解析出文件的group、大小、创建时间等信息，然后为该请求选择一个storage用于读请求
由于group内的文件同步在后台是异步进行的，可能出现文件没有同步到其他storage server上或者延迟的问题， 后面我们在使用nginx_fastdfs_module模块可以很好解决这一问题

四、文件合并
小文件合并存储主要解决的问题：
本地文件系统inode数量有限，存储小文件的数量受到限制
多级目录+目录里很多文件，导致访问文件的开销很大（可能导致很多次IO）
按小文件存储，备份和恢复效率低
海量小文件存储问题请参考：
https://blog.csdn.net/liuaigui/article/details/9981135
https://blog.csdn.net/kidd_3/article/details/6909097
FastDFS合并存储原理分析可参阅： https://blog.csdn.net/hfty290/article/details/42026215#comments
FastDFS的合并存储功能
FastDFS提供合并存储功能，默认创建的大文件为64MB，然后在该大文件中存储很多小文件
大文件中容纳一个小文件的空间称作一个Slot：
规定Slot最小值为256字节，最大为16MB
即小于 256 字节的文件也要占用256 字节，超过16MB的文件独立存储
为了支持文件合并机制，FastDFS生成的文件file_id需要额外增加16个字节
合并后的文件叫trunk file：
每个trunk file由一个id唯一标识，trunk file由group内的trunk server负责创建（trunk server是tracker选出来的），并同步到group内其他的storage
文件存储合并存储到trunk file后，根据其文件偏移量就能从trunk file中读取文件
————————————————
原文链接： https://blog.csdn.net/qq_41453285/article/details/107155643