什么是FastDFS

很多以文件為載體的在線服務，如相冊網站、視頻網站等，都需要對文件進行管理，包括文件的存儲、同步、訪問（文件上傳、文件下載）等，同時肯定會伴隨著大容量存儲和負載均衡的問題。

在日常的一些項目中，比如做用戶的KYC認證等，也需要存儲文件、圖片、視頻等。此時可以選擇使用OSS云服務，也可以自己構建相對專業(yè)的文件管理系統(tǒng)。

FastDFS是一個開源的輕量級分布式文件系統(tǒng)，用于解決大數據量存儲和負載均衡等問題，并需要通過專有API進行訪問。滿足大容量文件存儲問題，并保證高性能和高擴展性。它能夠很好的解決上述提到的業(yè)務場景。

FastDFS的特性

FastDFS為互聯(lián)網量身定制，充分考慮了冗余備份、負載均衡、線性擴容等機制，并注重高可用、高性能等指標，使用FastDFS很容易搭建一套高性能的文件服務器集群提供文件上傳、下載等服務。

優(yōu)點：

• 文件不分塊存儲，文件和系統(tǒng)中的文件一一對應。
• 對文件內容做hash處理，避免出現(xiàn)重復文件，節(jié)約磁盤空間。
• 下載文件支持HTTP協(xié)議，可基于內置Web Server或外部Web Server。
• 支持在線擴容，動態(tài)添加卷。支持文件冗余備份和負載均衡。
• 存儲服務器上可以保存文件屬性（meta-data）V2.0 網絡通信采用libevent，支持大并發(fā)訪問，整體性能更好。

缺點：

• 直接按文件存儲，可直接查看文件內容，缺乏文件安全性。
• 數據同步無校驗，存在靜默IO問題，降低系統(tǒng)可用性。
• 單線程數據同步，僅適合存儲小文件（4KB到500MB之間）。
• 備份數根據存儲分卷（分組）決定，缺乏文件備份數設置靈活性。
• 單個掛載點異常會導致整個存儲節(jié)點下線。
• 缺乏多機房容災支持。
• 靜態(tài)的負載均衡機制。

優(yōu)點與缺點并存，但針對中小型系統(tǒng)已經完全足夠使用了。

FastDFS的角色

初次接觸或部署FastDFS的朋友往往會有些疑惑，為什么要部署那么多服務才能使用FastDFS。這是由FastDFS的角色構成決定的。

FastDFS系統(tǒng)有三個角色：跟蹤服務器(Tracker Server)、存儲服務器(Storage Server)和客戶端(Client)。

如果通過Http訪問，通常情況下，還需要部署Nginx服務。

Tracker Server：跟蹤服務器，主要做調度工作，起到均衡的作用；負責管理所有的storage server和group，每個storage在啟動后會連接 Tracker，同步自己所屬group等信息，并保持周期性心跳。它是客戶端和數據服務器交互的樞紐。

Storage Server：存儲服務器，主要提供容量和備份服務；以group為單位，每個group內可以有多臺storage server，數據互為備份。文件及屬性（Meta Data）都保存在該服務器上。

Client：客戶端，上傳下載數據請求的發(fā)起方，通過專有接口，使用TCP/IP協(xié)議與跟蹤器服務器或存儲節(jié)點進行數據交互。

下面通過一張圖來看看FastDFS的不同角色在整個流轉過程中的作用。

上圖中Tracker相當于一個調度中心，上傳和下載都通過它來進行分配指定。

上面我們提到Nginx，客戶端通常會使用Ngnix等靜態(tài)服務器來調用或者做一部分的緩存。后面搭建環(huán)境時便是基于Nginx。

Storage cluster部分，由Volume1、Volume2……VolumeK組成，它們稱為卷（或者叫做組），卷與卷之間是平行的關系，可以根據資源的使用情況隨時增加，卷內服務器文件相互同步備份，以達到容災的目的。

上傳過程

當服務啟動之后，Storage Server會定期的向Tracker Server發(fā)送存儲信息。如果Tracker Server是集群形式，則每個Tracker之間的關系是對等的，客戶端上傳時選擇任意一個Tracker即可。

整體流程：當客戶端請求Tracker進行上傳操作時，會獲取存儲服務器相關信息，主要包括IP和端口。根據返回信息上傳文件，通過存儲服務器寫入磁盤，并返回給客戶端file_id、路徑信息、文件名等信息。

對應流程圖如下：

其中，當Tracker收到客戶端上傳文件的請求時，會為該文件分配一個可以存儲文件的group，當選定了group后就要決定給客戶端分配group中的哪一個storage server。

當分配好storage server后，客戶端向storage發(fā)送寫文件請求，storage將會為文件分配一個數據存儲目錄。然后為文件分配一個fileid，最后根據以上的信息生成文件名存儲文件。

生成的文件名基本格式如下：

下載過程

跟上傳一樣，在下載時客戶端可以選擇任意Tracker server。

客戶端帶文件名信息請求Tracker，Tracker從文件名中解析出文件的group、大小、創(chuàng)建時間等信息，然后選擇一個storage用來服務處理請求，返回對應文件。

對應流程圖如下：

如果是基于Web的http請求，此處的Client可以是Nginx代理服務。下面這張圖更加形象的描述了相關的流程。

小結

關于FastDFS的基本特性和原理已經介紹完畢，重點關注三個角色和兩個流程，以及將三個角色融入到兩個流程中進行分析。明白了這個大的方向之后，至于執(zhí)行的細節(jié)部分就可以逐步了解和掌握。

到此這篇關于Java中文件管理系統(tǒng)FastDFS詳解的文章就介紹到這了,更多相關Java文件管理系統(tǒng)FastDFS內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論