FastDFS 同步文件及目录结构

FastDFS同步相关文件：

192.168.0.2_23000.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(192.168.0.2)的源结点，同时是否需要从起点同步所有的记录
sync_old_done：是否同步完成过
until_timestamp：上次同步时间结点
scan_row_count：总记录数
sync_row_count：已同步记录数
b)binlog.000

内容如下
1457547668 C M00/00/00/CmRCUVbgaZSAGzKjAACkimfedYQ366.jpg

解释：
1457547668：同步时间戳
C：标记文件类型：C 源创建；A 源追加； D 源删除； T 源Truncate。
对应的小写字母则为副本，如c 副本创建。
M00/00/00/CmRCUVbgaZSAGzKjAACkimfedYQ366.jpg：文件名
c)binlog.index

内容如下
0
解释：现有binlog数。

新增结点同步流程图

注意事项： 对于非源storage，只上传指定时间结点后的源文件给新增结点，副本文件不处理。 对于源结点，需要把时间结点前所有文件(源和副)传给新结点。 同步完成后，B主动发消息给tracker，修改tracker中A的状态记录。 A心跳获取到tracker发过来的消息，修改自身状态。 Storage的状态的主要意义，给tracker用来判定哪些active的结点可以服务。 启动同步过程中，源结点状态不改变，可以正常存储文件。

正常文件同步流程图

注意事项： 正常文件上传完成后，就记录近binlog缓存中，系统定时刷入binlog文件。 系统有线程定时读取binlog文件，当有新增行时，判断该记录是源文件记录还是副本文件记录。 系统只主动发送源文件，副本文件不做处理(非启动时流程)。 图中A的binlog中记录的是源创建(C)，B中记录的是副本创建(c)。

FastDFS服务器端运行时目录结构如下：

${base_path} |__data：存放数据文件 |__logs：存放日志文件

其中，${base_path}由配置文件中的参数“base_path”设定。 一、tracker server tracker server目录及文件结构： ${base_path} |__data | |__storage_groups.dat：存储分组信息 | |__storage_servers.dat：存储服务器列表 |__logs |__trackerd.log：tracker server日志文件 数据文件storage_groups.dat和storage_servers.dat中的记录之间以换行符（/n）分隔，字段之间以西文逗号（,）分隔。 storage_groups.dat中的字段依次为： 1. group_name：组名 2. storage_port：storage server端口号 storage_servers.dat中记录storage server相关信息，字段依次为： 1. group_name：所属组名 2. ip_addr：ip地址 3. status：状态 4. sync_src_ip_addr：向该storage server同步已有数据文件的源服务器 5. sync_until_timestamp：同步已有数据文件的截至时间（UNIX时间戳） 6. stat.total_upload_count：上传文件次数 7. stat.success_upload_count：成功上传文件次数 8. stat.total_set_meta_count：更改meta data次数 9. stat.success_set_meta_count：成功更改meta data次数 10. stat.total_delete_count：删除文件次数 11. stat.success_delete_count：成功删除文件次数 12. stat.total_download_count：下载文件次数 13. stat.success_download_count：成功下载文件次数 14. stat.total_get_meta_count：获取meta data次数 15. stat.success_get_meta_count：成功获取meta data次数 16. stat.last_source_update：最近一次源头更新时间（更新操作来自客户端） 17. stat.last_sync_update：最近一次同步更新时间（更新操作来自其他storage server的同步） 二、storage server storage server目录及文件结构： ${base_path} |__data | |__.data_init_flag：当前storage server初始化信息 | |__storage_stat.dat：当前storage server统计信息 | |__sync：存放数据同步相关文件 | | |__binlog.index：当前的binlog（更新操作日志）文件索引号 | | |__binlog.###：存放更新操作记录（日志） | | |__${ip_addr}_${port}.mark：存放向目标服务器同步的完成情况 | | | |__一级目录：256个存放数据文件的目录，目录名为十六进制字符，如：00, 1F | |__二级目录：256个存放数据文件的目录，目录名为十六进制字符，如：0A, CF |__logs |__storaged.log：storage server日志文件 .data_init_flag文件格式为ini配置文件方式，各个参数如下： # storage_join_time：本storage server创建时间 # sync_old_done：本storage server是否已完成同步的标志（源服务器向本服务器同步已有数据） # sync_src_server：向本服务器同步已有数据的源服务器IP地址，没有则为空 # sync_until_timestamp：同步已有数据文件截至时间（UNIX时间戳） storage_stat.dat文件格式为ini配置文件方式，各个参数如下： # total_upload_count：上传文件次数 # success_upload_count：成功上传文件次数 # total_set_meta_count：更改meta data次数 # success_set_meta_count：成功更改meta data次数 # total_delete_count：删除文件次数 # success_delete_count：成功删除文件次数 # total_download_count：下载文件次数 # success_download_count：成功下载文件次数 # total_get_meta_count：获取meta data次数 # success_get_meta_count：成功获取meta data次数 # last_source_update：最近一次源头更新时间（更新操作来自客户端） # last_sync_update：最近一次同步更新时间（更新操作来自其他storage server） binlog.index中只有一个数据项：当前binlog的文件索引号 binlog.###，###为索引号对应的3位十进制字符，不足三位，前面补0。索引号基于0，最大为999。一个binlog文件最大为1GB。记录之间以换行符（/n）分隔，字段之间以西文空格分隔。字段依次为： 1. timestamp：更新发生时间（Unix时间戳） 2. op_type：操作类型，一个字符 3. filename：操作（更新）的文件名，包括相对路径，如：5A/3D/FE_93_SJZ7pAAAO_BXYD.S ${ip_addr}_${port}.mark：ip_addr为同步的目标服务器IP地址，port为本组storage server端口。例如：10.0.0.1_23000.mark。文件格式为ini配置文件方式，各个参数如下： # binlog_index：已处理（同步）到的binlog索引号 # binlog_offset：已处理（同步）到的binlog文件偏移量（字节数） # need_sync_old：同步已有数据文件标记，0表示没有数据文件需要同步 # sync_old_done：同步已有数据文件是否完成标记，0表示未完成，1表示已完成 # until_timestamp：同步已有数据截至时间点（UNIX时间戳） # scan_row_count：已扫描的binlog记录数 # sync_row_count：已同步的binlog记录数 数据文件名由系统自动生成，包括三部分：当前时间（Unix时间戳）、文件大小（字节数）和随机数。文件名长度为16字节。文件按照PJW Hash算法hash到65536（256*256）个目录中分散存储