項目地址：https://code.google.com/p/weed-fs/
weed-fs是一個簡單且高性能的分佈式存儲系統， 它有兩個目標：
1、存儲海量文件 2、快速訪問所存的文件
weed-fs選擇了 key~file 映射的方式實現文件尋址， 而不是POSIX文件系統已有的機制， 這有點類似於nosql系統， 你可以稱之爲“NoFS”
weed-fs的實現機制是管理volumes服務器， 而不是在一箇中心階段管理所有的元文件， volumes服務器可以管理文件及其元文件， 這種機制可以大大的緩解了中心節點的壓力， 並且可以將元文件保存在volumes服務器的內存中， 而且文件自動採用Gzip 壓縮 ， 從而保證了文件的訪問速度
weed-fs的理論模型可參考 Weed-FS models after Facebook's Haystack design paper. http://www.usenix.org/event/osdi10/tech/full_papers/Beaver.pdf
使用方式
weed-fs的master節點默認運行在9333端口，而volume節點運行在 8080 端口， 比如可以通過以下方式啓動一個master節點和兩個volume節點， 這裏所有節點跑在localhost上， 但你可以跑在多臺機器上
啓動master節點 ./weed
master
啓動volume節點
weed volume -dir="/tmp" -volumes=0-4 -mserver="localhost:9333" -port=8080 -publicUrl="localhost:8080" &
weed volume -dir="/tmp/data2" -volumes=5-7 -mserver="localhost:9333" -port=8081 -publicUrl="localhost:8081" &
寫文件
一個簡單的保存文件的例子 curl http://localhost:9333/dir/assign {"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
第一步發送http GET請求獲得文件的fid和volume服務器的url： curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6 {"size": 43234}
第二步發送http的 multipart POST請求（url+'/'+fid） 存儲實際的文件
保存文件ID
你可以保存文件fid, 3,01637037d6到任何一個數據庫中， 3表示volume服務器id，這是一個無符號的32位整型數字， 逗號後面的 01表示文件id，這是一個無符號的64位整型 ，最後的637037d6表示文件cookie， 它是一個無符號的32位整型， 用戶保護url的安全訪問 文件ID和cookie ID都是十六進制編碼， 你可以按照你自己的格式對元組進行保存， 比如把fid當作字符串，理論上你需要 8+1+16+8=33 bytes個字節
讀取文件
這裏有一個如何根據url訪問的例子
curl http://localhost:9333/dir/lookup?volumeId=3
{"Url":"127.0.0.1:8080","PublicUrl":"localhost:8080"}
首先通過volumeId查詢 volume 服務器的url, 由於通常情況下， volume 服務器不會很多， 也不會經常變動，所以你可以緩存查詢結果 現在你可以通過url從volume服務器上加載所需要的文件： http://localhost:8080/3,01637037d6.jpg
架構
對於大部分的分佈式存儲系統， 會把文件分成很多chunk, 中心節點保存文件名與chunk索引的映射，chunk索引中包含chunk server 和chunk handler等信息， 這種方式不能處理有效的處理大量的小文件，而且訪問請求也會通過master節點， 在高併發的情況下， 響應會很慢。
在weed-fs中， 採用volumes server管理數據， 每個volume的大小爲32GB，並且能夠持有大量的文件，每個存儲節點有多個volume節點，master節點只需要管理volume的元數據即可，而實際文件的元文件則儲存在各個 volume 中， 每個元文件的大小爲16 bytes，所有的文件訪問均可在內存中處理，而硬盤操作僅僅是在實際的文件讀取時纔開始
Master Server and Volume Server
架構非常簡單，實際數據存儲在volumes裏， 一個volume服務器包含多個volumes, 可同時支持讀寫操作，所有的volumes被 master server管理， master server包含了volume與volume server的映射關係，這種靜態的對應關係可以很輕鬆的被緩存
對於每次的寫請求， master server也會生成文件的key, 因爲寫沒有讀那麼頻繁， 所以一個master server可就可以應對大量的請求
讀寫文件
但客戶端發出寫請求， master server 返回 ， 之後客戶端想 volume 節點發出POST請求， 以REST的方式傳送文件內容，當客戶端需要讀取文件， 它需要向master server或者緩存中獲取， 最後用過public url獲取內容
存儲大小
在當前的設計中， 每個volume可以存儲32GB的數據， 所以單個文件的大小是受制於volume的大小的， 但這個容量是可以在代碼中調整的
內存儲存
所有 volume server上的元文件信息是存儲在內存中的， 而不需要從硬盤中讀取， 每個元文件都是16字節大小的映射表
同類產品比較
HDFS的特點是分割大文件， 能很完美的讀寫大文件 WeedFS的特點是偏向於小文件， 追求更高的速度和併發能力
MogileFS有三層組件: tracers, database, storage nodes. WeedFS有兩層組件：directory server, storage nodes. 多一層組件就意味着：很慢的訪問、很複雜的操作以及更高的出錯機率
GlusterFS是跟POSIX規範完全兼容的， 所以更復雜 WeedFS只有一部分兼容POSIX
Mongo's GridFS 採用MongoDB管理分隔後的chunks， 每次的讀寫請求都需要數據的查詢元文件信息，對於少量請求是沒有問題的， 但對於高併發的場景， 它很容易掛掉 WeedFS採用volume管理實際的數據， 查詢任務分攤到各個volume節點， 所以很容易應對高負載的場景