FastDFS是一個開源的輕量級分布式文件系統，它對文件進行管理，功能包括：文件存儲、文件同步、文件訪問（文件上傳、文件下載）等，解決了大容量存儲和負載均衡的問題。特別適合以文件為載體的在線服務，如相冊網站、視頻網站等等。
主頁地址： https://github.com/happyfish100/fastdfs
FastDFS從2008年7月發布至今，已推出31個版本，后續完善和優化工作正在持續進行中。目前已有多家公司在生產環境中使用FastDFS。
FastDFS是一款類Google FS的開源分布式文件系統，它用純C語言實現，支持Linux、FreeBSD、AIX等UNIX系統。它只能通過專有API對文件進行存取訪問，不支持POSIX接口方式，不能mount使用。准確地講，Google FS以及FastDFS、mogileFS、HDFS、TFS等類Google FS都不是系統級的分布式文件系統，而是應用級的分布式文件存儲服務。
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或Data server。Storage server直接利用OS的文件系統存儲文件。FastDFS不會對文件進行分塊存儲，客戶端上傳的文件和Storage server上的文件一一對應。
眾所周知，大多數網站都需要存儲用戶上傳的文件，如圖片、視頻、電子文檔等。出於降低帶寬和存儲成本的考慮，網站通常都會限制用戶上傳的文件大小，例如圖片文件不能超過5MB、視頻文件不能超過100MB等。我認為，對於互聯網應用，文件分塊存儲沒有多大的必要。它既沒有帶來多大的好處，又增加了系統的復雜性。FastDFS不對文件進行分塊存儲，與支持文件分塊存儲的DFS相比，更加簡潔高效，並且完全能滿足絕大多數互聯網應用的實際需要。
在FastDFS中，客戶端上傳文件時，文件ID不是由客戶端指定，而是由Storage server生成后返回給客戶端的。文件ID中包含了組名、文件相對路徑和文件名。
Storage server可以根據文件ID直接定位到文件。因此FastDFS集群中根本不需要存儲文件索引信息，這是FastDFS比較輕量級的一個例證。
而其他文件系統則需要存儲文件索引信息，這樣的角色通常稱作NameServer。其中mogileFS采用MySQL數據庫來存儲文件索引以及系統相關的信息，其局限性顯而易見，MySQL將成為整個系統的瓶頸。
FastDFS輕量級的另外一個體現是代碼量較小。包括了C客戶端API、FastDHT客戶端API和PHPextension等，代碼行數不到5.2萬行。
- 分組方式
類Google FS都支持文件冗余備份，例如Google FS、TFS的備份數是3。一個文件存儲到哪幾個存儲結點，通常采用動態分配的方式。采用這種方式，一個文件存儲到的結點是不確定的。舉例說明，文件備份數是3，集群中有A、B、C、D四個存儲結點。文件1可能存儲在A、B、C三個結點，文件2可能存儲在B、C、D三個結點，文件3可能存儲在A、B、D三個結點。
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，不存在單點問題。
2 系統結構
2.1跟蹤器與存儲結點
FastDFS服務端有兩個角色： 跟蹤器（tracker）和 存儲節點（storage）。
跟蹤器主要做調度工作，在訪問上起負載均衡的作用。
存儲節點存儲文件，完成文件管理的所有功能：存儲、同步和提供存取接口，FastDFS同時對文件的meta data進行管理。所謂文件的meta data就是文件的相關屬性，以鍵值對（key value pair）方式表示，如：width=1024，其中的key為width，value為1024。文件meta data是文件屬性列表，可以包含多個鍵值對。
FastDFS系統結構如下圖所示：
為了支持大容量，存儲節點（服務器）采用了分卷（或分組）的組織方式。存儲系統由一個或多個卷組成，卷與卷之間的文件是相互獨立的，所有卷的文件容量累加就是整個存儲系統中的文件容量。
一個卷可以由一台或多台存儲服務器組成，一個卷下的存儲服務器中的文件都是相同的，卷中的多台存儲服務器起到了冗余備份和負載均衡的作用。在卷中增加服務器時，同步已有的文件由系統自動完成，同步完成后，系統自動將新增服務器切換到線上提供服務。
當存儲空間不足或即將耗盡時，可以動態添加卷。只需要增加一台或多台服務器，並將它們配置為一個新的卷，這樣就擴大了存儲系統的容量。FastDFS中的文件標識分為兩個部分：卷名和文件名，二者缺一不可。
- Tracker server之間相互獨立，不存在直接聯系
- 客戶端和Storage server主動連接Tracker server。Storage server主動向Tracker server報告其狀態信息
- 一個組包含的Storage server不是通過配置文件設定的，而是通過Tracker server獲取到的
- 不同組的Storage server之間不會相互通信，同組內的Storage server之間會相互連接進行文件同步
- 一個組的存儲容量為該組內存儲服務器容量最小的那個
上傳流程：
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（包含Volume號和文件名）；
2. Tracker server返回一台可用的Storage server；
3. Client直接和該Storage server建立連接，完成文件下載。
4.生成文件名
當文件存儲到某個子目錄后，即認為該文件存儲成功，接下來會為該文件生成一個文件名，文件名由group、存儲目錄、兩級子目錄、fileid、文件后綴名（由客戶端指定，主要用於區分文件類型）拼接而成。
5.文件同步
寫文件時，客戶端將文件寫至group組內一個storage server即認為寫文件成功，storage server寫完文件后，會由后台線程將文件同步至同group組內其他的storage server。
每個storage寫文件后，同時會寫一份binlog，binlog里不包含文件數據，只包含文件名等元信息，這份binlog用於后台同步，storage會記錄向group內其他storage同步的進度，以便重啟后能接上次的進度繼續同步；進度以時間戳的方式進行記錄，所以最好能保證集群內所有server的時鍾保持同步。
storage的同步進度會作為元數據的一部分匯報到tracker上，tracke在選擇讀storage的時候會以同步進度作為參考。
比如一個group內有A、B、C三個storage server，A向C同步到進度為T1 (T1以前寫的文件都已經同步到B上了），B向C同步到時間戳為T2（T2 > T1)，tracker接收到這些同步進度信息時，就會進行整理，將最小的那個做為C的同步時間戳，本例中T1即為C的同步時間戳為T1（即所有T1以前寫的數據都已經同步到C上了）；同理，根據上述規則，tracker會為A、B生成一個同步時間戳。
客戶端將一個文件上傳到一台Storage server后，文件上傳工作就結束了。由該Storage server根據binlog中的上傳記錄將這個文件同步到同組的其他Storage server。這樣的文件同步方式是異步方式.
同步延遲問題：
異步方式帶來了文件同步延遲的問題。新上傳文件后，在尚未被同步過去的Storage server上訪問該文件，會出現找不到文件的現象。FastDFS是如何解決文件同步延遲這個問題的呢？
文件的訪問分為兩種情況：文件更新和文件下載。
文件更新：包括設置文件附加屬性和刪除文件。文件的附加屬性包括文件大小、圖片寬度、圖片高度等。FastDFS中，文件更新操作都會優先選擇源Storage server，也就是該文件被上傳到的那台Storage server。這樣的做法不僅避免了文件同步延遲的問題，而且有效地避免了在多台Storage server上更新同一文件可能引起的時序錯亂的問題。
文件下載：那么文件下載是如何解決文件同步延遲這個問題的呢？
要回答這個問題，需要先了解文件名中包含了什么樣的信息。
Storage server生成的文件名（fileid）中，包含了源Storage server的IP地址和文件創建時間等字段。文件創建時間為UNIX時間戳，后面稱為文件時間戳。從文件名或文件ID中，可以反解出這兩個字段。
然后我們再來看一下，Tracker server是如何准確地知道一個文件已被同步到一台Storage server上的。前面已經講過，文件同步采用主動推送的方式。另外，每台storage server都會定時向tracker server報告它向同組的其他storage server同步到的文件時間戳。當tracker server收到一台storage server的文件同步報告后，它會依次找出該組內各個storage server被同步到的文件時間戳最小值，作為storage server的一個屬性記錄到內存中。
FastDFS對文件同步延遲問題的解決方案
下面我們來看一下FastDFS采取的解決方法。
1.一個最簡單的解決辦法，和文件更新一樣，優先選擇源Storage server下載文件即可。這可以在Tracker server的配置文件中設置，對應的參數名為download_server。
2.另外一種選擇Storage server的方法是輪流選擇（round-robin）。當Client詢問Tracker server有哪些Storage server可以下載指定文件時，Tracker server返回滿足如下四個條件之一的Storage server：
- 該文件上傳到的源Storage server，文件直接上傳到該服務器上的；
- 文件創建時間戳 < Storage server被同步到的文件時間戳，這意味着當前文件已經被同步過來了；
- 文件創建時間戳=Storage server被同步到的文件時間戳，且（當前時間—文件創建時間戳） > 一個文件同步完成需要的最大時間（如5分鍾）；
- （當前時間—文件創建時間戳） > 文件同步延遲閾值，比如我們把閾值設置為1天，表示文件同步在一天內肯定可以完成。