Fastdfs安装和原理
原链接
http://blog.csdn.net/ForeverSunshine/article/details/51226061
最近因为工作需要,使用了FastDFS,这是一款国产的开源DFS软件,但是这个软件本身不能对重复上传的文件进行去重,需要我们自己去处理,一种可行的方案是,在文件上传之前进行md5校验,把每个文件保存在数据库中,然后进行对比,这个md5值如果在数据库中已经存在的话,就不上传。不过这个效率可能不怎么高。FastDFS作者余庆也开源了一个解决的资源,就是FastDHT了,使用这个也可以做到去重。
关于FastDHT
FastDHT is a high-performance distributed hash system (DHT) which based key value pairs. It can store mass key value pairs such as filename mapping, session data and user related data.
FastDHT implements data replication by it’s binlog file, so it only uses the basic storage function of the Berkeley DB.
从这段话中可以看出,FastDHT是一个高性能的分布式哈希系统,它是基于键值对存储的,而且它需要依赖于Berkeley DB作为数据存储的媒介,同时需要依赖于libfastcommon。
FastDHT集群由一个或者多个组 group组成,同组服务器上存储的数据是相同的,数据同步只在组的服务器之间进行;组内各个服务是对等的,对数据进行存取时,可以根据 key的hash值来决定使用哪台机器。
安装
下载FastDHT,建议在GitHub上下载:https://github.com/happyfish100/fastdht,
libfastcommon下载地址:https://github.com/happyfish100/libfastcommon,
Berkeley DB的下载地址:
http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index.html
下载完毕后,就可以开始安装了。
先安装libfastcommon
将源码解压到/usr/local/src/目录下,
[root@tracker src]# unzip libfastcommon-master.zip
[root@tracker src]# cd libfastcommon-master
[root@tracker libfastcommon-master]# ls
HISTORY INSTALL libfastcommon.spec make.sh README src
[root@tracker libfastcommon-master]# ./make.sh
[root@tracker libfastcommon-master]# ./make.sh install
mkdir -p /usr/lib64
install -m 755 libfastcommon.so /usr/lib64
mkdir -p /usr/include/fastcommon
install -m 644 common_define.h hash.h chain.h logger.h base64.h shared_func.h pthread_func.h ini_file_reader.h _os_bits.h sockopt.h sched_thread.h http_func.h md5.h local_ip_func.h avl_tree.h ioevent.h ioevent_loop.h fast_task_queue.h fast_timer.h process_ctrl.h fast_mblock.h connection_pool.h /usr/include/fastcommon
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
安装Berkeley DB
其实libfastcommon在安装FastDFS的时候就会安装了,接下来安装db。这里我下载的是db-6.1.19版本。
①将db-6.1.19源码拷贝到 /usr/local/src下
②进入db-6.1.19uild_unix,
③执行../dist/configure --prefix=/usr/local/db-6.1.19
④make
⑤make install
安装完db,会在/usr/local目录下生成db-6.1.19/
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
安装FastDHT
①将fastdht-master源码解压到 /usr/local/src下,编译之前需要先修改make.sh文件。
在CFLAGS=’-Wall -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -I/usr/local/db-6.1.19/include/ -L/usr/local/db-6.1.19/lib/’
这行里面加上斜体字部分。
②然后,进入/usr/local/src/fastdht-master源码目录下,执行./make.mk
然后执行./make.sh install。
③最后会在/usr/local/bin生成安装后的文件,在/etc/fdht下生成文件
root@jz-server:/usr/local/bin# cd /etc/fdht/
root@jz-server:/etc/fdht# ll
total 24
drwxr-xr-x 2 root root 4096 Apr 22 12:45 ./
drwxr-xr-x 102 root root 4096 Apr 22 12:45 ../
-rwxr-xr-x 1 root root 910 Apr 22 12:45 fdht_client.conf*
-rwxr-xr-x 1 root root 5374 Apr 22 12:45 fdhtd.conf*
-rwxr-xr-x 1 root root 76 Apr 22 12:45 fdht_servers.conf*
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
配置FastDHT
配置fdht_client.conf文件
base_path=/data/fastdht
keep_alive=1
#include /etc/fdhtd/fdht_servers.conf
- 1
- 2
- 3
- 1
- 2
- 3
配置fdht_servers.conf文件
vim /etc/fdhtd/fdht_servers.conf
group_count = 1
group0 = 10.10.10.81:11411
group0 = 10.10.10.82:11411
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
配置fdhtd.conf文件
vim /etc/fdht/fdhtd.conf/
port=11411
bash_path=/data/fastdht (该目录必须是已经存在的)
cache_size = 32MB
#include /etc/fdhtd/fdht_servers.conf -> (本行前有#表示打开,如果想关闭此选项,则应该为##开头)
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
配置storaged.conf文件
vim /etc/fdfs/storaged.conf
#是否检测上传文件已经存在。如果已经存在,则建立一个索引链接以节省磁盘空间
check_file_duplicate=1
#当上个参数设定为1时 , 在FastDHT中的命名空间
key_namespace=FastDFS
#长连接配置选项,如果为0则为短连接 1为长连接
keep_alive=1
#此处特别需要注意配置
#include /etc/fdht/fdht_servers.conf
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
启动
或fdhtd /etc/fdht/fdhtd.conf
fdhtd /etc/fdht/fdhtd.conf restart
可能遇到问题:
fdhtd /etc/fdht/fdhtd.conf
error while loading shared libraries: libdb-6.1.so: cannot open shared object file: No such file or directory
解决办法:
# cp /usr/local/db-6.1.19/lib/libdb-6.1.so /usr/lib/
- 1
- 1
然后再重新启动就可以了。
测试一下:
可以看到,第一次上传的文件为:
-rw-r--r-- 1 root root 3706 Apr 22 15:24 CgoKUlcZ0cWAUpQ4AAAOepbSnR0875.png
- 1
- 1
第一次上传返回的结果为一个软链接:CgoKUlcZ0cWAYmiNAAAOejexS3k075.png,之后每次重复上传的话都是返回一个指向第一次上传的文件的软链接。也就保证了文件只保存了一份。需要说明的是,FastDFS不会返回原始文件的索引,比如这里的CgoKUlcZ0cWAUpQ4AAAOepbSnR0875.png,即返回的全部是软链接,当所有的软链接都被删除的时候,原始文件也会从FastDFS中被删除。
整个过程就是这样了,就写这么多吧。。。
原理如下链接:
http://blog.csdn.net/pzw_0612/article/details/52672778?locationNum=7&fps=1
在前面几篇文章中我们对fastdfs系统的概述、tracker server、storage server以及文件的上传、下载、删除等功能的介绍,
本文将对同一组的不同storage server之间的同步以及新增storage server的同步进行介绍。
fastdfs文件系统结构
fastdfs文件系统原理
从fastdfs文件系统结构中我们可以看出不管是上传文件、删除文件、修改文件及新增storager server,文件的同步都是同组
内多台storager server之间进行的。下面我们看fastdfs文件系统开发者是怎么描述同步机制的(来源于chinaunix):
tracker server的配置文件中没有出现storage server,而storage server的配置文件中会列举出所有的tracker server。
这就决定了storage server和tracker server之间的连接由storage server主动发起,storage server为每个tracker server启动一个线程
进行连接和通讯。
tracker server会在内存中保存storage分组及各个组下的storage server,并将连接过自己的storage server及其分组
保存到文件中,以便下次重启服务时能直接从本地磁盘中获得storage相关信息。storage server会在内存中记录本组的所有服务器,
并将服务器信息记录到文件中。tracker server和storage server之间相互同步storage server列表:
1. 如果一个组内增加了新的storage server或者storage server的状态发生了改变,tracker server都会将storage server列
表同步给该组内的所有storage server。以新增storage server为例,因为新加入的storage server主动连接tracker server,tracker
server发现有新的storage server加入,就会将该组内所有的storage server返回给新加入的storage server,并重新将该组的storage
server列表返回给该组内的其他storage server;
2. 如果新增加一台tracker server,storage server连接该tracker server,发现该tracker server返回的本组storage server
列表比本机记录的要少,就会将该tracker server上没有的storage server同步给该tracker server。
同一组内的storage server之间是对等的,文件上传、删除等操作可以在任意一台storage server上进行。文件同步
只在同组内的storage server之间进行,采用push方式,即源服务器同步给目标服务器。以文件上传为例,假设一个组内有3台storage
server A、B和C,文件F上传到服务器B,由B将文件F同步到其余的两台服务器A和C。我们不妨把文件F上传到服务器B的操作为源头操
作,在服务器B上的F文件为源头数据;文件F被同步到服务器A和C的操作为备份操作,在A和C上的F文件为备份数据。同步规则总结如下:
1. 只在本组内的storage server之间进行同步;
2. 源头数据才需要同步,备份数据不需要再次同步,否则就构成环路了;
3. 上述第二条规则有个例外,就是新增加一台storage server时,由已有的一台storage server将已有的所有数据(包括源头数据和
备份数据)同步给该新增服务器;
storage server有7个状态,如下:
# FDFS_STORAGE_STATUS_INIT :初始化,尚未得到同步已有数据的源服务器
# FDFS_STORAGE_STATUS_WAIT_SYNC :等待同步,已得到同步已有数据的源服务器
# FDFS_STORAGE_STATUS_SYNCING :同步中
# FDFS_STORAGE_STATUS_DELETED :已删除,该服务器从本组中摘除(注:本状态的功能尚未实现)
# FDFS_STORAGE_STATUS_OFFLINE :离线
# FDFS_STORAGE_STATUS_ONLINE :在线,尚不能提供服务
# FDFS_STORAGE_STATUS_ACTIVE :在线,可以提供服务
当storage server的状态为FDFS_STORAGE_STATUS_ONLINE时,当该storage server向tracker server发起一次heart beat时,
tracker server将其状态更改为FDFS_STORAGE_STATUS_ACTIVE。
组内新增加一台storage server A时,由系统自动完成已有数据同步,处理逻辑如下:
1. storage server A连接tracker server,tracker server将storage server A的状态设置为FDFS_STORAGE_STATUS_INIT。
storage server A询问追加同步的源服务器和追加同步截至时间点,如果该组内只有storage server A或该组内已成功上传的文件数为0,
则没有数据需要同步,storage server A就可以提供在线服务,此时tracker将其状态设置为FDFS_STORAGE_STATUS_ONLINE,否则
tracker server将其状态设置为FDFS_STORAGE_STATUS_WAIT_SYNC,进入第二步的处理;
2. 假设tracker server分配向storage server A同步已有数据的源storage server为B。同组的storage server和tracker server
通讯得知新增了storage server A,将启动同步线程,并向tracker server询问向storage server A追加同步的源服务器和截至时间点。
storage server B将把截至时间点之前的所有数据同步给storage server A;而其余的storage server从截至时间点之后进行正常同步,只
把源头数据同步给storage server A。到了截至时间点之后,storage server B对storage server A的同步将由追加同步切换为正常同步,
只同步源头数据;
3. storage server B向storage server A同步完所有数据,暂时没有数据要同步时,storage server B请求tracker server将
storage server A的状态设置为FDFS_STORAGE_STATUS_ONLINE;
4 当storage server A向tracker server发起heart beat时,tracker server将其状态更改为FDFS_STORAGE_STATUS_ACTIVE。
从上面的描述,我觉得作者描述的非常的清楚,让我们这些使用者能够非常容易理解。
同步时间管理
刚刚我们从上面了解了fastdfs文件系统中组内的多个storage server之间同步的机制,那文件同步是什么时候进行呢?是文件上传成功后,
其它的storage server才开始同步,其它的storage server怎么去感知,tracker server是怎么通知storage server呢?
管理同步时间
当一个文件上传成功后,客户端马上发起对该文件下载请求(或删除请求)时,tracker是如何选定一个适用的存储服务器呢?
其实每个存储服务器都需要定时将自身的信息上报给tracker,这些信息就包括了本地同步时间(即,同步到的最新文件的时间戳)。
而tracker根据各个存储服务器的上报情况,就能够知道刚刚上传的文件,在该存储组中是否已完成了同步。在storage server中这些信息是
以Binlog文件的形式存在的。
Binlog文件
当Storaged server启动时会创建一个 base_path/data/sync 同步目录,该目录中的文件都是和同组内的其它 Storaged server之间的
同步状态文件,如192.168.1.2_33450.mark 192.168.1.3_33450.mark binlog.100(binlog.index);
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的同步状态
在Mark文件中内容:由binlog_index和binlog_offset两项组成,以192.168.1.2_33450.mark为例其中binlog_index表示上次同步192.168.
1.2机器的最后一条
binlog文件索引,binlog_offset表示上次同步192.168.1.2机器的最后一条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
第二个字段 表示文件执行操作,值为下面几种
C表示源创建、c表示副本创建
A表示源追加、a表示副本追加
D表示源删除、d表示副本删除
T表示源Truncate、t表示副本Truncate
其中源表示客户端直接操作的那个Storage即为源,其他的Storage都为副本
第三个字段 表示文件 如M00/03/61/QkIPAFdQCL-AQb_4AAIAi4iqLzk223.jpg
Storage server具体同步过程
从fastdfs文件同步原理中我们知道Storaged server之间的同步都是由一个独立线程负责的,这个线程中的所有操作都是以同步方式
执行的。比如一组服务器有A、B、C三台机器,那么在每台机器上都有两个线程负责同步,如A机器,线程1负责同步数据到B,线程2负责同
步数据到C。每个同步线程负责到一台Storage的同步,以阻塞方式进行。
以IP为192.168.1.1的Storaged severe的服务器为例,它的同步目录下有192.168.1.2_33450.mark 192.168.1.3_33450.mark binlog.100
等文件现在Storaged severe将会从ip为192.168.1.2的Storaged severe的存储里面同步数据。
1)打开对应Storage server的mark文件,如负责到192.168.1.1的同步则打开192.168.1.2_33450.mark 文件,从中读取binlog_index、
binlog_offset两个字段值,如取到值为:100、1000,那么就打开binlog.100文件,seek到1000这个位置。
2)进入一个while循环,尝试着读取一行,若读取不到则睡眠等待。若读取到一行,并且该行的操作方式为源操作,如C、A、D、T
(大写的都是),则将该行指定的操作同步给对方(非源操作不需要同步),同步成功后更新binlog_offset标志,该值会定期写入到192.168.1
.2_33450.mark文件之中。
同步过程中可能因为同步较为缓慢,导致可能在同步一个文件之前,文件已经被客户端删除,此时同步线程将打印一条日志,然后直接处理后
面的Binlog。
- 上一篇:没有了
- 下一篇:没有了