FastDFS文件同步机制分析

数据文件storage_groups.dat和storage_servers.dat中的记录之间以换行符（\n）分隔，字段之间以英文逗号（,）分隔。

可以使用tail -f logs/trackerd.log查看打印信息，这对有报错时进行日志分析非常有用。

（1）storage_changelog.dat。例如：

（2）storage_groups_new.dat。例如：

（3）storage_servers.dat。例如：

（4）主要参数如下：

重点了解sync 目录及文件结构。

（1）binlog.index中只有一个数据项：当前binlog的文件索引号 binlog.###。

（2）binlog.###为索引号对应的3位十进制字符，不足三位，前面补0。索引号基于0，最大为999。一个binlog文件最大为1GB。记录之间以换行符（\n）分隔，字段之间以英文空格分隔。字段依次为：

（3）$ {ip_addr}_${port}.mark：ip_addr为同步的目标服务器IP地址，port为本组storage server端口。例如：10.0.0.1_23000.mark。各个参数如下：

（4）如果还有其他storage，则有更多的${ip_addr}_${port}.mark，比如10.0.0.2_23000.mark 。

思考：文件上传成功后，其它的storage server才开始同步，其它的storage server怎么去感知？tracker server是怎么通知storage server？

storage定时发送心跳包到tracker，并附带同步的时间节点，tracker会返回其他storage的状态。

正常文件上传完成后，就记录进binlog缓存中，系统定时刷入binlog文件。

系统有线程定时读取binlog文件，当有新增行时，判断该记录是源文件记录还是副本文件记录。

系统只主动发送源文件，副本文件不做处理（非启动时流程）。

线程：

storage的状态：

同步命令：

例如192.168.0.104服务器的sync log：

如果有不只2个storage的时候，则该目录还有更多的 .mark文件。

FastDFS文件同步采用binlog异步复制方式。storage server使用binlog文件记录文件上传、删除等操作，根据binlog进行文件同步。binlog中只记录文件ID和操作，不记录文件内容。

例如：

可以看到，binlog文件有三列，依次为：时间戳，操作类型，文件ID（不带group名称）。

文件操作类型采用单个字母编码，其中源头操作用大写字母表示，被同步的操作为对应的小写字母。文件操作字母含义如下：

注意：源表示客户端直接操作的那个Storage即为源，，其他的Storage都为副本。

同组内的storage server之间是对等的，文件上传、删除等操作可以在任意一台storage server上进行。

文件同步只在同组内的storage server之间进行，采用push方式，即源头服务器同步给本组的其他存储服务器。对于同组的其他storage server，一台storage server分别启动一个线程进行文件同步。

文件同步采用增量方式，记录已同步的位置到mark文件中。mark文件存放路径为：

mark文件内容示例：

（1）只在同组内的storage server之间进行同步。

（2） 源头数据才需要同步，备份数据不需要再次同步，否则就构成环路了，源数据和备份数据区 分是用binlog的操作类型来区分，操作类型是大写字母，表示源数据，小写字母表示备份数据。

（3）当新增一台storage server时，由已有的一台storage server将已有的所有数据（包括源头数据和备份数据）同步给该新增服务器。

增量同步：storage server之间已经在运行，它们之间的数据同步就是增量同步发。

全量同步：新增一台storage server时，由已有的一台storage server将已有的所有数据（包括源头数据和备份数据）同步给该新增服务器，这就是全量同步。

在FastDFS之中，每个Storaged之间的同步都是由一个独立线程负责的，该线程中的所有操作都是以同步方式执行的。比如一组服务器有A、B、C三台机器，那么在每台机器上都有两个线程负责同步，如A机器，线程1负责同步数据到B，线程2负责同步数据到C。

tracker_report_thread_entrance 线程负责向tracker上报信息。 在Storage.conf配置文件中，只配置了Tracker的IP地址，并没有配置组内其他的Storage。因此同组的其他Storage必须从Tracker获取。具体过程如下：

storage_sync_thread_entrance 同步线程。每个同步线程负责到一台Storage的同步，以阻塞方式进行。

（1）打开对应Storage的mark文件，如负责到192.168.0.104的同步则打开192.168.0.104_23000.mark文件，从中读取binlog_index、binlog_offset两个字段值，如取到值为：0、100，那么就打开binlog.000文件，seek到100这个位置。

（2）进入一个while循环，尝试着读取一行，若读取不到则睡眠等待。若读取到一行，并且该行的操作方式为源操作，如C、A、D、T（大写的都是），则将该行指定的操作同步给对方（非源操作不需要同步），同步成功后更新binlog_offset标志，该值会定期写入到192.168.0.104_23000.mark文件之中。

假如同步较为缓慢，那么有可能在开始同步一个文件之前，该文件已经被客户端删除，此时同步线程将打印一条日志，然后直接接着处理后面的Binlog。

举个例子：

一个group内有Storage-A、Storage-B、Storage-C三台机器。对于A这台机器来说，B与C机器都会同步Binlog（包括文件）给他，A在接收同步时会记录每台机器同步给他的最后时间（Binlog中的第一个字段timpstamp，这个时间也会更新到storage_stat.dat的last_sync_update）。比如B最后同步给A的Binlog-timestamp为100，C最后同步给A的Binlog-timestamp为200，那么A机器的最后最早被同步时间就为100。也就是取最小值。

这个值的意义在于，判断一个文件是否存在某个Storage上。

