SeaWeedfs最初是作爲一個對象存儲來有效地處理小文件的。central master不管理central master中的所有文件元數據，而只管理文件卷，它通過這些volume servers管理文件及其元數據。這減輕了來自central master的併發壓力，並將文件元數據分散到卷服務器中，從而允許更快的文件訪問（O（1），通常只有一個磁盤讀取操作）。每個文件的元數據只有40字節的磁盤存儲開銷。
架構
官網描述：
Usually distributed file systems split each file into chunks, a central master keeps a mapping of filenames, chunk indices to chunk handles, and also which chunks each chunk server has.
The main drawback is that the central master can’t handle many small files efficiently, and since all read requests need to go through the chunk master, so it might not scale well for many concurrent users.
Instead of managing chunks, SeaweedFS manages data volumes in the master server. Each data volume is 32GB in size, and can hold a lot of files. And each storage node can have many data volumes. So the master node only needs to store the metadata about the volumes, which is a fairly small amount of data and is generally stable…
seaWeedFs的文件存儲的基本結構如上，我們從下往上看
數據卷：也就是是類似我們windowspan的D,E盤等物理磁盤，文件保存的物理介質。默認32GB，通過修改代碼可以修改爲64GB或者128GB,每個文件的最大不超過單個卷的大小。
官網描述：In the current implementation, each volume can hold 32 gibibytes (32GiB or 8x2^32 bytes). This is because we align content to 8 bytes. We can easily increase this to 64GiB, or 128GiB, or more, by changing 2 lines of code, at the cost of some wasted padding space due to alignment.
There can be 4 gibibytes (4GiB or 2^32 bytes) of volumes. So the total system size is 8 x 4GiB x 4GiB which is 128 exbibytes (128EiB or 2^67 bytes).
Each individual file size is limited to the volume size.
數據卷服務器：爲了更方便的管理數據卷，通過該服務來對多個數據捲進行管理。其中，數據卷服務器保存了文件元數據，通過訪問文件元數據就可以操作數據卷中的文件。從官網中我們瞭解到文件的元數據只有16字節大小。【文件句柄：表示文件對象的一個便於使用的引用】
官網描述：The actual data is stored in volumes on storage nodes. One volume server can have multiple volumes, and can both support read and write access with basic authentication. 一個卷服務對應多個卷
The actual file metadata is stored in each volume on volume servers. Since each volume server only manages metadata of files on its own disk, with only 16 bytes for each file, all file access can read file metadata just from memory and only needs one disk operation to actually read file data.每個文件的元數據16字節大小，Linux中中XFS結構中爲536/8（67）字節。
For comparison, consider that an xfs inode structure in Linux is 536 bytes
主控服務器：爲了便於對多個數據卷服務器進行統一的調度（增加，刪除，查找，定位等等操作），邏輯上抽象出一個主控服務器對整個DFS(分佈式文件系統)進行統一管理。其中，主控服務器自然就管理着數據卷服務器的元數據信息（數據卷的元數據），相當於間接管理了文件信息。
官網描述：All volumes are managed by a master server. The master server contains the volume id to volume server mapping. This is fairly static information, and can be easily cached.
架構的好處：
*The actual data is stored in volumes on storage nodes. One volume server can have multiple volumes, and can both support read and write access with basic authentication.*實際數據保存在存儲節點（數據卷）中，一個卷服務管理多個卷，同時支持帶有基本認證功能的讀寫操作。提高讀寫訪問的併發功能。
基本原理
具體的核心原理可參考facebook的一片文章《Finding a needle in Haystack: Facebook’s photo storage》
存儲在磁盤中的文件，得以快速讀寫基礎是，得益於Append-Only的數據存儲方式，文件的上傳操作只是在特定磁盤位置追加文件數據，類似與kafka的消息存儲結構和Redis的AOF數據恢復方式使用的數據接口。
基本使用
基本環境搭建
master服務
./weed master
卷服務
> weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080 &
> weed volume -dir="/tmp/data2" -max=10 -mserver="localhost:9333" -port=8081 &
By default, the master node runs on port 9333, and the volume nodes run on port 8080. Let’s start one master node, and two volume nodes on port 8080 and 8081. Ideally, they should be started from different machines. We’ll use localhost as an example.
SeaweedFS uses HTTP REST operations to read, write, and delete. The responses are in JSON or JSONP format.
SeaWeedFS提供了一個HTTTREST形式的接口，我們通過HTTP客戶端就可以完成對文件的讀寫操作。
上傳文件（Write File）
從master服務中獲取文件將要存放的卷服務，以及文件的唯一標示信息，至於文件最後被保存在磁盤的哪裏，由卷服務自行決定。
To upload a file: first, send a HTTP POST, PUT, or GET request to /dir/assign to get an fid and a volume server url:
> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
Second, to store the file content, send a HTTP multi-part POST request to url + ‘/’ + fid from the response:
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
修改文件（Write File）
To update, send another POST request with updated file content.
修改文件和上傳文件類似，同一個URL不同的是文件不同罷了！
刪除文件（Write File）
For deletion, send an HTTP DELETE request to the same url + ‘/’ + fid URL:
刪除文件和上傳文件類似，訪問對應的URL，採用DELETE Method即可
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
查看文件（Read File）
首先，找到對應的卷服務訪問地址
First look up the volume server’s URLs by the file’s volumeId:
> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}
因爲（通常）卷服務器不會太多，而且卷也不經常移動，所以在大多數時間緩存結果。根據複製類型，一個卷可以有多個副本位置。隨便挑一個地方讀。
第二步：現在可以獲取公共url、呈現url或通過url直接從卷服務器讀取：
Now you can take the public url, render the url or directly read from the volume server via url:
http://localhost:8080/3,01637037d6.jpg
Notice we add a file extension “.jpg” here. It’s optional and just one way for the client to specify the file content type.
寫不寫擴展名取決於自身的需求，可以參考官網
的描述信息。
文件ID含義解析：
"fid":"3,01637037d6"
開頭的數字3表示卷id，卷id是一個無符號的32bit整數
逗號之後是一個文件密鑰01，文件密鑰是一個無符號的64bit整數；
隨後是一個文件cookie 637037d6，是一個無符號的32bit整數，用於防止URL猜測。文件密鑰和文件cookie都是十六進制編碼的。
通過訪問master服務獲得了fid，根據需要可以將fid 301637037d6保存到不同的存儲服務中（REDIS,MYSQL,TEXT等等）。可以按照自己的格式存儲<volume id，file key，file cookie>元組，或者將fid簡單地存儲爲字符串。
如果作爲字符串存儲，理論上，您需要8+1+16+8=33個字節。一個char（33）就足夠了，如果不夠的話，因爲大多數使用不需要2^32個卷。
如果真的需要空間，可以用自己的格式存儲文件id。卷id需要一個4字節整數，文件密鑰需要8字節長的數字，文件cookie需要一個4字節整數。所以16個字節就足夠了。