分佈式文件系統FastDFS

時間 2019-11-11

原文原文鏈接

分佈式文件系統FastDFS架構剖析javascript

第一部分概念和原理php

什麼是FastDFS？css

FastDFS是一個開源的輕量級分佈式文件系統。它解決了大數據量存儲和負載均衡等問題。特別適合以中小文件（建議範圍：4KB < file_size <500MB）爲載體的在線服務，如相冊網站、視頻網站等等。在UC基於FastDFS開發向用戶提供了：網盤，社區，廣告和應用下載等業務的存儲服務。html

FastDFS架構：java

FastDFS服務端有三個角色：跟蹤服務器（tracker server）、存儲服務器（storage server）和客戶端（client）。nginx

tracker server：跟蹤服務器，主要作調度工做，起負載均衡的做用。在內存中記錄集羣中全部存儲組和存儲服務器的狀態信息，是客戶端和數據服務器交互的樞紐。相比GFS中的master更爲精簡，不記錄文件索引信息，佔用的內存量不多。git

storage server：存儲服務器（又稱：存儲節點或數據服務器），文件和文件屬性（meta data）都保存到存儲服務器上。Storage server直接利用OS的文件系統調用管理文件。github

client：客戶端，做爲業務請求的發起方，經過專有接口，使用TCP/IP協議與跟蹤器服務器或存儲節點進行數據交互。web

Tracker Server：跟蹤服務器，主要作調度工做，在訪問上起負載均衡的做用。數據庫

Storage Server：存儲服務器（又稱數據服務器）

FastDFS是一個應用級分佈式文件存儲服務，其採用中心型結構（相似GFS、HDFS、TFS等），主要用於大中型網站存儲資源文件。FastDFS具備輕量級，支持高併發放訪問，負載均衡，可擴展等優勢。而FastDFS最大的亮點就是對小文件的存儲性能較好，這主要來自於其文件名策略。

1.小文件存儲性能優化

小文件的性能瓶頸主要來自於對元數據服務器（如FastDFS中的TrackerServer或TFS中的NameServer）的訪問，由於當文件自己大小很小時，元數據存儲所佔空間與文件內容存儲所佔空間的比例就變得較大，訪問元數據所消耗資源與訪問文件內容所消耗資源的比例也變得較大。所以，一般對小文件存儲的優化方法主要有兩大類思路：一是減小訪問元數據的次數，好比Cache預取；二是減小元數據所佔的存儲空間，好比FastDFS使用的文件名策略。

2. FastDFS文件名策略

FastDFS中的文件名是在向StorageServer存儲文件時由系統指定的，文件名中包含了VolumeID和FileID。也就是說，當客戶要讀取某個文件時，經過在客戶端對文件名進行解析，就能夠知道該文件存儲在哪一個Volume上和它在StorageServer中的FileID。可是此時用戶還不能讀取文件，由於他不知道Volume內各個StorageServer的ip地址，也不知道應該從Volume內的哪一個StorageServer中讀取。因此用戶需手持欲訪問的文件的VolumeID向TrackerServer詢問，TrackerServe會均衡當前各StorageServer的IO負載情況，返回一個最佳的StorageServer的ip地址。最後用戶與該StorageServer鏈接，出示欲訪問文件的FileID，StorageServer上會維持一個FileID對應偏移量的表，從而獲得欲訪問文件的偏移量。

可見，FastDFS的文件名策略將文件存儲位置信息隱含在文件名中，從而減小了元數據量，達到了優化小文件存儲性能的做用。

FastDFS是一款類Google FS的開源分佈式文件系統，它用純C語言實現，支持Linux、FreeBSD、AIX等UNIX系統。它只能經過專有API對文件進行存取訪問，不支持POSIX接口方式，不能mount使用。準確地講，Google FS以及FastDFS、mogileFS、HDFS、TFS等類GoogleFS都不是系統級的分佈式文件系統，而是應用級的分佈式文件存儲服務。

FastDFS的設計理念

