在工作中使用到了fastdfs分布式文件系統用作圖片、文件的存儲，由於它小巧、易用、高性能、自帶分布式和負載均衡的功能，收到了很多公司和

團隊的喜愛。自己在使用過程中也覺得非常的好用所以寫幾篇文章對fastdfs文件系統概述、存儲結構、分布式實現和與dubbo結合起來實現一個分

布式服務給其它服務和應用進行調用，來讓更多朋友對它的了解並使用。

fastdfs文件概述：

在百度百科裏面是這樣介紹的：“FastDFS是一個開源的輕量級分布式文件系統，它對文件進行管理，功能包括：文件存儲、文件同步、文件訪問

（文件上傳、文件下載）等，解決了大容量存儲和負載均衡的問題。特別適合以文件為載體的在線服務，如相冊網站、視頻網站等等。"這段描述的

非常的正確，fastdfs就是有這麽好。

fastdfs文件系統架構圖

fastdfs文件系統架構圖（圖來自互聯網）

從圖中我們可以看出fastdfs文件系統由tracker集群、storage server服務組成。

Tracker：是FastDFS文件系統的協調者，負責管理所有的storage server和group，每個storage在啟動後會連接Tracker，告知自己所屬的group等信息，

並保持周期性的心跳，tracker根據storage的心跳信息，建立group與storage server 的映射表。文件的上傳和刪除，並不需要tracker作為中間者，調用

storage server操作文件。client直接操作storage server。

storage server：簡稱storage，以組（卷，group或volume）為單位組織，一個group內包含多臺storage機器，數據互為備份，存儲空間以group內容

量最小的storage為準，所以建議group內的多個storage盡量配置相同，以免造成存儲空間的浪費。

fastdfs工作原理：客戶端client 調用fastdfs的api,獲取可用的tracker server ，再調用tracker server 獲取可用的組，tracker server 通過負載均衡返回一個

最優的storage server,這樣客戶端與client就建立了連接，client就可以調用storage server對文件進行上傳、刪除和追加的操作。

tracker和storage sever是fastdfs的核心，是不可缺少的。下一章將會給大家介紹tracker和storage sever,以及它們的關系，它們是怎麽搭配工作的。

storage

在上一篇文章的fastdfs結構圖中，我們可以看出FastDFS服務端有兩個角色：跟蹤器（tracker）和存儲節點（storage）。跟蹤器（tracker）主要做

調度工作，就像公交車站裏面的調務員一樣，它負責通過負載均衡選出最優的存儲節點（storage）。存儲節點（storage）顧名思義就是負責存儲、

數據同步、數據的操作的一個服務。今天我們將會重點對Storage server進行介紹。

概述

Storage server（簡稱storage）以組group為單位，如上圖一個group內包含多臺storage機器，數據互為備份，存儲空間以group內容量最小的

storage為準，建議group內的多個storage盡量配置相同，以免造成存儲空間的浪費。以group為單位組織存儲能方便的進行應用隔離、負載均衡

、副本數定制（group內storage server數量即為該group的副本數），比如將不同應用數據存到不同的group就能隔離應用數據，比如group1為內

網訪問數據，group2為外網訪問數據。同時還可根據應用的訪問情況來將應用分配到不同的group來做負載均衡；缺點是group的容量受單機存儲

容量的限制比如gourp1中有3個storage，storage1為100G、storage2為120G、storage為110G，那麽對於group1來說存儲空間大小就是100G。

當group中有機器壞掉時，數據的恢復只能依賴group中的其他機器，所以恢復時間會特別的長。

storage存儲

在group中每個storage的存儲依賴於本地文件系統，所以storage可以動態增加存儲空間大小，比如fastdfs系統使用一段時間之後group1的空間使

用完了，那我們可以動態為group1下面的所有storage主機掛載更多的磁盤。而且可以指定那些盤為storage的存儲目錄比如有5塊磁盤，分別掛載

在/data/disk1-/data/disk5，那麽可將這5個存儲目錄都配置為storage的數據存儲目錄。

當storage接受到客戶端或其它storage同步的寫文件請求時，將會根據配置好的規則，選擇其中一個存儲目錄來存儲文件。

為了防止單個目錄下的文件數太多，在storage第一次啟動時，會在每個數據存儲目錄裏創建2級子目錄，每級256個，總共65536個文件，新寫的文

件會以hash的方式被路由到其中某個子目錄下，然後將文件數據直接作為一個本地文件存儲到該目錄中。

storage的同步策略：

文件同步是由獨立的線程負責的，每個Storage都有到同組中其他Storage的同步線程，如一組三個Storage，那麽每個Storage都有兩個線程負責到其他
兩個Storage的同步。同步線程由Tracker通訊線程啟動，因為只有Tracker才知道一組中有哪些Storage。

同步線程的執行過程主要由源同步與Binlog同步兩部分組成，具體的同步過程我將會在另一篇文章中進行詳細的介紹。

