目录
[1 ：获取组内的其他Storage信息 tracker_report_thread_entrance ，并启动同步线程](#1 ：获取组内的其他Storage信息 tracker_report_thread_entrance ，并启动同步线程)
[2 ：同步线程执行过程storage_sync_thread_entrance](#2 ：同步线程执行过程storage_sync_thread_entrance)
[3 ：同步前删除](#3 ：同步前删除)
[5：Storage的 最后 最早 被同步时间](#5：Storage的 最后 最早 被同步时间)
一：FatsDFS的结构图
我们知道FatsDFS是一个分布式存储，我们可以配置多个storage，那这几个storage是怎么进行同步的呢？在下面这张图中，我们可以看到有Tracker和Storage集群，我们配置的多个storage就是在集群中。其中一个Group中含有多个storage，他们互为备份，互相同步。
二：FatsDFS文件同步
前言：
文件上传成功后，其它的storage server才开始同步，其它的storage server怎么去感知，tracker server是怎么通知storage server？
storage定时发送心跳包到tracker，并附带同步的时间节点 --- tracker 返回我们其他storage的状态。
正常文件上传完成后，就记录到binlog缓存中，系统定时刷入binlog文件。
系统有线程定时读取binlog文件，当有新增行时，判断该记录是源文件记录还是副本文件记录。
系统只主动发送源文件，副本文件不做处理(非启动时流程)。
疑问？
两个storage如何相互备份，会不会出现备份死循环的问题？
已经存在两个storage了，然后加入第三个storage，那谁同步给第三个storage？
binlog的格式是怎么设计的，如果binlog文件太大该怎么处理？
已有A、B、C三个storage，我现在上传一个文件到A，然后发起请求下载，会不会出现从B请求下载，但此时B没有同步文件，导致下载失败？
线程：
tracker_report_thread_entrance ，连接tracker有独立的线程，连接n个tracker就有n个线程
storage_sync_thread_entrance ，给同group的storage做同步，同组有n个storage，就有n-1个线程
有A、B、C三个storage，那我们在A的机器中看到的线程是：A->B,A->C。那在B中看到的是B->A,B->C。
1：同步日志所在目录
比如在192.168.1.18服务器目录中看到的sync log：
bash
root@xx:/home/fastdfs/storage_group1_23000/data/sync#192.168.1.19_23000.mark：同步状态文件。是记录从本机18到19（另一台服务器的地址）的同步状态。文件名由同步源IP_端口组成。
binlog.000：binlog文件，文件大小最大1G，超过1G，会重新写下个文件，同时更新binlog.index
binlog_index.dat：记录了当前写binlog的索引id。
如果有不只2个storage的时候，比如还有192.168.1.20，则该目录还存在192.168.1.20_23000.mark
2：binlog格式
FastDFS文件同步采用binlog异步复制方式。storage server使用binlog文件记录文件上传、删除等操作，根据binlog进行文件同步。binlog中只记录文件ID和操作，不记录文件内容。下面给出几行binlog文件内容示例：
bash
1646123002 C M00/00/00/oYYBAF285cOIHiVCAACI-7zX1qUAAAAVgAACC8AAIkT490.txt
1646123047 c M00/00/00/oYYBAF285luIK8jCAAAJeheau6AAAAAVgABI-cAAAmS021.xml
1646123193 A M00/00/00/rBMYd2IaLXqASSVXAAAHuj79dAY65.txt 6 6
1646123561 d M00/00/00/oYYBAF285luIK8jCAAAJeheau6AAAAAVgABI-cAAAmS021.xml从上面可以看到，binlog文件有三列，依次为：
时间戳
操作类型
文件ID（不带group名称）：Storage_id（ip的数值型），timestamp（创建时间），file_size（若原始值为32位则前面加入一个随机值填充，最终为64位），crc32（文件内容的检验码）
文件操作类型采用单个字母编码，其中源头操作用大写字母表示，被同步的操作为对应的小写字母。文件操作字母含义如下：
同组内的storage server之间是对等的，文件上传、删除等操作可以在任意一台storage server上进行。文件同步只在同组内的storage server之间进行，采用push方式，即源头服务器主动同步给本组的其他存储服务器。对于同组的其他storage server，一台storage server分别启动一个线程进行文件同步。
注：源表示客户端直接操作的那个Storage即为源，，其他的Storage都为副本。
文件同步采用增量方式，记录已同步的位置到mark文件中。mark文件存放路径为：
bash
$base_path/data/sync/
bash
192.168.1.22_23000.mark
binlog_index=0 //binlog索引id 表示上次同步给192.168.1.22机器的最后一条binlog文件索引
binlog_offset=3944 //当前binlog 大小 (单位是字节)表示上次同步给192.168.1.22机器的最后一条binlog偏移量，若程序重启了，也只要从这个位置开始向后同步即可。
need_sync_old=1 //是否需要同步老数据
sync_old_done=1 //是否同步完成
until_timestamp=1621667115 //同步已有数据文件的截至时间
scan_row_count=68 //扫描记录数
sync_row_count=53 //同步记录数
192.168.1.18_23000.mark
binlog_index=0
binlog_offset=4350
need_sync_old=0
sync_old_done=0
until_timestamp=0
scan_row_count=75
sync_row_count=153：同步规则
只在本组（group）内的storage server之间进行同步；
源头数据才需要同步，备份数据不需要再次同步，否则就构成环路了，源数据和备份数据区分是用binlog的操作类型来区分，操作类型是大写字母，表示源数据，小写字母表示备份数据；
当先新增加一台storage server时，由已有的一台storage server将已有的所有数据（包括源头数据和备份数据）同步给该新增服务器。
4：binlog同步过程
在FastDFS之中，每个Storaged之间的同步都是由一个独立线程负责的，该线程中的所有操作都是以同步方式执行的。比如一组服务器有A、B、C三台机器，那么在每台机器上都有两个线程负责同步，如A机器，线程1负责同步数据到B，线程2负责同步数据到C。
1 ：获取组内的其他Storage信息 tracker_report_thread_entrance ，并启动同步线程
tracker_report_thread_entrance 线程负责向tracker上报信息。在Storage.conf配置文件中，只配置了Tracker的IP地址，并没有配置组内其他的Storage。因此同组的其他Storage必须从Tracker获取。具体过程如下：
1）Storage启动时为每一个配置的Tracker启动一个线程负责与该Tracker的通讯。
2）默认每间隔30秒，与Tracker发送一次心跳包，在心跳包的回复中，将会有该组内的其他Storage信息。
3）Storage获取到同组的其他Storage信息之后，为组内的每个其他Storage开启一个线程负责同步。
2 ：同步线程执行过程storage_sync_thread_entrance
每个同步线程负责到一台Storage的同步，以阻塞方式进行。
1）打开对应Storage的mark文件，如负责到192.168.1.22的同步则打开192.168.1.22_23000.mark文件，从中读取binlog_index、binlog_offset两个字段值，如取到值为：0、100，那么就打开binlog.000文件，seek到100这个位置。
2）进入一个while循环，尝试着读取一行，若读取不到则睡眠等待。若读取到一行，并且该行的操作方式为源操作，如C、A、D、T（大写的都是），则将该行指定的操作同步给对方（非源操作不需要同步），同步成功后更新binlog_offset标志，该值会定期写入到192.168.1.22_23000.mark文件之中。
3 ：同步前删除
假如同步较为缓慢，那么有可能在开始同步一个文件之前，该文件已经被客户端删除，此时同步线程将打印一条日志，然后直接接着处理后面的Binlog。
5：Storage的 最后 最早 被同步时间
这个标题有点拗口，先举个例子：一组内有Storage-A、Storage-B、Storage-C三台机器。对于A这台机器来说，B与C机器都会同步Binlog（包括文件）给他，A在接收同步时会记录每台机器同步给他的最后时间（Binlog中的第一个字段timpstamp，这个时间也会更新到storage_stat.datlast_sync_update）。
比如B最后同步给A的Binlog-timestamp为100，C最后同步给A的Binlog-timestamp为200，那么A机器的最后最早被同步时间就为100.这个值的意义在于，判断一个文件是否存在某个Storage上。比如这里A机器的最后最早被同步时间为100，那么如果一个文件的创建时间为99，就可以肯定这个文件在A上肯定有。
为什呢？一个文件会Upload到组内三台机器的任何一台上：
1）若这个文件是直接Upload到A上，那么A肯定有。
2）若这个文件是Upload到B上，由于B同步给A的最后时间为100，也就是说在100之前的文件都已经同步A了，那么A肯定有。
3）同理C也一样。
Storage会定期将每台机器同步给他的最后时间告诉给Tracker，Tracker在客户端要下载一个文件时，需要判断一个Storage是否有该文件，只要解析文件的创建时间，然后与该值作比较，若该值大于创建创建时间，说明该Storage存在这个文件，可以从其下载。Tracker也会定期将该值写入到一个文件之中，Storage_sync_timestamp.dat，内容如下：
bash
group1,10.0.0.1, 0, 1408524351, 1408524352
group1,10.0.0.2, 1408524353, 0, 1408524354
group1,10.0.0.3, 1408524355, 1408524356, 0 每一行记录了，对应Storage同步给其他Storage的最后时间，如第一行表示10.0.0.1同步给10.0.0.2的最后时间为1408524351，同步给10.0.0.3的最后时间为1408524352；同理可以知道后面两行的含义了。每行中间都有一个0，这个零表示自己同步给自己，没有记录。按照纵列看，取非零最小值就是最后最早同步时间了，如第三纵列为10.0.0.1被同步的时间，其中1408524353就是其最后最早被同步时间。
6：Tracker选择客户端下载文件的storage的原则
-
在同group下，获取最小的一个同步时间点(各个storage在同一时间，同步完成的时间点不一样)
-
在最小同步时间点之前的文件，按照用户的规则随意选择一个storage。
-
在最小同步时间点之后的文件，选择源storage提供给客户端。
三：同步结构图，一目了然
下面是同步的具体过程，以及拿取文件的过程
