當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

weedfs文件使用记录

發布時間：2024/4/15 编程问答 40 豆豆

生活随笔收集整理的這篇文章主要介紹了 weedfs文件使用记录小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

源碼目錄結構

核心模塊

weed 入口目錄
weed/weed_server 入口目錄與HTTP服務相關
topology 核心模塊，主要包括【DataCenter, Rack, DataNode】三層拓撲結構。
storage 核心模塊，主要包括【Store, Volume, Needle】這三大塊存儲相關的源碼。

輔助模塊

sequence 負責FileID的全局有序生成
filer 提供支持 HTTP REST 操作的文件服務器，其實就是基于 leveldb 把文件名和目錄結構存儲起來。
stats 和操作系統內存和磁盤使用狀況有關的模塊
operation 由protobuf生成的代碼們
proto 存放protobuf的描述文件
glog 日志模塊
images 圖片服務
util 工具函數
tools 工具，暫時只有一個讀索引的文件。

多數據節點維護之 Topology

topology 整個模塊最核心的數據結構是三個：

DataCenter
Rack
DataNode

topology 是樹狀結構，DataNode 是樹的葉子節點， DataCenter 和 Rack 是樹的非葉子節點， DataCenter 是 Rack 的父母節點。如下圖

DataCenter | | ------------------ | | | | Rack Rack | | ------------ | | | | DataNode DataNode

也就是在 MasterServer 維護的拓撲結構里，是把 VolumeServer 的相關信息存儲在 DataNode 里，所以在代碼里面可以看到如下：

dc := t.GetOrCreateDataCenter(dcName) rack := dc.GetOrCreateRack(rackName) dn := rack.FindDataNode(*joinMessage.Ip, int(*joinMessage.Port))

每次查找對應的DataNode，都需要從 DataCenter -> Rack -> DataNode 依次找下去。

數據存儲

理解Fid

curl -F "file=@/tmp/test.pdf" "127.0.0.1:9333/submit" {"fid":"1,01f96b93eb","fileName":"test.pdf","fileUrl":"localhost:8081/1,01f96b93eb","size":548840}

其中?"fid":"1,01f96b93eb"?就是 Fid，Fid 由三個部分組成【VolumeId, NeedleId, Cookie】組成。

VolumeId: 1 32bit 存儲的物理卷的Id?
NeedleId: 01 64bit 全局唯一NeedleId，每個存儲的文件都不一樣(除了互為備份的)。
Cookie: f96b93eb 32bit Cookie值，為了安全起見，防止惡意攻擊。

其中 VolumeId 是由 MasterServer 分配給 VolumeServer，每個 VolumeServer 都維護個 n 個 Volume ，每個 Volume 都有一個專屬 VolumeId，之后會細說。 Needle 屬于 Volume 里面的一個單元，后續說。

Volume

