s
一个基于Golang的分布式存储开源项目 / weed-fs
http://blog.csdn.net/love_se/article/details/7951771
项目地址：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节点， 所以很容易应对高负载的场景
分布式小文件系统fastdfs与weedfs的对比
http://www.tuicool.com/articles/uaiimu
http://wenjun.org/database/1087.html?utm_source=tuicool
最近拿一台双核1G的kvm vps搭建了一个图片的服务器，前面用百度云加速扛着，有了个专业图片存储及CDN的样子。每天还是有50W左右的PV，流量在30G左右。总结一下最近接触过的两个分布式小文件系统weedfs和fastdfs。
fastdfs的详细介绍看这里=》传送门
weedfs官方地址=>传送门
在两个系统中都有一个负责管理存储节点或者存储卷的服务，weedfs中叫master,而fastdfs中叫做tracker。下面是在文档中对各自的master的解释
根据上面的解释就可以知道，master在上传和下载文件的过程中都承载着定位文件需要上传或者下载的具体的卷。
在具体存储小文件的时候，weedfs是通过将多个小文件的二级制存储到一个大文件中，然后通过索引进行具体的位置的定位。而fastdfs是通过文件夹散列的方式将文件直接存储在硬盘上面。但从这里就可以看出来，在海量小文件的情况下，weedfs产生的文件的元数据是很少的，因他他至于每个数据卷的元数据。而weedfs会产生大量的元数据，因为他依赖的是操作系统的文件管理系统，对每一个文件的定位以及验证都是通过元数据来进行的。
从上面的对比就可以看出来，在海量小文件的情况下肯定是weedfs的性能更高，因为他的文件元数据是相当少的，所以这部分经常被访问的元数据能够被操作系统或者内存直接缓存住，这样就减少了对磁盘的操作，而磁盘的操作只需要进行一次，就是在进行文件读取的时候。而fastdfs回产生海量的文件的元数据，大到一定程序了操作系统的缓存或者内存就无法进行全部存储了，这样就造成了在硬盘上进行随机读写来查找文件了，两个效率和速度以及对系统和硬盘造成的负载显而易见了。
总结：小文件存储不同于大文件，大文件的性能和时间消耗，主要在传输的带宽等限制上。而小文件主要在于系统本身的读取速度上。所以综合来说，个人觉得weedfs比fastdfs更先进，更能承受数量更大的小文件
-
不是我干的 2014年11月4日1楼fastdfs 被 weedfs 完爆的，淘宝的 tfs 和 weedfs 还有的一比，但是感觉还是 weedfs 简单易用。淘宝的 tfs 太复杂了，光配置参数就一大堆配个没玩没了。
说的是，tfs没搭建起来，哈哈。我最后的实现还是用的weedfs，尽管先用fastdfs实现了我的小文件存储，但是最后还是选择了weedfs
lindows.iteye.com / weedfs 性能压测结果：
\\192.168.98.17\D$\TestCase\20150303_uimg
30台压力机,60台服务器,图片总量7个亿,4680并发用户,双光纤计流150MB,9k图片下载TPS 2万/秒,响应时间0.192秒。
SMS告警：2015-03-04 03:02:00 图片处理系统Nginx分发服务器连接数为：7101>=7000阀值，警告。
http://dl2.iteye.com/upload/attachment/0106/3355/4c25ebd2-96fa-3c94-a75f-691050063c45.jpg
http://dl2.iteye.com/upload/attachment/0106/8417/682a682e-3c91-3865-b94c-5ded9b6bd049.jpg
第二次压测
分布式对象存储sdoss / weedfs / weed-fs / 适用于9k小图片
海量文件存储
主站有来自互联网的海量的商品图片、描述信息、用户留言等非结构化的数据，必须满足百亿文件数
弹性扩容
能否在线扩充整个图片系统的容量、iops
高性能
能搞满足双11，双12等大促时海量用户的并发请求
分布式文件系统SDFS / GlusterFS / 适用于doc、txt、xls等文件型小文件
弹性存储系统（Elasticity）
存储系统具有弹性能力，意味着企业可以根据业务需要灵活地增加或缩减数据存储以及增删存储池中的资源，而不需要中断系统运行。
线性横向扩展（Linear Scale-Out）
纵向扩展（Scale-Up）旨在提高单个节点的存储容量或性能，往往存在理论上或物理上的各种限制，而无法满足存储需求。横向扩展（Scale-Out）通过增加存储节点来提升整个系统的容量或性能，这能有效应对容量、性能等存储需求。
高可靠性（Reliability）
在普通的服务器和硬件上构建企业级存储，可靠性显得尤为关键。
分布式文件存储产品 / fastDFS / 原老旧型项目架构暂已不能适用 >300GB的海量文件
对象存储 swift
https://www.zybuluo.com/yummy/note/28041
end