FastDFS是爲互聯網應用量身定作的分佈式文件系統，充分考慮了冗餘備份、負載均衡、線性擴容等機制，並注重高可用、高性能等指標。和現有的類Google FS分佈式文件系統相比，FastDFS的架構和設計理念有其獨到之處，主要體如今輕量級、分組方式和對等結構三個方面。

輕量級

FastDFS只有兩個角色：Tracker server和Storage server。Tracker server做爲中心結點，其主要做用是負載均衡和調度。Tracker server在內存中記錄分組和Storage server的狀態等信息，不記錄文件索引信息，佔用的內存量不多。另外，客戶端（應用）和Storage server訪問Tracker server時，Tracker server掃描內存中的分組和Storage server信息，而後給出應答。由此能夠看出Tracker server很是輕量化，不會成爲系統瓶頸。

FastDFS中的Storage server在其餘文件系統中一般稱做Trunk server 它直接利用OS的文件系統存儲文件。FastDFS不會對文件進行分塊存儲，衆所周知，FastDFS不對文件進行分塊存儲，與支持文件分塊存儲的DFS相比，更加簡潔高效，而且徹底能知足絕大多數互聯網應用的實際須要。

在FastDFS中，客戶端上傳文件時，文件ID不是由客戶端指定，而是由Storage server生成後返回給客戶端的。文件ID中包含了組名、文件相對路徑和文件名，Storage server能夠根據文件ID直接定位到文件。所以FastDFS集羣中根本不須要存儲文件索引信息，這是FastDFS比較輕量級的一個例證。而其餘文件系統則須要存儲文件索引信息，這樣的角色一般稱做NameServer。其中mogileFS採用MySQL數據庫來存儲文件索引以及系統相關的信息，其侷限性顯而易見，MySQL將成爲整個系統的瓶頸。

FastDFS輕量級的另一個體現是代碼量較小。最新的V2.0包括了C客戶端API、FastDHT客戶端API和PHP extension等，代碼行數不到5.2萬行。

分組方式

FastDFS採用了分組存儲方式。集羣由一個或多個組構成，一個組由一臺或多臺存儲服務器組成，同組內的多臺Storage server之間是互備關係，同組存儲服務器上的文件是徹底一致的。文件上傳、下載、刪除等操做能夠在組內任意一臺Storage server上進行。相似木桶短板效應，一個組的存儲容量爲該組內存儲服務器容量最小的那個，因而可知組內存儲服務器的軟硬件配置最好是一致的。

採用分組存儲方式的好處是靈活、可控性較強。好比上傳文件時，能夠由客戶端直接指定上傳到的組。一個分組的存儲服務器訪問壓力較大時，能夠在該組增長存儲服務器來擴充服務能力（縱向擴容）。當系統容量不足時，能夠增長組來擴充存儲容量（橫向擴容）。採用這樣的分組存儲方式，可使用FastDFS對文件進行管理，使用主流的Web server如Apache、nginx等進行文件下載。

對等結構

FastDFS集羣中的Tracker server也能夠有多臺，Tracker server和Storage server均不存在單點問題。Tracker server之間是對等關係，組內的Storage server之間也是對等關係。傳統的Master-Slave結構中的Master是單點，寫操做僅針對Master。若是Master失效，須要將Slave提高爲Master，實現邏輯會比較複雜。和Master-Slave結構相比，對等結構中全部結點的地位是相同的，每一個結點都是Master，不存在單點問題。

FastDFS的架構

圖1展現的是FastDFS的系統架構。

從圖1能夠看出，Tracker server之間相互獨立，不存在直接聯繫。

客戶端和Storage server主動鏈接Tracker server。Storage server主動向Tracker server報告其狀態信息，包括磁盤剩餘空間、文件同步情況、文件上傳下載次數等統計信息。Storage server會鏈接集羣中全部的Tracker server，向他們報告本身的狀態。Storage server啓動一個單獨的線程來完成對一臺Tracker server的鏈接和定時報告。須要說明的是，一個組包含的Storage server不是經過配置文件設定的，而是經過Tracker server獲取到的。

不一樣組的Storage server之間不會相互通訊，同組內的Storage server之間會相互鏈接進行文件同步。

Storage server採用binlog文件記錄文件上傳、刪除等更新操做。binlog中只記錄文件名，不記錄文件內容。

