经典论文翻译导读之《Finding a needle in Haystack: Facebook’s photo storage》
http://www.importnew.com/3292.html
下面一张图总结下相互关系：
weed master 创建的是一个master服务器。
参数：
-defaultReplication string 备份策略（详细见 https://github.com/chrislusf/seaweedfs/wiki/Replication ）
-ip string
-mdir string选项用于配置保存生成的序列文件id的文件夹
-port int (default 9333)
-volumeSizeLimitMB uint 自定义不能大于30000(default 30000)
-whiteList string 白名单，ip地址用逗号隔开
master服务器可以创建多个来实现故障转移主服务器，详细见 https://github.com/chrislusf/seaweedfs/wiki/Failover-Master-Server
参数：
-dir string 数据保存的路径，如果master的mdir没有指定会使用这个，如果filer的dir没有指定会新增并使用该目录下的filer目录
-ip string
-mserver string (default "localhost:9333")
-port
-dataCenter string
-rack string
-whiteList string
weed volume会创建一个 datanode ，可以指定所属的 datacenter rack和master ，会根据配置存储文件，默认一开始没有volume，当开始存储文件的时候才会创建一个volume，当这一个volume大小超过了volumeSizeLimitMB 就会新增一个volume，当volume个数超过了max则该datanode就不能新增数据了。那就需要在通过weed volume命令新增一个datanode。
weed filer
参数
-collection string 所有数据将存储在此集合中
-dataCenter string更倾向于在这个数据中心写入卷
-dirListLimit int limit sub dir listing size (default 100000)
-ip string
-master string
-port int(default 8888)
更详细的说明请见： https://mp.csdn.net/mdeditor/85049078#
或者访问官网wiki ： https://github.com/chrislusf/seaweedfs/wiki
出现如下提示说明启动成功
执行下面的命令：
出现DataCenters是null的原因是没有执行weed volume创建DataCenter。
" 这里说一下抽象概念"：
我们抽象的认为我们的图片服务器，一个master需要两个datacenter叫imgdatacenter1，imgdatacenter2；imgdatacenter1需要两个rack叫imgrack1,imgrack2；然后imgrack1需要两个datanode1，datanode2；
创建datanode时 ，统一设置每个datanode包含10个volume即可。当datanode里面的volume满了以后再创建 新的datanode即可，方便扩展，并且不同datanode可以在不同磁盘位置；
（imgdatacenter1的imgrack2和imgdatacenter2按照上面的方式创建即可，见附录 ）
目前我们只是用imgdatacenter1->imgrack1->datanode1中的datanode1 :
创建datanode1的时候 master命令行会打印，提示leader新增child imgdatacenter1成功；imgdatacenter1新增child imgrack1成功；imgdatacenter1，imgrack1新增child 9991成功；volume server在9991端口。
此时再执行查看master状态的命名；
DataCenters Racks DataNodes都存在了；
但是名为localhost:9991的datanode中的volumes为0，明明我们设置了10啊；
因为没有上传文件之前不会创建volume，volume会在上传文件的时候根据实际情况创建。
这里注意下layouts，现在是null，当上传文件的时候会出现一个名为""的collection，里面的writables就是volume 的id数组，如果你自定义了collection，name你自定义的collection也会出现在这里，并且所有collection的volume个数之和小于等于我们设置的10；
collection删除后再新增，里面的volume的id会一直递增，不会使用原先删除的volume id。
此时我们可以上传文件了。
上传文件有多种方式，这里我们先说明两个
1.先向master申请文件id，然后用文件id向datanode上传文件：
修改只需要在fid上传别的文件即可
上传成功后访问，只需要拼接url即可： localhost:9991/1,015b7256d5
2.直接向master上传文件，master自己生成文件id，并向datanode上传文件，然后返回结果：
此时你再查看状态发现volume就创建了10个。
此时查看datanode的状态：
因为我1.jpg上传了两次，而且第一次在id为1的volume中，第二次在id为3的volume中，所有你会发现这两个id的volume的FileCount都为1
并发的上传文件：
一个卷服务器一次只写一个卷。如果需要增加并发性，可以预先分配大量卷。下面是例子。您还可以组合所有不同的选项。状态详情见附录
删除文件：
文件的删除不是实时的，因为weed默认有个阈值，超过这个阈值才会清理没使用的空间，如果你一时间内删除了大量文件，想立马生效，可以用这种方式清理未使用的空间：
此时文件通过url的增删改查都可以了，下面把服务映射成文件系统来操作，可以方便的操作本地的大量文件
filer是将文件以文件目录的方式上传到图片服务，然后你根据文件目录的方式访问
默认使用leveldb保存映射关系，打开filer.toml文件修改保存映射文件的文件夹为ftmp（自定义）
然后启动filer服务
master打印如下信息说明成功
自身的log
直接往weed filer中拷贝目录或者文件（-include是文件模式通配符前使用？？）
weed filer.copy nginxdir http://localhost:8888/aaa 把nginxdir拷贝到aaa目录下
weed filer.copy -include *.go . http://localhost:8888/github/
详细请见 https://github.com/chrislusf/seaweedfs/wiki/Filer-Server-API
然而我们时长会有这样的需求，批量把照片保存成图片文件备份起来，而不是备份一个bat文件；
或者我们想以目录结构的方式通过本地访问，而不是通过web访问？
此时最简单有效的方法就是把filer服务器mount到本地，然后直接操作文件系统：
weed mount 像访问本地目录一样访问文件系统，前提是开启了 master volume filer
（它使用bazil.org/FUSE，它允许在Linux和OSX上编写FUSE文件系统。在OSX上，它需要OSXFUSE）
可以指定 collection
关闭挂在需要关闭mount并且手动umont ~/mdir目录，如果一般用户失败请使用root用户
一个场景：
如果本地已经有很多文件了，如何快速的迁移到seaweedfs中呢？
1.启动master、volume、filer
2.启动mount
3.手动拷贝到mount目录中（单线程的）
4.使用weed filer.copy file_or_dir1 [file_or_dir2 file_or_dir3] http://localhost:8888/path/to/a/folder/ （多线程且绕过fuse层）
aws s3 兼容
Each bucket is stored in one collection, and mapped to folder /buckets/<bucket_name>by default
可以通过删除collection来快速删除一个bucket
异步复制
应该有两个SeawideFileSystems运行，可能跨数据中心运行。每个服务器都应该有自己的文件服务器、主服务器和卷服务器。
这是我执行了（curl " http://localhost:9333/vol/grow?collection=imgcoll&count=3 " ）的结果
详细文档请见官方wiki
https://github.com/chrislusf/seaweedfs/wiki/Getting-Started
部署简单。Go 编译生成的是一个静态可执行文件，除了 glibc 外没有其他外部依赖。这让部署变得异常方便：目标机器上只需要一个基础的系统和必要的管理、监控工具，完全不需要操心应用所需的各种包、库的依赖关系，大大减轻了维护的负担。这和 Python 有着巨大的区别。由于历史的原因，Python 的部署工具生态相当混乱【比如 setuptools, distutils, pip, buildout 的不同适用场合以及兼容性问题】。官方 PyPI 源又经常出问题，需要搭建私有镜像，而维护这个镜像又要花费不少时间和精力。并发性好。Goroutine 和 channel 使得编写高并发的服务端软件变得相当容易，很多情况下完全不需要考虑锁机制以及由此带来的各种问题。单个 Go 应用也能有效的利用多个 CPU 核，并行执行的性能好。这和 Python 也是天壤之比。多线程和多进程的服务端程序编写起来并不简单，而且由于全局锁 GIL 的原因，多线程的 Python 程序并不能有效利用多核，只能用多进程的方式部署；如果用标准库里的 multiprocessing 包又会对监控和管理造成不少的挑战【我们用的 supervisor 管理进程，对 fork 支持不好】。部署 Python 应用的时候通常是每个 CPU 核部署一个应用，这会造成不少资源的浪费，比如假设某个 Python 应用启动后需要占用 100MB 内存，而服务器有 32 个 CPU 核，那么留一个核给系统、运行 31 个应用副本就要浪费 3GB 的内存资源。
良好的语言设计。从学术的角度讲 Go 语言其实非常平庸，不支持许多高级的语言特性；但从工程的角度讲，Go 的设计是非常优秀的：规范足够简单灵活，有其他语言基础的程序员都能迅速上手。更重要的是 Go 自带完善的工具链，大大提高了团队协作的一致性。比如 gofmt 自动排版 Go 代码，很大程度上杜绝了不同人写的代码排版风格不一致的问题。把编辑器配置成在编辑存档的时候自动运行 gofmt，这样在编写代码的时候可以随意摆放位置，存档的时候自动变成正确排版的代码。此外还有 gofix, govet 等非常有用的工具。
执行性能好。虽然不如 C 和 Java，但通常比原生 Python 应用还是高一个数量级的，适合编写一些瓶颈业务。内存占用也非常省。
