原本本篇是想介紹前端組件化開發用戶界面,發現框架還未實現文件存儲,本來計劃是後續設計開發的,索性把計劃提早,因此本篇將介紹基於Raft實現分佈式的文件存儲引擎。html
既然是分佈式存儲,就須要解決如下幾個關鍵問題:前端
開始時想設計爲一個集羣對應一個BlobMetaRaftGroup,後來考慮到單個RaftGroup可能會壓力較大,因此改成每一個Application對應一個BlobMetaRaftGroup。每一個元數據狀態機主要存儲如下各項信息:git
確認了須要存儲哪些信息後,就須要確認如何將這些數據映射至底層的KV存儲,既要保證高效又要方便Api檢索這些元數據,通過一些嘗試後最終定爲如下方案。github
TypeFlag | AppId | 目錄名稱UTF8編碼 |
---|---|---|
8bit | 8bit | n bit |
目錄Id | Chunk RaftGroup數量 | Chunk RaftGroupIds |
---|---|---|
128bit | 16bit | n * 64bit |
TypeFlag | AppId | 目錄Guid | 分隔佔位 | 名稱UTF8編碼 |
---|---|---|---|---|
8bit | 8bit | 128bit | 8bit | n bit |
文件Id | 文件大小 | Chunk RaftGroupId |
---|---|---|
128bit | 32bit | 64bit |
根據上述設計,每一個目錄下的文件分紅了多個存儲組(BlobChunkRaftGroup),原本想用MemoryMapFile來實現底層Chunk存儲,但考慮到有更重要的功能要實現因此暫偷懶直接利用Linux文件系統來存儲文件,狀態機Apply文件寫命令時,將文件直接寫入節點運行時blob/ChunkRaftGroupId/目錄下。瀏覽器
根據以上設計在經歷了1個月的編碼後已初步實現(其中約一半時間在更改架構,拋棄了Mono依賴,改成Hosting CoreCLR,性能提高1倍),在框架IDE內每一個Application內有個"BlobStore"節點,以下圖所示可測試上傳文件,而後經過瀏覽器訪問上傳至/pub目錄內的文件(http://{地址:端口}/blob/{app名稱}/{文件路徑} eg: http://xx.xx.xx.xx:5000/blob/sys/imgs/aa.jpg)
緩存
做者簡單測試了一下經過框架WebHost下載文件的性能(測試時還沒有實現緩存元數據, 虛擬機I74C8G),以下圖所示:
架構
本實現適用於存儲大量小文件,如業務單證的附件,或者用於OA系統做爲文檔庫。目前只是實現了基本的上傳下載功能,刪除、重命名、Chunk合併等功能還沒有實現,另待未來框架實現反向索引後再實現全文搜索功能。併發
框架已更新,如何安裝測試請參考AppBoxFuture(一): Hello Future!。若是您有問題或Bug報告,請留言或在Github提交Issue。app