文件同步只在同組內的Storage server之間進行，採用push方式，即源頭服務器同步給目標服務器。只有源頭數據才須要同步，備份數據並不須要再次同步，不然就構成環路了。有個例外，就是新增長一臺Storage server時，由已有的一臺Storage server將已有的全部數據（包括源頭數據和備份數據）同步給該新增服務器。

Storage server中由專門的線程根據binlog進行文件同步。爲了最大程度地避免相互影響以及出於系統簡潔性考慮，Storage server對組內除本身之外的每臺服務器都會啓動一個線程來進行文件同步。

接下來咱們一塊兒看一下文件上傳和下載的交互過程。文件上傳和下載流程分別如圖二、圖3所示。文件上傳流程的步驟以下：

1. Client詢問Tracker server上傳到的Storage server；

2. Tracker server返回一臺可用的Storage server，返回的數據爲該Storage server的IP地址和端口；

3. Client直接和該Storage server創建鏈接，進行文件上傳，Storage server返回新生成的文件ID，文件上傳結束。

文件下載流程的步驟以下：

1. Client詢問Tracker server能夠下載指定文件的Storage server，參數爲文件ID（包含組名和文件名）；

2. Tracker server返回一臺可用的Storage server；

3. Client直接和該Storage server創建鏈接，完成文件下載。

文件同步延遲問題的提出

客戶端將一個文件上傳到一臺Storage server後，文件上傳工做就結束了。由該Storage server根據binlog中的上傳記錄將這個文件同步到同組的其餘Storage server。這樣的文件同步方式是異步方式，異步方式帶來了文件同步延遲的問題。新上傳文件後，在還沒有被同步過去的Storage server上訪問該文件，會出現找不到文件的現象。FastDFS是如何解決文件同步延遲這個問題的呢？

文件的訪問分爲兩種狀況：文件更新和文件下載。文件更新包括設置文件附加屬性和刪除文件。文件的附加屬性包括文件大小、圖片寬度、圖片高度等。FastDFS中，文件更新操做都會優先選擇源Storage server，也就是該文件被上傳到的那臺Storage server。這樣的作法不只避免了文件同步延遲的問題，並且有效地避免了在多臺Storage server上更新同一文件可能引發的時序錯亂的問題。

那麼文件下載是如何解決文件同步延遲這個問題的呢？

要回答這個問題，須要先了解文件名中包含了什麼樣的信息。Storage server生成的文件名中，包含了源Storage server的IP地址和文件建立時間等字段。文件建立時間爲UNIX時間戳，後面稱爲文件時間戳。從文件名或文件ID中，能夠反解出這兩個字段。

而後咱們再來看一下，Tracker server是如何準確地知道一個文件已被同步到一臺Storage server上的。前面已經講過，文件同步採用主動推送的方式。另外，每臺storage server都會定時向tracker server報告它向同組的其餘storage server同步到的文件時間戳。當tracker server收到一臺storage server的文件同步報告後，它會依次找出該組內各個storage server（後稱做爲S）被同步到的文件時間戳最小值，做爲S的一個屬性記錄到內存中。

FastDFS對文件同步延遲問題的解決方案

下面咱們來看一下FastDFS採起的解決方法。

一個最簡單的解決辦法，和文件更新同樣，優先選擇源Storage server下載文件便可。這能夠在Tracker server的配置文件中設置，對應的參數名爲download_server。

另一種選擇Storage server的方法是輪流選擇（round-robin）。當Client詢問Tracker server有哪些Storage server能夠下載指定文件時，Tracker server返回知足以下四個條件之一的Storage server：

該文件上傳到的源Storage server，文件直接上傳到該服務器上的；

文件建立時間戳 < Storage server被同步到的文件時間戳，這意味着當前文件已經被同步過來了；

文件建立時間戳=Storage server被同步到的文件時間戳，且（當前時間—文件建立時間戳） > 一個文件同步完成須要的最大時間（如5分鐘）；

（當前時間—文件建立時間戳） > 文件同步延遲閾值，好比咱們把閾值設置爲1天，表示文件同步在一天內確定能夠完成。

結束語