tracker

tracker server是FastDFS文件系統的協調者,其主要作用是負載均衡和調度。Tracker server在內存中記錄分組和Storage server的狀態等信息，

不記錄文件索引信息，占用的內存量很少。另外，客戶端（應用）和Storage server訪問Tracker server時，Tracker server掃描內存中的分組和

Storage server信息，然後給出應答。由此可以看出Tracker server非常輕量化，不會成為系統瓶頸。

FastDFS集群中的Tracker server可以有多臺，Tracker server和Storage server均不存在單點問題。Tracker server之間是對等關系，組內的

Storage server之間也是對等關系。傳統的Master-Slave結構中的Master是單點，寫操作僅針對Master。如果Master失效，需要將Slave提升為Master，

實現邏輯會比較復雜。和Master-Slave結構相比，對等結構中所有結點的地位是相同的，每個結點都是Master，不存在單點問題。

FastDFS系統結構

從上圖中可以看出，Tracker server之間相互獨立，不存在直接聯系。每次客戶端client不管是上傳、下載還是刪除，首先

都要請求Tracker server，Tracker server通過負載均衡返回指定組類的最優的Storage server，然後後client再調用Storage

server進行上傳、下載和刪除功能。

在fastdfs系統中，客戶端clinet和Storage server主動連接Tracker server。Storage server主動向Tracker server報告其狀態信息，包括磁盤剩

余空間、文件同步狀況、文件上傳下載次數等統計信息。Storage server會連接整個集群中所有的Tracker server，向他們報告自己的狀態。

Storage server啟動一個單獨的線程來完成對一臺Tracker server的連接和定時報告。需要特別說明的是，一個組包含的Storage server不是通

過配置文件設定的，而是通過Tracker server獲取到的。

從上面的描述我們可以看出Tracker server是整個系統的調度者和負載均衡者，同時也收集各個組的健康狀態。它很像nginx+keeplive的集

合體，有了Tracker server使得整個fastdfs系統性能更優，健壯性也更強。所以它在整個系統中是非常重要的。

fastdfs分布式文件系統文件上傳、下載、刪除交互過程

在講解fastdfs的上傳、下載和刪除流程之前，我們先介紹fastdfs中的工程流程：首先客戶端client 調用fastdfs的api,獲取可用的tracker server ，

再調用tracker server 獲取可用的組，tracker server 通過負載均衡返回一個最優的storage server,這樣客戶端與client就建立了連接，client就可

以調用storage server對文件進行上傳、刪除和追加的操作。

下面我們將結合時序圖的方式給大家詳細講解fastdfs的上傳、下載和刪除各個角色的交互流程：

文件上傳交互流程

從上圖中我們可以看出整個交互過程分為3步：

1. 1. client詢問tracker上傳到的storage，不需要附加參數；
   2. tracker返回一臺可用的storage；
   3. client直接和storage通訊完成文件上傳。

上傳成功後，storage將會返回一個字符串數組，其中results[0]:卷名即組，results[1]:文件名（包含在文件系統的目錄結構）。

在FastDFS中的文件標識分為兩個部分：卷名和文件名，二者缺一不可。

組group如group1,文件名由group、存儲目錄、兩級子目錄、fileid、文件後綴名（由客戶端指定，主要用於區分文件類型）

拼接而成。如：/group2/M00/00/01/goQeAFUjqu2AdlUPABHKPTiTXBY295.jpg

具體的訪問地址需自己在代碼中拼上域名和端口號如：http://xxx.xxx.com:8002/group2/M00/00/01/goQeAFUjqu2AdlUPA

BHKPTiTXBY295.jpg

需要說明的是，client為使用FastDFS服務的調用方，client也應該是一臺服務器，它對tracker和storage的調用均為服務器間的調用。

文件上傳類型有3種：

1. 1. upload：上傳普通文件，包括主文件 ；
   2. upload_appender：上傳appender文件，後續可以對其進行append操作【又用作斷點續傳】 ；
   3. upload_slave：上傳從文件；

下載文件交互過程

下載文件交互過程

從上圖中我們可以看出整個交互過程分為3步：

1. 1. client詢問tracker下載文件的storage，參數為文件標識（卷名和文件名）；
   2. tracker返回一臺可用的storage；
   3. client直接和storage通訊完成文件下載；

文件刪除交互過程

文件刪除交互過程

從上圖中我們可以看出整個交互過程分為3步：

1. 1. client詢問tracker下載文件的storage，參數為文件標識（卷名和文件名）；
   2. tracker返回一臺可用的storage；
   3. client直接和storage通訊完成文件刪除；

刪除成功後，返回int類型的結果值0:文件刪除成功，2：文件不存在 ，其它：文件刪除出錯；

Fastdfs分布式文件系統之文件同步機制

在前面幾篇文章中我們對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。

FastDFS分布式文件系統總結-草稿