1，FastDFS 介紹
FastDFS 是一個 C 語言實現的開源輕量級分佈式文件系統,作者餘慶(happyfish100),支持 Linux、FreeBSD、AID 等 Unix 系統,解決了大數據存儲和讀寫負載均衡等問題,適合存儲 4KB~500MB 之間的小文件,如圖片網站、短視頻網站、文檔、app 下載站等,UC、京東、支付寶、迅雷、酷狗等都有使用,其中 UC 基於 FastDFS 向用戶提供網盤、廣告和應用下載的業務的存儲服務 FastDFS 與 MogileFS、HDFS、TFS 等都不是系統級的分佈式文件系統,而是應用級的分佈式文件存儲服務。
使用FastDFS分佈式文件系統目的：
- 海量存儲，存儲用量方便擴展
- 文件指紋，有高重複使用性
- 結合Nginx提高網站訪問效率
2，FastDFS 架構
FastDFS服務有三個角色:跟蹤服務器(tracker server)、存儲服務器(storage server)和客戶端(client)
tracker server: 跟蹤服務器,主要做調度工作,起到均衡的作用;負責管理所有的 storage server 和 group,每個 storage 在啓動後會連接 Tracker,告知自己所屬 group 等信息,並保持週期性心跳, Tracker根據storage心跳信息,建立group—>[storage server list]的映射表;tracker管理的元數據很少,會直接存放在內存;tracker 上的元信息都是由 storage 彙報的信息生成的,本身不需要持久化任何數據,tracker 之間是對等關係,因此擴展 tracker 服務非常容易,之間增加 tracker服務器即可,所有tracker都接受stroage心跳信息,生成元數據信息來提供讀寫服務(與 其他 Master-Slave 架構的優勢是沒有單點,tracker 也不會成爲瓶頸,最終數據是和一個可用的 Storage Server進行傳輸的)
storage server:存儲服務器,主要提供容量和備份服務;以 group 爲單位,每個 group 內可以包含多臺storage server,數據互爲備份,存儲容量空間以group內容量最小的storage爲準;建 議group內的storage server配置相同;以group爲單位組織存儲能夠方便的進行應用隔離、負載均衡和副本數定製;缺點是 group 的容量受單機存儲容量的限制,同時 group 內機器壞掉,數據 恢復只能依賴 group 內其他機器重新同步(壞盤替換,重新掛載重啓 fdfs_storaged 即可)
多個group之間的存儲方式有3種策略:round robin(輪詢)、load balance(選擇最大剩餘空 間的組上傳文件)、specify group(指定group上傳)
group 中 storage 存儲依賴本地文件系統,storage 可配置多個數據存儲目錄,磁盤不做 raid, 直接分別掛載到多個目錄,將這些目錄配置爲 storage 的數據目錄即可
storage 接受寫請求時,會根據配置好的規則,選擇其中一個存儲目錄來存儲文件;爲避免單 個目錄下的文件過多,storage 第一次啓時,會在每個數據存儲目錄裏創建 2 級子目錄,每級 256 個,總共 65536 個,新寫的文件會以 hash 的方式被路由到其中某個子目錄下,然後將文件數據直 接作爲一個本地文件存儲到該目錄中
總結:1.高可靠性:無單點故障 2.高吞吐性:只要Group足夠多,數據流量是足夠分散的
3，FastDFS 工作流程
上傳
FastDFS 提供基本的文件訪問接口,如 upload、download、append、delete 等
選擇tracker server
集羣中 tracker 之間是對等關係,客戶端在上傳文件時可用任意選擇一個 tracker
選擇存儲 group
當tracker接收到upload file的請求時,會爲該文件分配一個可以存儲文件的group,目前支持選擇 group 的規則爲:
- Round robin,所有 group 輪詢使用
- Specified group,指定某個確定的 group
- Load balance,剩餘存儲空間較多的 group 優先
選擇storage server
當選定group後,tracker會在group內選擇一個storage server給客戶端,目前支持選擇server 的規則爲:
4. Round robin,所有 server 輪詢使用(默認)
5. 根據IP地址進行排序選擇第一個服務器(IP地址最小者)
6. 根據優先級進行排序(上傳優先級由storage server來設置,參數爲upload_priority)
選擇storage path(磁盤或者掛載點)
當分配好storage server後,客戶端將向storage發送寫文件請求,storage會將文件分配一個數據存儲目錄,目前支持選擇存儲路徑的規則爲:
- round robin,輪詢(默認)
- load balance,選擇使用剩餘空間最大的存儲路徑
選擇下載服務器
目前支持的規則爲:
- 輪詢方式,可以下載當前文件的任一storage server
- 從源storage server下載
生成 file_id
選擇存儲目錄後,storage 會生成一個 file_id,採用 Base64 編碼,包含字段包括:storage server ip、文件創建時間、文件大小、文件 CRC32 校驗碼和隨機數;每個存儲目錄下有兩個 256*256 個子目錄,storage 會按文件 file_id 進行兩次 hash,路由到其中一個子目錄,然後將文件以 file_id 爲文件名存儲到該子目錄下,最後生成文件路徑:group 名稱、虛擬磁盤路徑、數據兩級目錄、file_id
其中,
組名:文件上傳後所在的存儲組的名稱,在文件上傳成功後由存儲服務器返回,需要客戶端自行保存
虛擬磁盤路徑:存儲服務器配置的虛擬路徑,與磁盤選項 store_path*參數對應
數據兩級目錄:存儲服務器在每個虛擬磁盤路徑下創建的兩級目錄,用於存儲數據文件
同步機制
-
新增tracker服務器數據同步問題
由於 storage server 上配置了所有的 tracker server. storage server 和 trackerserver 之間的通信是由 storage server 主動發起的,storage server 爲每個 tracker server 啓動一個線程進行通信;在通信過程中,若發現該 tracker server 返回的本組 storage server列表比本機記錄少,就會將該tracker server上沒有的storage server 同步給該 tracker,這樣的機制使得 tracker 之間是對等關係,數據保持一致 -
新增storage服務器數據同步問題
若新增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; -
組內storage數據同步問題
組內storage server之間是對等的,文件上傳、刪除等操作可以在組內任意一臺storageserver 上進行。文件同步只能在同組內的 storage server 之間進行,採用 push 方式, 即源服務器同步到目標服務器
A. 只在同組內的storage server之間進行同步
B. 源數據才需要同步,備份數據不再同步
C. 特例:新增storage server時,由其中一臺將已有所有數據(包括源數據和備份數據)同步到新增服務器
storage server的7種狀態:
通過命令 fdfs_monitor /etc/fdfs/client.conf 可以查看 ip_addr 選項顯示 storage server 當前狀態
INIT : 初始化,尚未得到同步已有數據的源服務器
WAIT_SYNC : 等待同步,已得到同步已有數據的源服務器
SYNCING : 同步中
DELETED : 已刪除,該服務器從本組中摘除
OFFLINE :離線
ONLINE : 在線,尚不能提供服務
ACTIVE : 在線,可以提供服務
組內增加storage serverA狀態變化過程:
- storage server A 主動連接 tracker server,此時 tracker server 將 storageserverA 狀態設置爲 INIT
- storage server A 向 tracker server 詢問追加同步的源服務器和追加同步截止時間點(當前時間),若組內只有storage server A或者上傳文件數爲0,則告訴新機器不需要數據同步,storage server A 狀態設置爲 ONLINE ;若組內沒有 active 狀態機器,就返回錯誤給新機器,新機器睡眠嘗試;否則 tracker 將其狀態設置爲 WAIT_SYNC
- 假如分配了 storage server B 爲同步源服務器和截至時間點,那麼 storage server B會將截至時間點之前的所有數據同步給storage server A,並請求tracker設置 storage server A 狀態爲SYNCING;到了截至時間點後,storage server B向storage server A 的同步將由追加同步切換爲正常 binlog 增量同步,當取不到更多的 binlog 時,請求tracker將storage server A設置爲OFFLINE狀態,此時源同步完成
- storage server B 向 storage server A 同步完所有數據,暫時沒有數據要同步時, storage server B請求tracker server將storage server A的狀態設置爲ONLINE
- 當 storage server A 向 tracker server 發起心跳時,tracker sercer 將其狀態更改爲 ACTIVE,之後就是增量同步(binlog)
註釋:
1.整個源同步過程是源機器啓動一個同步線程,將數據 push 到新機器,最大達到一個磁盤的 IO,不能併發
2.由於源同步截止條件是取不到 binlog,系統繁忙,不斷有新數據寫入的情況,將會導致一直無法完成源同步過程
下載
client 發送下載請求給某個 tracker,必須帶上文件名信息,tracker 從文件名中解析出文件的 group、大小、創建時間等信息,然後爲該請求選擇一個 storage 用於讀請求;由於 group 內的文件同步在後臺是異步進行的,可能出現文件沒有同步到其他storage server上或者延遲的問題, 後面我們在使用 nginx_fastdfs_module 模塊可以很好解決這一問題
文件合併原理
小文件合併存儲主要解決的問題:
- 本地文件系統inode數量有限,存儲小文件的數量受到限制
- 多級目錄+目錄裏很多文件,導致訪問文件的開銷很大(可能導致很多次IO)
- 按小文件存儲,備份和恢復效率低
FastDFS 提供合併存儲功能,默認創建的大文件爲 64MB,然後在該大文件中存儲很多小文件; 大文件中容納一個小文件的空間稱作一個 Slot,規定 Slot 最小值爲 256 字節,最大爲 16MB,即小於 256 字節的文件也要佔用 256 字節,超過 16MB 的文件獨立存儲;
爲了支持文件合併機制,FastDFS生成的文件file_id需要額外增加16個字節;每個trunk file 由一個id唯一標識,trunk file由group內的trunk server負責創建(trunk server是tracker 選出來的),並同步到group內其他的storage,文件存儲合併存儲到trunk file後,根據其文件偏移量就能從trunk file中讀取文件