看了上面的介紹，你是否定爲FastDFS比較簡潔高效呢？原雅虎同事——一位比較資深的系統架構師聽完FastDFS介紹後，做出這樣的評價：「FastDFS是窮人的解決方案」。他的意思是說FastDFS把簡潔和高效作到了極致，很是節約資源，中小網站徹底用得起，這是對FastDFS的極大承認和褒獎。

FastDFS從2008年7月發佈至今，已推出31個版本，後續完善和優化工做正在持續進行中。目前已有多家公司在生產環境中使用FastDFS，相信經過咱們的不懈努力，FastDFS必定會愈來愈好！

第二部分 fdfs安裝和實戰

基礎環境說明，centos 6.6 系統，6臺服務器，其中兩臺tracker 4臺 storages

hd01	tracker服務器	192.168.1.11
hd02	tracker服務器	192.168.1.12
hd03	storages服務器	192.168.1.13
hd04	storages服務器	192.168.1.14
hd05	storages服務器	192.168.1.15
hd06	storages服務器	192.168.1.16

1. 配置每臺服務器的主機名，以hd1爲例配置以下

[root@hd1 ~]# cat /etc/hosts

127.0.0.1 hd01 localhost

192.168.1.11 hd01

192.168.1.12 hd02

192.168.1.13 hd03

192.168.1.14 hd04

192.168.1.15 hd05

192.168.1.16 hd06

[root@hd2 ~]# cat /etc/hosts

127.0.0.1 hd02 localhost

192.168.1.11 hd01

192.168.1.12 hd02

192.168.1.13 hd03

192.168.1.14 hd04

192.168.1.15 hd05

192.168.1.16 hd06

其餘主機的/etc/hosts 忽略

2.安裝依賴包（在全部服務器上）

[root@hd1 ~]# yum -y install perl-devel make gcc cmake

3.安裝fastdfs所須要的common庫（在全部的服務器）

unzip libfastcommon-master.zip

cd libfastcommon-master

./make.sh

./make.sh install

4.安裝fastdfs（在全部機器）

unzip fastdfs-master.zip

cd fastdfs-master

./make.sh

./make.sh install

5.修改配置文件（在全部tracker服務器上）

[root@hd1 ~]# cp /etc/fdfs/client.conf.sample /etc/fdfs/client.conf

[root@hd1 ~]# cp /etc/fdfs/tracker.conf.sample /etc/fdfs/tracker.conf

[root@hd2 ~]# cp /etc/fdfs/client.conf.sample /etc/fdfs/client.conf

[root@hd2 ~]# cp /etc/fdfs/tracker.conf.sample /etc/fdfs/tracker.conf

修改配置文件

vim /etc/fdfs/tracker.conf

base_path=/data/fdfs/Tracker #第22行

http.server_port=80 #第260行

建立目錄

mkdir /data/fdfs/Tracker -p

修改配置文件

vim /etc/fdfs/client.conf

base_path=/data/fdfs/client #第10行

tracker_server=192.168.1.11:22122 #第14行

tracker_server=192.168.1.12:22122

建立目錄

mkdir /data/fdfs/client -p

啓動服務

service fdfs_trackerd start

[root@hd1 ~]# lsof -i :22122

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

fdfs_trac 36821 root 5u IPv4 255518 0t0 TCP *:22122 (LISTEN)

在storage上操做（四臺storage，192.168.1.13,192.168.1.14爲同一個組）進行以下操做：

cp /etc/fdfs/storage.conf.sample /etc/fdfs/storage.conf

vim /etc/fdfs/storage.conf

group_name=group1 #第3行

base_path=/data/fdfs/storage #第41行

store_path0=/data/fdfs/storage #第109行

tracker_server=192.168.1.11:22122 #第118行

tracker_server=192.168.1.12:22122

#結束！！！

在storage上操做（四臺storage，192.168.1.15,192.168.1.16爲同一個組）進行以下操做：

vim /etc/fdfs/storage.conf

group_name=group2 #第3行

base_path=/data/fdfs/storage #第41行

store_path0=/data/fdfs/storage #第109行

tracker_server=192.168.1.11:22122 #第118行

