FastDFS由跟踪服务器(Tracker Server)、存储服务器(Storage Server)和客户端(Client)构成。
跟踪服务器Tracker Server
和TFS的NameServer相似,负责接收客户端的请求,选择合适的组合StorageServer ，他们与StorageServer之间也用心跳机制来检查对方是否还活着。
Tracker需要管理的信息也都放在内存中，并且里面所有的Tracker都是对等的，很容易扩展
客户端访问集群的时候会随机分配一个Tracker来和客户端交互。
存储服务器Storage Server
主要负责提供容量和备份服务。
他们是以group为单位，一个group里面的Storage数据互相备份，也就是数据是一样的。这种方法的好处是可以隔离不同应用的数据，比如一个应用的数据放在一个group里面，
缺点也很明显了， 整个group的容量其实就是每一个Stroage的容量，容量会受到限制。
而且部署时候Storage的容量要保持一致，这样可以避免浪费资源
当group里有机子坏掉的时候，数据恢复只能依赖group组内的其他服务器，会比较慢。。。不是很懂，那怎样操作才是快呢。
写操作的时候，storage会将他所挂载的所有数据存储目录的底下都创建2级子目录，每一级256个总共65536个，新写的文件会以hash的方式被路由到其中某个子目录下，然后将文件数据作为本地文件存储到该目录中。
客户端Client
主要是上传下载数据的服务器，也就是我们自己的项目所部署在的服务器。每个客户端服务器都需要安装Nginx
FastDFS的存储策略
为了支持大容量，存储节点（服务器）采用了分卷（或分组）的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。
在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。
这样做的优点是比较灵活，当你的某个应用或者模块（对应一个group）的访问量超过其他的时候，可以直接在group上面增加若干个storage来实现负载均衡
FastDFS的读取和写入操作
FastDFS向使用者提供基本文件访问接口，比如upload、download、append、delete等，以客户端库的方式提供给用户使用
FastDFS的文件同步
当客户端将一条数据成功写到一个storage中就算写入成功，他的文件同步是在后台线程上面运行的，这是和TFS不太一样的地方。
FastDFS同步的时候会生成一个binlog，这里包含数据的元信息，storage会记录下他同步的进度，以便关机重启之后可以继续同步，这个进度以时间戳的方式记录，所以需要所有的服务器保持时钟的一致。
他的文件同步机制还带来了一个安全隐患，就是当客户端写入成功之后，进行备份的时候，如果源storage突然爆炸了0.0（就是那种彻底毁坏，数据也丢了，系统也坏了的那种损坏）
这个数据就会丢失。不过感觉一般不太可能爆炸吧0.0
注意：
1.group2同组的Storage2和Storage3 FastDFS服务端口必须一致: port=23000。
2.一台服务器可以装多个组(group)但不能装同组的多个Storage,日志会报错误，日志报错原因是"注意1"
3.Version 4.05之前fastdfs内部绑定了libevent作为http服务器.Version 4.05之后的版本删除了内置的web http服务，内置的web http服务是个累赘，不用也罢！
4.启动storage server时，一直处于僵死状态.启动storage server，storage将连接tracker server，如果连不上，将一直重试。直到连接成功，启动才算真正完成!如果集群中有2台tracker server，而其中一台tracker没有启动，可能会导致storage server一直处于僵死状态
