工作原理
1. FastDFS服务端有2个角色 分别是tracker(跟踪器(或说是调度器会更合适)) 和 storage(存储节点)。
2. tracker负责调度和负载均衡，并不需要存储文件的索引信息，因为文件上传后 stroage 返回给客户端的文件ID中就包含了组名、文件相对路径和文件名等(文件ID还包含了文件大小、时间戳、源storage server IP地址、文件内容校验码、随机数等), client可以根据文件ID直接定位到文件所在的组(但具体哪个storage server下载就需要询问tracker server)。
3. storage负责文件的管理(包括: 存储，同步，提供存取接口)，并对文件的meta data(元数据)进行管理，meta data就是指文件的相关属性，以键值对(key value pair)方式表示，如:width=1024，文件的meta data是文件属性列表，可以包含多个键值对。
4. tracker 和 storage都可以由一台或多台服务器构成，均可以随时增加或减少而不影响线上服务(存储卷中只有一台服务器除外，详细见存储原理)。其中 tracker 所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。
存储原理
1. 为了支持大容量，storage采用了 "分卷" 的组织方式，整个存储系统由一个或多个卷组成(相当于raid0)
2. 卷与卷之间的文件是相互独立的，所有卷的容量累加起来就是整个存储系统的容量。
3. 其中一个卷 可以由一台或多台存储服务器组成，同一个卷下的存储服务器中的文件都是相同的(相当于raid1，所以一般由2台服务器组成一个卷，卷的容量以卷内服务器磁盘空间最小的为准)，卷中的多台存储服务器起到了冗余和负载均衡的作用。
4. 经过第 1、3点的介绍，就可以知道，整个FastDFS的存储是类似raid10的逻辑，底层分卷 卷中做raid1 再把所有卷通过raid0逻辑叠加起来。
5. storage接收到写文件请求时，会根据配置好的规则 选择其中一个存储目录来存储文件。
6. 为了避免单个目录下的文件数太多，storage第一次启动时，会在每个数据存储目录里创建2级子目录，每级256个，总共65536个文件，新写的文件会以hash的方式被路由到其中某个子目录下，然后直接以本地文件存储到该目录中。(所以才能用nginx的方式来读取该文件 见后面的实验)
6. 在卷中增加服务器时，同步文件由系统自动完成，同步完成后，系统会自动将新增服务器上线提供服务
7. 当存储空间不足时，只需要动态添加卷，这样就扩大了存储系统的容量
FastDFS上传和下载过程
-- 注: FastDFS的文件标识由两个部分组成: 卷名和文件名 缺一不可
上传过程
1. client询问tracker上传到的storage，不需要附加参数;
2. tracker返回一台可用的storage;
3. client直接和storage通讯完成文件上传。
下载过程
1. client询问tracker下载文件的storage，参数为文件标识(卷名和文件名);
2. tracker返回一台可用的storage;
3. client直接和storage通讯完成文件下载。
本文暂时没有评论，来添加一个吧(●'◡'●)