tracker_server=192.168.1.12:22122

#結束！！！

建立目錄

mkdir /data/fdfs/storage -p

啓動storage端的服務

service fdfs_storaged start

檢查Tracker hd01 的服務器的狀態

[root@hd1 ~]# fdfs_monitor /etc/fdfs/client.conf

Storage 1:

id = 192.168.1.13

ip_addr = 192.168.1.13 (hd03) ACTIVE

Storage 2:

id = 192.168.1.14

ip_addr = 192.168.1.14 (hd04) ACTIVE

#以上表示192.168.1.11跟蹤服務器上有兩個storage服務器192.168.1.13和192.168.1.14

測試上傳

[root@hd1 ~]# echo abcd >11.txt

[root@hd1 ~]# fdfs_test /etc/fdfs/client.conf upload /root/11.txt

group_name=group1, remote_filename=M00/00/00/wKgBDVkCHIaAQfRtAAAABXWItN4729_big.txt

source ip address: 192.168.1.13

#咱們緊接着，繼續上傳

[root@hd1 ~]# echo 1234 >22.txt

[root@hd1 ~]# fdfs_test /etc/fdfs/client.conf upload /root/22.txt

group_name=group1, remote_filename=M00/00/00/wKgBDlkCHJ2AKpdHAAAABVCR-FM269.txt

source ip address: 192.168.1.14

#以上說明會將上傳任務負載分擔到兩個不一樣的storage服務器上

那麼這兩個storage服務器上的文件會不會同步呢？

咱們去192.168.1.13上查找有沒有wKgBDlkCHJ2AKpdHAAAABVCR-FM269.txt文件，若是有說明，192.168.1.14 把22.txt同步到192.168.1.13上了

檢查另一個跟蹤服務器的狀態

[root@hd2 ~]# fdfs_monitor /etc/fdfs/client.conf

測試上傳1

[root@hd2 ~]# fdfs_test /etc/fdfs/client.conf upload /root/onekeyyum.sh

從上面的輸出能夠看到文件被上傳到了hd06 的下面，能夠查看一下

測試上傳2

[root@hd1 ~]# fdfs_upload_file /etc/fdfs/client.conf /root/33.txt

作md5驗證：

查看文件信息

刪除文件

#刪除以後沒有信息提示，咱們進行查找，結果以下

#上面表示沒有這個文件了

移除故障節點

加入節點上的fastdfs出了問題，咱們須要將它從組中移除，可根據下面的命令操做

1）停掉fastdfs上的storage服務

/etc/init.d/fdfs_storaged stop

2）將問題節點（hd5）從組中移除

fdfs_monitor /etc/fdfs/client.conf delete group2 192.168.1.15

1）移除成功後，再次查看

[root@hd1 ~]# fdfs_monitor /etc/fdfs/client.conf

當hd05上的fastdfs修復後，能夠再把它加入到fastdfs組中，加入的操做只須要把hd05上的fastdfs服務正常啓動就好，由於配置文件已經作了配置，若是服務正常的話，修復後的節點能夠自動加入到fastdfs組中。

啓動fastdfs_storaged服務

[root@hd5 ~]# /etc/init.d/fdfs_storaged start

再次查看，恢復正常

總結：group機制自己可用來作負載均衡，但這只是一種靜態的負載均衡機制，須要預先知道應用的訪問特性；同時group機制也致使不可能在group之間遷移數據來作動態負載均衡

第三部分配置nginx爲storage server提供http訪問接口

在大多數業務場景中，每每須要爲FastDFS存儲的文件提供http下載服務，而儘管FastDFS在其storage及tracker都內置了http服務，但性能表現卻不盡如人意；經過增長基於當前主流web服務器的擴展模塊(包括nginx/apache)，利用web服務器直接對本機storage數據文件提供http服務，以提升文件下載的性能，同時避免了同組storage服務器同步延遲致使不能訪問的問題。

描述：

nginx 配置在storage節點上；

由於 nginx 要想鏈接 fastdfs 就必需要有相應的模塊，因此要編譯安裝 nginx 把fastdfs-nginx-module 模塊編譯進去

#nginx 安裝（Tracker節點）