比如这里A机器的最后最早被同步时间为100，那么如果一个文件的创建时间为99，就可以肯定这个文件在A上肯定有。

Storage会定期将每台机器同步给他的最后时间告诉给Tracker，Tracker在客户端要下载一个文件时，需要判断一个Storage是否有该文件，只要解析文件的创建时间，然后与该值作比较，若该值大于创建创建时间，说明该Storage存在这个文件，可以从其下载。

Tracker也会定期将该值写入到一个文件之中，Storage_sync_timestamp.dat，内容如下：

每一行记录了对应Storage同步给其他Storage的最后时间。

如第一行含义：0表示自己同步给自己，没有记录；1408524351表示192.168.0.104同步给192.168.0.105的最后最早被同步时间；1408524352 表示192.168.0.104同步给192.168.0.106的最后最早被同步时间。其他行同理。

比如在已有A、B节点上，新增节点storage C。

1. 新节点storage C 启动的时候会创建线程tracker_report_thread_entrance，调用tracker_report_join向tracker 发送命令TRACKER_PROTO_CMD_STORAGE_JOIN（81）报告，自己的group名称，ip,端口，版本号，存储目录数，子目录数，启动时间，老数据是否同步完成，当前连接的tracker信息，当前状态信息（FDFS_STORAGE_STATUS_INIT）等信息。

2. tracker收到TRACKER_PROTO_CMD_STORAGE_JOIN命令后，将上报的信息和已有（tracker数据文件中保存的信息）的信息进行比较，如果有则更新，没有的话，将节点及状态信息写入缓存和数据文件中，并查找同group的其他节点做为同步源，如果有返回给stroage C。

3. 新节点stroage C 收到tracker响应继续流程。发送TRACKER_PROTO_CMD_STORAGE_SYNC_DEST_REQ （87）查询同步目的。

4. tracker收到TRACKER_PROTO_CMD_STORAGE_SYNC_DEST_REQ 请求后， 查找同group的其他节点做为同步目标，及时间戳返回给新storage节点。

5. 新storage节点收到响应后，保存同步源及同步时间戳。继续流程，发送TRACKER_PROTO_CMD_STORAGE_BEAT（83） 给tracker。

6. tracker收到心跳报告后，leader trakcer（非leader不返回数据），把最新的group的 storagelist返回给新的stroaged。

7. stroage C 收到 tracker storage list后，启动2个同步线程，准备将binlog同步到 节点 A和B（此时还不能同步，因为stroage C 还是WAIT_SYNC 状态）。

8. 这时候，其他的已在线的storage 节点 A 、B会发送心跳给tracker ，tracker 把会收到最新的stroagelist，A、B、C返回给Storage A，B 。

9. storage A，B 收到tracker响应后，会发现本地缓存中没有stroage C，会启动binlog同步线程，将数据同步给 stroage C。

10. storage A 、B分别启动storage_sync_thread_entrance 同步线程，先向 tracker 发送TRACKER_PROTO_CMD_STORAGE_SYNC_SRC_REQ（86）命令，请求同步源，tracker会把同步源IP及同步时间戳返回。

11. stroage A 、B节点的同步线程收到TRACKER_PROTO_CMD_STORAGE_SYNC_SRC_REQ 响应后，会检查返回的同步源IP是否和自己本地ip一致，如果一致置need_sync_old=1表示将做为源数据将老的数据，同步给新节点C，如果不一致置need_sync_old=0，则等待节点C状态为Active时，再同步（增量同步）。因为，如果A、 B同时作为同步源，同步数据给C的话，C数据会重复。这里假设节点A，判断tracker返回的是同步源和自己的iP一致，A做为同步源，将数据同步给storage C节点。

12. Storage A同步线程继续同步流程，用同步目的的ip和端口，为文件名，.mark为后缀，如192.168.0.104_23000.mark,将同步信息写入此文件。将Storage C的状态置为FDFS_STORAGE_STATUS_SYNCING 上报给tracker，开始同步。

（1）在同group下，获取最小的一个同步时间点(各个storage在同一时间，同步完成的时间点不一样)。

（2）在最小同步时间点之前的文件，按照用户的规则随意选择一个storage。

（3）在最小同步时间点之后的文件，选择源storage提供给客户端。

4. FastDFS做到高可用是tracker可以做集群，storage一般部署三个及以上。

5. 写的高并发通过增加storage是不能提高并发的，因为storage直接需要推送文件；可以通过增加group、一个storage配置多个硬盘，每个硬盘对应一个store_path两种方式来提高写并发。

6. 读的并发在少写多读的情况下可以通过扩充storage来提高并发，可以通过增加group，一个storage配置多个硬盘，每个硬盘对应一个store_path。

7. 需要小文件存储的原因是小文件数量太多查找麻烦，而且因为inode的存在小文件会降低磁盘的利用率。

8. fastdfs是弱一致性，如果是需要特别安全和特别可靠的就最好不要使用fastdfs。

9. 两个storage直接的备份通过大小写字符来区别源数据和备份数据；如果是大写（比如C）就需要推送到其他storage，如果是小写（比如c）就不需要推送。从而避免备份死循环问题。

10. 已经存在两个storage了，然后加入第三个storage，那么由Tracker决定由谁将数据同步到新的storage中，一般是选择最后最早同步时间戳的storage ，即取最小原则。

11. Tracker选择客户端下载文件的storage的原则是在最小同步时间点之前的文件按照用户的规则随意选择一个，在最小同步时间点之后的文件，选择源storage提高给客户端。