FastDFS文件同步原理

目录

文件同步

何时开启同步线程

同步规则

同步流程

Binlog 目录结构

 Mark 文件

Binlog 文件

同步过程

文件同步时间戳

问题

---

1. 文件同步

   1. 何时开启同步线程

从Tracker Server获取到同组storage server集合后，就会为除了自己之外的其他同组storage server分别开启同步线程。

如果组内有三个Storage Server，那么每台Storage Server都应该开启两个独立同步线程

同步规则

1. 只在本组内的storage server之间进行同步；

2. 源头数据才需要同步，备份数据不需要再次同步，否则就构成环路了；

3. 同步采取push方式，即源服务器同步给同组其他服务器；

4. 上述第二条规则有个例外，就是新增加一台storage server时，由已有的一台storage server将已有的所有数据（包括源头数据和备份数据）同步给该新增服务器

1. 同步流程

   1. Binlog 目录结构

当Storaged server启动时会创建一个 base_path/data/sync 同步目录，该目录中的文件都是和同组内的其它 Storaged server之间的同步状态文件，如：

 192.168.1.2_33450.mark 

 192.168.1.3_33450.mark 

 binlog.000 

 binlog.index

文件说明：

binlog.index           记录当前使用的binlog文件序号，如为10，则表示使用binlog.010

binlog.100         真实地binlog文件

192.168.1.2_33450.mark   同步状态文件，记录本机到192.168.1.2_33450的同步状态

1. 1. 1.  Mark 文件

在Mark文件中内容：

 binlog_index=0

 binlog_offset=1334

 need_sync_old=1

 sync_old_done=1

 until_timestamp=1457542256

 scan_row_count=23

 sync_row_count=11

文件说明：

binlog_index：对应于哪个binlog

binlog_offset：binlog.xxx的偏移量，可以直接这个偏移量获取下一行记录

need_sync_old：本storage是否是对侧storage(10.100.66.82)的源结点，同时是否需要从起点同步所有的记录

sync_old_done：是否同步完成过

until_timestamp：上次同步时间结点

scan_row_count：总记录数

sync_row_count：已同步记录数

1. 1. 1. Binlog 文件

Binlog文件内容：在该文件中是以binlog日志组成，比如：

 1470292943 c M00/03/61/QkIPAFdQCL-AQb_4AAIAi4iqLzk223.jpg

 1470292948 C M00/03/63/QkIPAFdWPUCAfiraAAG93gO_2Ew311.png

 1470292954 d M00/03/62/QkIPAFdWOyeAO3eUAABvALuMG64183.jpg

 1470292959 C M00/01/23/QUIPAFdVQZ2AL_o-AAAMRBAMk3s679.jpg

 1470292964 c M00/03/62/QkIPAFdVOsCAcxeQAAGTdbQsdVs062.jpg

 1470292969 c M00/03/62/QkIPAFdVOnKAXu1NAABq9pkfsms63.jpeg

 1470293326 D M00/03/62/QkIPAFdVMnGAZYSZAABq9pkfsms33.jpeg

文件说明：

其中的每一条记录都是使用[空格符]分成三个字段，分别为：

• 第一个字段 表示文件 upload 时间戳 如：1470292943
• 第二个字段 表示文件执行操作，值为下面几种（其中源表示客户端直接操作的那个 Storage 即为源，其他的 Storage 都为副本）

  C 表示源创建、c 表示副本创建
  A 表示源追加、a 表示副本追加
  D 表示源删除、d 表示副本删除
  T 表示源 Truncate、t 表示副本 Truncate

• 第三个字段 表示文件，如 M00/03/61/QkIPAFdQCL-AQb_4AAIAi4iqLzk223.jpg

1. 1. 同步过程

从fastdfs文件同步原理中我们知道Storaged server之间的同步都是由一个独立线程负责的，这个线程中的所有操作都是以同步方式执行的。比如一组服务器有A、B、C三台机器，那么在每台机器上都有两个线程负责同步，如A机器，线程1负责同步数据到B，线程2负责同步数据到C。每个同步线程负责到一台Storage的同步，以阻塞方式进行。

1）获取组内的其他 Storage 信息，并启动同步线程

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

 1）Storage启动时为每一个配置的Tracker启动一个线程负责与该Tracker的通讯。

 2）默认每间隔30秒，与Tracker发送一次心跳包，在心跳包的回复中，将会有该组内的其他Storage信息。

 3）Storage获取到同组的其他Storage信息之后，为组内的每个其他Storage开启一个线程负责同步。

2）同步线程执行过程

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

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

 ​

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

1. 1. 文件同步时间戳

举个例子：一组内有Storage-A、Storage-B、Storage-C三台机器。对于A这台机器来说，B与C机器都会同步Binlog（包括文件）给他，A在接受同步时会记录每台机器同步给他的最后时间（也就是Binlog中的第一个字段timpstamp）。比如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，内容如下：

 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就是其最后最早被同步时间

1. 1. 问题

问题一：同步到中途，把源文件删除，备份服务器怎么办？

源文件删除，同步就读取不到数据，把中断写入日志，直接同步下一条数据。

问题二：同步到中途，服务器宕机，如何解决？

 Make,binlog 同步文件，记录同步偏移量，时间戳。 服务器宕机，下次重新启动，重新加载同步文件，发现没有同步完成。

问题三：此时需要下载文件，如何确定从那台storage服务器下载文件呢？ 此时服务器同步未完成？

访问不到文件，如何解决？

所有文章都是以专栏系列编写，建议系统性学习，更容易成为架构师！

博主每天早晚坚持写博客给与读者价值提升，为了让更多人受益，请多多关照，如果觉得文章质量有帮助到你，请关注我的博客，收藏此文，持续提升，奥利给！

另外我不打算靠运营方式拿到博客专家的认证，纯纯的科技与狠活来征服读者，就看读者的感恩之心了，祝你好运连连。