#Nginx緩存和反向代理

[root@hd1 ~]# yum install -y pcre pcre-devel openssl-devel openssl

[root@hd1 ~]# tar -xf ngx_cache_purge-2.3.tar.gz

[root@hd1 nginx-1.10.1]# ./configure --prefix=/usr/local/nginx --add-module=/root/ngx_cache_purge-2.3 --with-http_stub_status_module --with-http_ssl_module

[root@hd1 nginx-1.10.1]#make && make install

[root@hd1 ~]# cd /usr/local/nginx/conf/

[root@hd1 conf]# cat nginx.conf

user root;

worker_processes 1;

events {

worker_connections 1024;

}

http {

include mime.types;

default_type application/octet-stream;

sendfile on;

tcp_nopush on;

keepalive_timeout 65;

proxy_cache_path /usr/local/nginx/proxy_cache_path levels=1:2 keys_zone=cache_one:500m inactive=1d max_size=10g;

proxy_temp_path /usr/local/nginx/proxy_tmp_path;

gzip on;

gzip_min_length 1k;

gzip_buffers 4 16k;

gzip_types text/plain application/x-javascript text/css application/xml text/javascript application/x-httpd-php;

gzip_vary on;

upstream fdfs {

server 192.168.1.13:80 max_fails=3 fail_timeout=30s weight=1;

server 192.168.1.14:80 max_fails=3 fail_timeout=30s weight=1;

}

server {

listen 80;

server_name localhost;

location / {

root html;

index index.html index.htm;

}

location /group1/M00 {

proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;

proxy_pass http://fdfs;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_connect_timeout 300;

proxy_send_timeout 300;

proxy_read_timeout 600;

proxy_max_temp_file_size 10m;

proxy_busy_buffers_size 256k;

proxy_buffer_size 256k;

proxy_buffers 4 256k;

proxy_cache_valid 200 304 12h ;

proxy_cache_valid 301 302 1m ;

proxy_cache_valid any 1m;

proxy_cache cache_one;

proxy_cache_key $host$uri$is_args$args;

}

location ~ /purge(/.*) {

allow 127.0.0.1 ;

allow 192.168.1.0/24 ;

deny all ;

proxy_cache_purge cache_one $host$1$is_args$args ;

}

error_page 500 502 503 504 /50x.html;

location = /50x.html {

root html;

}

檢查語法

[root@hd1 conf]# /usr/local/nginx/sbin/nginx -t

nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok

nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

建立緩存目錄

[root@hd1 conf]# mkdir -p /usr/local/nginx/proxy_temp_path

[root@hd1 conf]# mkdir -p /usr/local/nginx/proxy_cache_path

啓動服務

[root@hd1 ~]# /usr/local/nginx/sbin/nginx

[root@hd1 ~]# netstat -lntup | grep 80

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 71571/nginx

#nginx 安裝（兩臺Storage節點）

[root@hd3 ~]#wget -c https://nginx.org/download/nginx-1.12.1.tar.gz

[root@hd3 ~]#wget https://github.com/happyfish100/fastdfs-nginx-module/archive/master.zip

[root@hd3 ~]#tar -xf nginx-1.12.1.tar.gz

[root@hd4 ~]# unzip master.zip

[root@hd3 ~]# yum install -y pcre pcre-devel openssl-devel openssl

[root@hd3 ~]# cd nginx-1.12.1

[root@hd3 ~]#./configure --prefix=/usr/local/nginx --add-module=/root/fastdfs-nginx-module-master/src --with-http_stub_status_module --with-http_ssl_module

root@hd3 ~]#make && make install

此處編譯出錯

解決方法

解決辦法：

https://github.com/happyfish100/fastdfs/issues/126

修改/root/fastdfs-nginx-module-master/src/common.c第1245行

把（pContext-> range_count> 1 &&！g_http_params.support_multi_range））最後面的條件

去掉了改爲（pContext-> range_count > 1））

從新make就行了

目前看沒有什麼問題

make install 成功

[root@hd3 ~]# cp /root/fastdfs-nginx-module-master/src/mod_fastdfs.conf /etc/fdfs/