WEEDFS

weed-fs是一款由Go语言实现的，基于facebook haystack论文的面向blob的分布式存储系统，部分应用于google内部。该系统具有代码量较少，结构简单，且不包含第三方依赖，易于部署的特点。本文将简单介绍一下这个系统。

特点

设计很大程度上借鉴的facebook的论文:Finding a neddle in the hay stack

系统由两个部分构成：Master和VolumeServer。

Master: 维护Volume的元数据，和VolumeServer的状态

为了限制Master内存使用，它只维护volumeid到VolumeServer的映射关系。客户端需要自己维护文件到fid的映射，如存放到memcached或者mysql。
关系如下：topology/data_center/rack/data_node/volumes
请求处理方式

每次读写请求都将经过Master，Master为写请求分配fid，为读请求返回fid对应的Volume地址

Master通过raft来保证元数据的高可用性，当节点出现故障时，可实现秒级切换不丢数据。
多个Maste由Raft保证同一时间有一个主来复杂处理请求，其它的节点都将请求转发到主上。

处理数据的读写请求, 维护文件的元数据信息，即文件在volume的位置。

每个Volume默认为32G，元数据只有8字节。假设Master有32G，简单计算可得，至少能存储32/832G = 128GB GB的空间，空间不是问题。

VolumeServer通过心跳向Master报告自己当前管理的volume和最大能接收多少volume。

多种粒度的Replication，replication基于volume level。有关replication的细节可以看这里：

curl http://localhost:9333/dir/assign
resp: {“count”:1,”fid”:”3,01637037d6”,”url”:”127.0.0.1:8080”,”publicUrl”:”localhost:8080”}

fid由三部分组成: ,逗号之前代码volumeid，接着是32位的keyid，和64位的cookie。这里：
volumeid = 3， keyid = 01 cookie = 637037d6

curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
返回成功后，客户端需保存/home/chris/myphoto.jpg -> 3,01637037d6 的映射。

curl http://localhost:9333/dir/lookup?volumeId=3
resp: {“locations”:[{“publicUrl”:”localhost:8080”,”url”:”localhost:8080”}]}

Weedfs设计思路简单，很大的节约了管理成本，性能不错(需要根据不同场景测试)，对于小公司是个很好地选择。

但需要注意到其切片的粒度较大，当出现节点不可用时，数据迁移需要耗费很长的时间，可能会造成短时间不可用。

假设内部宽带为20MB/s，那么迁移32G的数据需要：32G / 20MB = 1600s 大约需要半个小时
由客户端维护文件到volume的映射，一定程度增加了使用成本。