type Volume struct { Id VolumeId dir string Collection string dataFile *os.File nm NeedleMapper readOnly bool SuperBlock accessLock sync.Mutex lastModifiedTime uint64 //unix time in seconds }

VolumeId 通俗易懂，比如?"fid":"3,01f9896771"?里面逗號前面的 3 就是 VolumeId 。
dir 就是該 Volume 所在的目錄，
Collection 很有用，每個 Volume 只能對應同一個 Collection，不同 Collection 的圖片存儲在不同 Volume，后面會講到。
所以同一個 Volume 只能針對某一個 Collection ，而同一個 Collection 的圖片可能分布在不同的 Volume。 dataFile 就是對應的文件句柄。
nm NeedleMapper 看上去像是個 map ，其實是個列表，包含多個 Needle ，后面會講到。
readOnly 是否只讀
SuperBlock 超塊，后面會講到。
accessLock 互斥鎖
lastModifiedTime 最近修改時間

以上最關鍵的兩個點就是 SuperBlock 和 NeedleMapper ，這兩者在文件中布局如下：

+-------------+ |SuperBlock | +-------------+ |Needle1 | +-------------+ |Needle2 | +-------------+ |Needle3 | +-------------+ |Needle ... | +-------------+ Volume = 1 SuperBlock + n Needle

SuperBlock

/* * Super block currently has 8 bytes allocated for each volume. * Byte 0: version, 1 or 2 * Byte 1: Replica Placement strategy, 000, 001, 002, 010, etc * Byte 2 and byte 3: Time to live. See TTL for definition * Rest bytes: Reserved */ type SuperBlock struct { version Version ReplicaPlacement *ReplicaPlacement Ttl *TTL }

SuperBlock 內維護的數據基本上就是該 Volume 的元數據。

ReplicaPlacement : 在后面的 Replication 會講
Ttl :Time To Live 為了定時刪除的功能

【TTL】

定時刪除功能，這個感覺很酷炫，但是在Seaweedfs里面的實現原理很簡單，按 Volume 來進行分塊，當每次用戶上傳一個自帶TTL的文件（需要定時刪除的文件）時，會把這個文件存儲在合適的 Volume 里面（如何選出合適的 Volume 之后再說），存儲的時候每個文件會帶有 TTL 這個屬性，當讀取出來之后發現該文件已經過期（超時時間到），則會返回一個 Not Found 結果，而每個 Volume 維護一個最大超時時間，當這個時間抵達時，說明整個 Volume 所有的文件都超時了，然后 VolumeServer 通知 MasterServer 這個 Volume 已經被標識為 Dead 狀態，意味著 MasterServer 不會再為這個 Volume 分配新的 Fid。然后再經過一段合適的時間后由 VolumeServer 將這個 Volume 從磁盤上安全的刪除掉。詳細請看在?Seaweedfs?自帶的文檔?ttl?，

Needle

/* * A Needle means a uploaded and stored file. * Needle file size is limited to 4GB for now. */ type Needle struct { Cookie uint32 `comment:"random number to mitigate brute force lookups"` Id uint64 `comment:"needle id"` Size uint32 `comment:"sum of DataSize,Data,NameSize,Name,MimeSize,Mime"` Data []byte `comment:"The actual file data"` DataSize uint32 `comment:"Data size"` //version2 Flags byte `comment:"boolean flags"` //version2 NameSize uint8 //version2 Name []byte `comment:"maximum 256 characters"` //version2 MimeSize uint8 //version2 Mime []byte `comment:"maximum 256 characters"` //version2 LastModified uint64 //only store LastModifiedBytesLength bytes, which is 5 bytes to disk Ttl *TTL Checksum CRC `comment:"CRC32 to check integrity"` Padding []byte `comment:"Aligned to 8 bytes"` }

Needle 結構體里面的 Cookie 和 Id 就是上文提過的 Fid 里面的 Cookie 和 NeedleId，其他就是一些存儲相關的變量，沒什么奇淫巧計。就是簡單的存儲結構而已。

數據備份之 Replication

Replication 和 Topology 嚴重相關，在配置文件中可以配置多種備份模式，詳見?seaweedfs-wiki?。

+-----+---------------------------------------------------------------------------+ |001 |replicate once on the same rack | +-----+---------------------------------------------------------------------------+ |010 |replicate once on a different rack in the same data center | +-----+---------------------------------------------------------------------------+ |100 |replicate once on a different data center | +-----+---------------------------------------------------------------------------+ |200 |replicate twice on two other different data center | +-----+---------------------------------------------------------------------------+

比如在 001 模式，即在同一個 rack 中的不同 DataNode 中備份一份。假設在 rack1 中含有 DataNode1, DataNode2, DataNode3 三個數據節點中【隨機】選出兩個數據節點，比如選出 DataNode1, DataNode2 然后同時寫入這兩個數據節點。假設 rack1 只有一個數據節點的時候，而備份模式是 001 模式，則無法正常備份，服務會報錯。

注意到，選擇備份數據節點的方法是【隨機】，所以就會出現從三個數據節點中隨機選擇兩個的情況下，

curl -v -F "file=@/tmp/test.json" localhost:8081/5,1ce2111f1

topo.NextVolumeId 負責生成 VolumeId ，負責在 VolumeGrowth 里的時候分配 Volume 的時候，生成一個全局唯一的新 VolumeId，在 Weed-fs 中，是支持多 MasterServer 集群的。當有多個 MasterServer，生成一個全局唯一的新 VolumeId 是很重要，在 Weed-fs 中是通過?goraft?來實現的。

【強一致性】

Seaweedfs 的備份實現是強一致性的。當一個 VolumeServer 接受到上傳文件的 POST 請求時，將該文件作為一個 Needle 寫入本地 Volume 之后，會根據該文件所分配的 VolumeId 判斷是否需要備份，如果需要備份，則進行備份（需要請求另外其它的 VolumeServer 服務器）。過程詳見?ReplicatedWrite?(topology/store_replicate.go)。當備份完畢后，再對該 POST 請求進行答復。所以用戶每次上傳圖片時，當收到了答復之后，則可以認為此備份已完成。這個和最終一致性不同，屬于強一致性。

上述實現強一致性的過程中，有個必要條件就是【 VolumeServer 需要知道往其它那些 VolumeServer 備份】。在 Seaweedfs 的實現中是借助 MasterServer 來實現，因為備份的基本單位是 Volume, 在 MasterServer 中，對每個 VolumeId 都維護對應的備份機器列表。可以通過如下示例命令查看:

curl "localhost:9333/dir/lookup?volumeId=4&pretty=y" { "volumeId": "4", "locations": [ { "url": "127.0.0.1:8081", "publicUrl": "localhost:8081" }, { "url": "127.0.0.1:8080", "publicUrl": "localhost:8080" } ] }

如上示例中可以看出，對應的 volumeId=4 的 Volume, 可以看出對應的備份機器列表有兩臺，分別是 "127.0.0.1:8081" 和 "127.0.0.1:8080" 。

實際上對于每臺 VolumeServer 查找其它備份機器的時候，也是通過如上 HTTP api 向 MasterServer 詢問。只不過不是每次都詢問，因為只要詢問過了之后就會緩存下來，只有在緩存里面找不到才詢問。

【Collection】

示例如下：

啟動 MasterServer

weed master

啟動 VolumeServer

weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080

申請Fid

curl "http://127.0.0.1:9333/dir/assign?collection=pictures" {"fid":"4,01d50c6fbf","url":"127.0.0.1:8080","publicUrl":"localhost:8080","count":1} curl "http://127.0.0.1:9333/dir/assign?collection=mp3" {"error":"No free volumes left!"} curl "http://127.0.0.1:9333/dir/assign?collection=pictures" {"fid":"5,0147ed0fb7","url":"127.0.0.1:8080","publicUrl":"localhost:8080","count":1}

申請Fid的示例解釋：

因為默認情況下，VolumeServer 啟動時，未申請任何 Volume，當第一次?/dir/assign?的時候，會分配 Volume，因為?weed volume?的參數?-max=5?所以一次性分配 5 個 Volume ，并且這 5 個 Volume 的 Collection 屬性都是 pictures，甚至可以看到在?ls?/tmp/data1?的結果如下：

/tmp/data1 pictures_1.dat pictures_1.idx pictures_2.dat pictures_2.idx pictures_3.dat pictures_3.idx pictures_4.dat pictures_4.idx pictures_5.dat pictures_5.idx

可以看出每個卷的文件名以 Collection 來命名。

2. 因為已有的 5 個 Volume 的 Collection 屬性都是 pictures，所以此時如果需要?/dir/assign?一個非 pictures Collection 的 Fid 時失敗，

3. 當申請一個屬于 pictures Collection 的 Fid 成功。

也就是在每次申請 Fid 時，會針對 Collection 進行檢查，來保證存入 Volume 的每個 Needle 所屬的 Collection 一致。在實際應用中可以通過 Collection 來類別的分片。

【Volume 的大小限制】

在每次 VolumeServer 向 MasterServer 發送心跳信息的時候，會在 storage.VolumeInfo.Size 里面注明當前 Volume 的大小信息(Size)。所以可以以此來限制 Volume 的大小。如下函數：

func (vl *VolumeLayout) isWritable(v *storage.VolumeInfo) bool { return uint64(v.Size) < vl.volumeSizeLimit && v.Version == storage.CurrentVersion && !v.ReadOnly }

當 VolumeInfo.Size 大于 VolumeLayout.volumeSizeLimit 時，則將該 Volume 標記為不可寫。而 VolumeLayout.volumeSizeLimit 的值可以在啟動 MasterServer 的時候配置。由?weed help master?可知：

-volumeSizeLimitMB=30000: Master stops directing writes to oversized volumes.

每個 Volume 的最大 Size 默認是 30G , 而每個 VolumeServer 可以配置 n 個 Volume，根據所在機器不同的硬盤大小配置不同的 n . 由?weed help volume?可知：

-max="7": maximum numbers of volumes, count[,count]...

每個 VolumeServer 默認的 Volume 大小是 7 。

所以默認情況下，當一個 VolumeServer 使用的磁盤超過 7 * 30G = 210G 之后，該 VolumeServer 屬于只讀狀態， MasterServer 不會再分配新的 Fid 給它。

但是其實這里會有漏洞，如果此時不通過請求 MasterServer 獲取 Fid，而是直接自己構造 Fid 向 VolumeServer POST 文件的話， VolumeServer 還是會一直接受上傳的文件，直到大小超過在storage/needle.go?里面寫死的一個常量：

MaxPossibleVolumeSize = 4 * 1024 * 1024 * 1024 * 8

其實在 VolumeServer 里面也有維護一個變量叫 volumeSizeLimit ，

type Store struct { ... volumeSizeLimit uint64 //read from the master ... }

此變量的值是從 MasterServer 獲取的，當每次 VolumeServer 寫入 Needle 到 Volume 的時候，都會檢查 Volume Size 是否超過 volumeSizeLimit , 當超過的時候會打錯誤日志，但是不會停止寫入，也就是不會拒絕上傳的文件。?有且只有?當大小超過 MaxPossibleVolumeSize 的時候才會拒絕寫入磁盤。

【擴容】

對于 Seaweedfs 來說，擴容非常簡單，

啟動 MasterServer:

./weed master -mdir="/tmp/weed_master_tmp"

啟動 VolumeServer1:

weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080

當 VolumeServer1 因為抵達 Volume 大小上限而無法繼續接受上傳數據時，此時繼續 submit 上傳數據 MasterServer 則會返回錯誤(因為在 MasterServer 內已經將 VolumeServer1 標記為不可寫)。

curl -F "file=@/tmp/test.pdf" "127.0.0.1:9333/submit" {"error":"No free volumes left!"}

此時直接再啟動 VolumeServer2 即可

weed volume -dir="/tmp/data2" -max=5 -mserver="localhost:9333" -port=8081

此時 VolumeServer2 啟動之后會自動向 MasterServer 的 Topology 結構注冊新的 DataNode , 當 MasterServer 接受到新的 submit 請求的時候，會將該上傳文件寫入 VolumeServer2 （因為此時 VolumeServer1 已經不可寫）。

也就是說如果當線上出現容量問題的時候，擴容只需要加機器即可，簡單有效。

總結

每個 MasterServer 通過 Topology 維護多個 VolumeServer 。
每個 VolumeServer 維護多個 Volume 。
每個 Volume 包含多個 Needle ，Needle 即文件。
多臺 VolumeServer 之間的多機備份實現是強一致性。
多臺 MasterServer 之間的主從關系是是通過?goraft?實現。
1.架構

我們先了解一個概念：見附錄

一個master：

作為cluster管理一個DataCenter名叫imgdatacenter1（抽象的概念）；
imgdatacenter1包含一個機柜 rack名叫imgrack1（抽象的概念）；
imgrack1機柜里面有一個DataNode名叫datanode1（可以認為DataNode是一個volume server ）；

?
cd /home1/seaweeddir //這是我的測試目錄，你這里選擇你自己的目錄 mkdir {mtmp,vtmp1,vtmp2,ftmp,mountdir} //大括號內千萬別多空格，否則會出現問題 weed master -ip=localhost -port=9333 -mdir=./mtmp (mtmp是你自定義的保存生成的序列文件id的文件夾)
一個DataNode：（datanode1只是抽象的名字沒有實質的代碼賦值，下面通過地址來區分DataNode）

就是上面的datanode1，定義里面有10個volume，collection不先設置，DataCenter和rack都用下面的指令指定：

?
weed volume -dataCenter=imgdatacenter1 -rack=imgrack1 -ip=localhost -port=9991 -dir=./vtmp1 -max=10 -mserver=localhost:9333
此時就在名為imgdatacenter1的dataCenter中的名為imgrack1的rack里添加了一個地址為localhost:9991的volume server。

一個filer服務器

?
weed scaffold -config=filer -output=. //先生成filer.toml文件
默認使用leveldb保存映射關系，打開filer.toml文件修改保存映射文件的文件夾為ftmp（自定義）

?

image.png

?

然后啟動filer服務

?
weed filer -ip=localhost -port=8888 -master=localhost:9333
本地映射filer

mountdir 是本地任意目錄，filer.path后面跟你想映射的filer中的目錄，可以直接映射根目錄。

?
sudo weed mount -filer=localhost:8888 -dir=/home1/seaweeddir/mountdir -filer.path=/ //sudo weed mount -filer=localhost:8888 -dir=~/folder_on_seaweedfs -filer.path=/home/chris -collection=chris
關閉掛在需要關閉mount并且手動umont ~/mdir目錄，如果一般用戶失敗請使用root用戶

2.驗證

我們驗證下我們的服務啟動狀態，
此時有一個DataCenters名為imgdatacenter1，一個Racks名為imgrack1，一個DataNodes地址是localhost:9991，且該DataNode的Volumes個數為0，等我們新增文件的時候就會發現volumes個數才會增加

?
//這種返回表示master啟動成功且作為了leader curl "http://localhost:9333/cluster/status?pretty=y" {"IsLeader": true,"Leader": "localhost:9333" }//此時有一個DataCenters名為imgdatacenter1，一個Racks名為imgrack1，一個DataNodes地址是localhost:9991，且該DataNode的Volumes個數為0 curl "http://localhost:9333/dir/status?pretty=y" {"Topology": {"DataCenters": [{"Free": 10,"Id": "imgdatacenter1","Max": 10,"Racks": [{"DataNodes": [{"Free": 10,"Max": 10,"PublicUrl": "localhost:9991","Url": "localhost:9991","Volumes": 0}],"Free": 10,"Id": "imgrack1","Max": 10}]}],"Free": 10,"Max": 10,"layouts": null},"Version": "1.10" }
本地操作的方式往服務器新增一個文件

?
cd /home1/image/mountdir cp /home1/image/1.jpg ./
我們查看下系統狀態，（詳細數據參見附錄：上傳文件后的系統狀態）
此時我們發現地址為localhost:9991的datanode的Volumes數量變成了7個，說明當前新增了7個volume，因為我們之前設置的volume最大個數時10，所有最多還能再新增3個volume。
我們再看layouts，發現已經不是之前的null了，而是出現了一個名為""的collection，有七個可以寫的volume。
這是因為如果我們沒有指定collection的時候，默認所有數據都保存在名為""的collection中

我們查看下文件上傳后volumeserver的狀態
我們發現id為4的volume的filecount為1，說明該文件上傳到了這里。

我們你再看下filer的狀態
多了個1.jpg文件

我們再看下我們的掛載目錄

?
ls /home1/seaweeddir/mountdir/ 1.jpg
此時說明我們上傳文件就成功了

此時我們可以操作本地文件系統中的目錄/home1/seaweeddir/mountdir，來操作我們的圖片服務器。
然而批量操作本地文件系統的mount文件夾時不是并發的，需要經過fuse層，要想并發操作就需要直接操作filer服務。

通過filer服務器做一些文件操作

使用命令上傳

?
curl -F file=@report.js "http://localhost:8888/javascript/new_name.js" # upload the file with a different name
本地批量上傳文件

使用weed filer.copy file_or_dir1 [file_or_dir2 file_or_dir3] http://localhost:8888/path/to/a/folder/ （多線程且繞過fuse層）
我在本地/home1/image/staff 下有大量的圖片，這里上傳到filer服務器的mystaff下，我們查看/home1/seaweeddir/mountdir/下，會發現多了個staff目錄，且目錄下也全部拷貝了圖片。

?
weed filer.copy /home1/image/staff http://localhost:8888/mystaff
刪除文件

?
curl -X DELETE http://localhost:8888/path/to/file
刪除文件夾

?
curl -X DELETE http://localhost:8888/path/to/dir?recursive=true
一些注意事項

1.關閉volume mount時需要手動sudo mount -l /home1/seaweeddir/mountdir目錄，否則該目錄會導致終端卡死。
2.刪除操作不會馬上清空磁盤，要想實時清空未使用的空間，請執行
curl "http://localhost:9333/vol/vacuum"

使用fid操作文件在filer的顯示

?
curl http://localhost:9333/dir/assign {"fid":"7,03a0146c8ac8","url":"localhost:9991","publicUrl":"localhost:9991","count":1}curl -F file=@/home1/image/1.jpg http://localhost:9991/7,03a0146c8ac8 //在filer中找不到,因為filer服務沒有保存映射關系，所有想使用filer，就得使用filer上傳文件，否則只能通過fid獲取信息。 curl -F file=@/home1/image/1.jpg "http://localhost:8888/javascript/2.jpg"//在filer的javascript目錄下多了個2.jpgweed download -server="localhost:9333" -dir="D:\data3" 4,012d48fa67 //可以通過fid下載文件
結尾

到這里一個圖片服務器就搭建起來了，
真正要熟悉使用seaweedfs需要仔細閱讀官方wiki，并且查看源碼和實現依賴的論文來了解實現原理。
剩余的像數據備份，服務器云備份等請看官網wiki：
https://github.com/chrislusf/seaweedfs/wiki/Failover-Master-Server
https://github.com/chrislusf/seaweedfs/wiki/Amazon-S3-API
https://github.com/chrislusf/seaweedfs/wiki/Async-Replication-to-another-Filer

總結

?
cd /home1/seaweeddir mkdir {mtmp,vtmp1,vtmp2,ftmp,mountdir} weed scaffold -config=filer -output=. vim filer.toml (修改leveldb的dir為"./ftmp") weed master -ip=localhost -port=9333 -mdir=./mtmp weed volume -dataCenter=imgdatacenter1 -rack=imgrack1 -ip=localhost -port=9991 -dir=./vtmp1 -max=10 -mserver=localhost:9333 weed filer -ip=localhost -port=8888 -master=localhost:9333 -collection=test sudo weed mount -filer=localhost:8888 -dir=/home1/seaweeddir/mountdir -filer.path=/ -collection=test //關閉服務后執行 sudo umount -l /home1/seaweeddir/mountdir 取消掛載 //此時就可以使用filer通過web操作文件了，而且也可以通過/home1/seaweeddir/mountdir本地操作文件了。 //或者這么理解，sudo weed mount只能用sudo umount -l 取消掛載，而不是直接kill進程。
附錄：

其他上傳下載的命令

?
weed upload -master=localhost:9333 file1 [file2 file3] weed upload -master=localhost:9333 -dir=one_directory -include=*.pdf
?
//指定幾個fid下載到本地one_directory中 weed download -server=localhost:9333 -dir=one_directory fid1 [fid2 fid3 ...]
?
//導出id為7的volume到/dir/name.tar，/tmp是volume保存的地址，只導出比2006-01-02T15:04:05新的文件 weed export -dir=/tmp -volumeId=7 -o=/home1/seaweeddir/exp2/name.tar -fileNameFormat={{.Name}} -newer='2006-01-02T15:04:05'
一些概念

1.topology 是樹狀結構，DataNode 是樹的葉子節點， DataCenter 和 Rack 是樹的非葉子節點， DataCenter 是 Rack 的父母節點。
2.在 MasterServer 維護的拓撲結構里，是把 VolumeServer 的相關信息存儲在 DataNode 里,每次查找對應的DataNode，都需要從 DataCenter -> Rack -> DataNode 依次找下去。
3."fid":"1,01f96b93eb" 就是 Fid，Fid 由三個部分組成【VolumeId, NeedleId, Cookie】組成

?
VolumeId: 1 32bit 存儲的物理卷的Id NeedleId: 01 64bit 全局唯一NeedleId，每個存儲的文件都不一樣(除了互為備份的)。Cookie: f96b93eb 32bit Cookie值，為了安全起見，防止惡意攻擊
4.VolumeId 是由 MasterServer 分配給 VolumeServer，每個 VolumeServer 都維護個 n 個 Volume ，每個Volume 都有一個專屬 VolumeId，之后會細說。 Needle 屬于 Volume 里面的一個單元
5.dir 就是該 Volume 所在的目錄，
6.Collection 很有用，每個 Volume 只能對應同一個 Collection，不同 Collection 的圖片存儲在不同 Volume，所以同一個 Volume 只能針對某一個 Collection ，而同一個 Collection 的圖片可能分布在不同的 Volume
7.Replication 和 Topology 嚴重相關,比如在 001 模式，即在同一個 rack 中的不同 DataNode 中備份一份。假設在 rack1 中含有 DataNode1, DataNode2, DataNode3 三個數據節點中【隨機】選出兩個數據節點，比如選出 DataNode1, DataNode2 然后同時寫入這兩個數據節點。假設 rack1 只有一個數據節點的時候，而備份模式是 001 模式，則無法正常備份，服務會報錯。
8.VolumeServer 啟動時，未申請任何 Volume，當第一次 /dir/assign 的時候，會分配 Volume
9.每個 VolumeServer 默認的 Volume 大小是 7 。默認情況下，當一個 VolumeServer 使用的磁盤超過 7 *30G = 210G 之后，該 VolumeServer 屬于只讀狀態， MasterServer 不會再分配新的 Fid 給它。
10.每個 MasterServer 通過 Topology 維護多個 VolumeServer 。
11.每個 VolumeServer 維護多個 Volume 。
12.每個 Volume 包含多個 Needle ，Needle 即文件。
13.多臺 VolumeServer 之間的多機備份實現是強一致性。
14.多臺 MasterServer 之間的主從關系是是通過 goraft 實現。

collection的說明

如果我們沒有指定collection的時候，默認所有數據都保存在名為""的collection中，
0.按照collection刪除

?
Delete Collection curl "http://localhost:9333/col/delete?collection=xxx&pretty=y"
1.預申請volume的時候指定collection

?
//預申請4個屬于名為turbo的collection 的volume curl "http://localhost:9333/vol/grow?collection=turbo&count=4"
2.添加filer時指定collection

?
//此時所有通過filer新增的數據都在名為myfiler的collection中 weed filer -ip=localhost -port=8888 -master=localhost:9333 -collection=myfiler
mount時指定collection
?
//只掛在指定collection weed mount -filer=localhost:8888 -dir=~/folder_on_seaweedfs -filer.path=/home/chris -collection=chris
4.其他

?
curl "http://127.0.0.1:9333/dir/assign?collection=pictures" curl -F @file=./hello1.txt http://10.0.40.58:9333/submit?collection=test_crash weed upload -collection myfiles -master=localhost:9333 XXX.txt
上傳文件后的系統狀態

?
curl "http://localhost:9333/dir/status?pretty=y" {"Topology": {"DataCenters": [{"Free": 3,"Id": "imgdatacenter1","Max": 10,"Racks": [{"DataNodes": [{"Free": 3,"Max": 10,"PublicUrl": "localhost:9991","Url": "localhost:9991","Volumes": 7}],"Free": 3,"Id": "imgrack1","Max": 10}]}],"Free": 3,"Max": 10,"layouts": [{"collection": "","replication": "000","ttl": "","writables": [1,2,3,4,5,6,7]}]},"Version": "1.10" }
我們查看下文件上傳后volumeserver的狀態
我們發現id為4的volume的filecount為1，說明該文件上傳到了這里。

?
curl "http://localhost:9991/status?pretty=y" {"Version": "1.10","Volumes": [{"Id": 1,"Size": 0,"ReplicaPlacement": {"SameRackCount": 0,"DiffRackCount": 0,"DiffDataCenterCount": 0},"Ttl": {},"Collection": "","Version": 3,"FileCount": 0,"DeleteCount": 0,"DeletedByteCount": 0,"ReadOnly": false},{"Id": 2,"Size": 0,"ReplicaPlacement": {"SameRackCount": 0,"DiffRackCount": 0,"DiffDataCenterCount": 0},"Ttl": {},"Collection": "","Version": 3,"FileCount": 0,"DeleteCount": 0,"DeletedByteCount": 0,"ReadOnly": false},{"Id": 3,"Size": 0,"ReplicaPlacement": {"SameRackCount": 0,"DiffRackCount": 0,"DiffDataCenterCount": 0},"Ttl": {},"Collection": "","Version": 3,"FileCount": 0,"DeleteCount": 0,"DeletedByteCount": 0,"ReadOnly": false},{"Id": 4,"Size": 77285,"ReplicaPlacement": {"SameRackCount": 0,"DiffRackCount": 0,"DiffDataCenterCount": 0},"Ttl": {},"Collection": "","Version": 3,"FileCount": 1,"DeleteCount": 0,"DeletedByteCount": 0,"ReadOnly": false},{"Id": 5,"Size": 0,"ReplicaPlacement": {"SameRackCount": 0,"DiffRackCount": 0,"DiffDataCenterCount": 0},"Ttl": {},"Collection": "","Version": 3,"FileCount": 0,"DeleteCount": 0,"DeletedByteCount": 0,"ReadOnly": false},{"Id": 6,"Size": 0,"ReplicaPlacement": {"SameRackCount": 0,"DiffRackCount": 0,"DiffDataCenterCount": 0},"Ttl": {},"Collection": "","Version": 3,"FileCount": 0,"DeleteCount": 0,"DeletedByteCount": 0,"ReadOnly": false},{"Id": 7,"Size": 0,"ReplicaPlacement": {"SameRackCount": 0,"DiffRackCount": 0,"DiffDataCenterCount": 0},"Ttl": {},"Collection": "","Version": 3,"FileCount": 0,"DeleteCount": 0,"DeletedByteCount": 0,"ReadOnly": false}] }
我們你再看下filer的狀態
多了個1.jpg文件

?
curl -H "Accept: application/json" "http://localhost:8888/?pretty=y" {"Path": "","Entries": [{"FullPath": "/1.jpg","Mtime": "2018-12-18T10:38:18+08:00","Crtime": "2018-12-18T10:38:18+08:00","Mode": 436,"Uid": 1000,"Gid": 1000,"Mime": "image/jpeg","Replication": "","Collection": "","TtlSec": 0,"chunks": [{"file_id": "4,0189b08312","size": 77244,"mtime": 1545100698715493243,"e_tag": "32f4abc5"}]}],"Limit": 100,"LastFileName": "1.jpg","ShouldDisplayLoadMore": false }
我們再看下我們的掛載目錄

?
ls /home1/seaweeddir/mountdir/ 1.jpg

?

總結

以上是生活随笔為你收集整理的weedfs文件使用记录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： kong 网关日志格式修改
下一篇： ActiveMQ持久化到mysql