正文
FastDFS数据存储
提示：扫一扫查出行【扫一扫了解最新限行尾号】
复制提示
1. 数据存储
在fdfs传一份文件时，通常会返回下面的一串字符，这包含了该文件在服务器端一些存储信息
M00/00/00/wKg4C1tFmTWAFPKBAADdeFFxlXA240.png
下面解释一下这串东西都是什么：
group1：是storage的组号，一个fastdfs集群可以有多个组，一个组内可以有多个storage节点（备份容灾）
M00：Mxx：xx为十六进制字符，表示存放的基路径（base path）序号。如果存放的base path只有一个，那固定就是M00，这样FastDFS支持多个磁盘（base path），所以要通过Mxx来区分，其中xx为磁盘的序号，基于0。数据就可以根据store_path0=/data/fastdfs/storage # 如果store_path0没有就去找base_path存数据，两个是一样的，所有固定为M00
/00/01/:store_path0=/data/fastdfs/storage配置的目录下的目录，用于存放上传的数据
- store_path0下都是些什么？
所有的文件都在这些目录下的一层目录，存储着上传的所有数据，其中/data/sync目录下存放着fastdfs的binlog日志
- 支持多磁盘
Fastdfs支持多磁盘存储，配置方法如下：
首先修改storage.conf
store_path_count=2
store_path0=磁盘1路径
store_path1=磁盘2路径
然后修改mod_fastdfs.conf（与上边保持一致）
store_path_count=2
store_path0=磁盘1路径
store_path1=磁盘2路径
2. 同步记录2.1 数据同步过程
2.1.1 Storage Server中有两类用于同步的线程：
Storage Server会为文件系统中的每一个Tracker启动一个线程
1）用于与Tracker之间通信。
2）实现心跳反馈机制，默认每30秒发送向Tracker发送一次心跳包，包含同组内其他Storage信息。
3）通过这一线程从Tracker中获取Storage列表信息
Storage会为同组的每一个Storage开启一个线程
1）从Tracer获取到同组内其他Storage Server信息，根据binlog向这些Storage Server同步数据（阻塞方式）。
2）如果组内有三个Storage，那么每个Storage都会启动两个线程用于向其他Storage同步数据。
3）打开/data/sync的mark文件，读取目标Storage_Server_IP.mark文件，获取对应的binlog文件以及同步的offset。
4）在对应的binlog文件中找到offset对应的文件操作，如果这已操作是源操作（CADT），则将操作将数据向外同步。同步完成后更新mark文件的offset值
2.1.2 Storage Server同步相关目录、文件：
当Storaged server启动时会创建一个 base_path/data/sync 同步目录，该目录中的文件都是和同组内的其它 Storaged server之间的同步信息。
mark文件
例如下图是同组内一个新加入storage后产生的mark文件。
说明：
1）这个storage server对新入组的Storage Server发起了数据同步
2）数据同步的动作（增加，删除）依据binlog.000中的记录
3）同步的进度是binlog.000的2204（offset）
4）扫描了38行
5）同步了38行所记录的操作
# 目录下结构
192.168.1.2_33450.mark 192.168.1.3_33450.mark binlog.000 binlog.indexbinlog.index # 记录当前使用的Binlog文件序号，如为10，则表示使用binlog.010
binlog.100 # 真实地Binlog文件
192.168.1.2_33450.mark # 同步状态文件，记录本机到192.168.1.2_33450的同步状态
binlog文件
Binlog文件记录文件上传、删除等更新操作（对文件的操作，而不是文件的内容），是数据同步的依据。
下面看看binlog到底记录些什么？
说明：
其中的每一条记录都是使用空格符分成三个字段： 第一个字段: 表示文件upload时间戳 如：1529376942
第二个字段: 表 示文件执行操作，值为：
C ：表示源创建
c：表示副本
A：表示源追加
a：表示副本追加
D：表示源删除
d：表示副本
T：表示源Truncate
t：表示副本Trunca
其中源表示客户端直接操作的那个Storage即为源，其他的Storage都为副本
第三个字段为存储文件信息描述
当上传一个文件后，binlog文件多了这么一行1531384360 C M00/00/00/wKg4C1tHEiiAWR8JAAAGkHPTQkQ1899.sh，记录了在这个Storage Server上上传了一个文件；文件的存储名为 wKg4C1tHEiiAWR8JAAAGkHPTQkQ1899.sh，C表示源创建，这时这个文件会向同组内的其他Storage Server同步该文件。 delete 亦是如此！
root@ubuntu03:~/fastdfs# fdfs_upload_file /etc/fdfs/client.conf ./stop.sh
group2/M00/00/00/wKg4C1tHEiiAWR8JAAAGkHPTQkQ1899.sh
Storage Server会为文件系统中的每一个Tracker启动一个线程
1）用于与Tracker之间通信。
2）实现心跳反馈机制，默认每30秒发送向Tracker发送一次心跳包，包含同组内其他Storage信息。
3）通过这一线程从Tracker中获取Storage列表信息
Storage会为同组的每一个Storage开启一个线程
1）从Tracer获取到同组内其他Storage Server信息，根据binlog向这些Storage Server同步数据（阻塞方式）。
2）如果组内有三个Storage，那么每个Storage都会启动两个线程用于向其他Storage同步数据。
3）打开/data/sync的mark文件，读取目标Storage_Server_IP.mark文件，获取对应的binlog文件以及同步的offset。
4）在对应的binlog文件中找到offset对应的文件操作，如果这已操作是源操作（CADT），则将操作将数据向外同步。同步完成后更新mark文件的offset值
当Storaged server启动时会创建一个 base_path/data/sync 同步目录，该目录中的文件都是和同组内的其它 Storaged server之间的同步信息。
mark文件
例如下图是同组内一个新加入storage后产生的mark文件。
说明：
1）这个storage server对新入组的Storage Server发起了数据同步
2）数据同步的动作（增加，删除）依据binlog.000中的记录
3）同步的进度是binlog.000的2204（offset）
4）扫描了38行
5）同步了38行所记录的操作
# 目录下结构
192.168.1.2_33450.mark 192.168.1.3_33450.mark binlog.000 binlog.indexbinlog.index # 记录当前使用的Binlog文件序号，如为10，则表示使用binlog.010
binlog.100 # 真实地Binlog文件
192.168.1.2_33450.mark # 同步状态文件，记录本机到192.168.1.2_33450的同步状态
binlog文件
Binlog文件记录文件上传、删除等更新操作（对文件的操作，而不是文件的内容），是数据同步的依据。
下面看看binlog到底记录些什么？
说明：
其中的每一条记录都是使用空格符分成三个字段： 第一个字段: 表示文件upload时间戳 如：1529376942
第二个字段: 表 示文件执行操作，值为：
C ：表示源创建
c：表示副本
A：表示源追加
a：表示副本追加
D：表示源删除
d：表示副本
T：表示源Truncate
t：表示副本Trunca
其中源表示客户端直接操作的那个Storage即为源，其他的Storage都为副本
第三个字段为存储文件信息描述
当上传一个文件后，binlog文件多了这么一行1531384360 C M00/00/00/wKg4C1tHEiiAWR8JAAAGkHPTQkQ1899.sh，记录了在这个Storage Server上上传了一个文件；文件的存储名为 wKg4C1tHEiiAWR8JAAAGkHPTQkQ1899.sh，C表示源创建，这时这个文件会向同组内的其他Storage Server同步该文件。 delete 亦是如此！
root@ubuntu03:~/fastdfs# fdfs_upload_file /etc/fdfs/client.conf ./stop.sh
group2/M00/00/00/wKg4C1tHEiiAWR8JAAAGkHPTQkQ1899.sh
