如果需要存储大量图片，比如网络相册，配置文件等，如果和应用部署在一起，分布式情况下无法多个服务共享。况且有些服务器对http静态资源支持不好，比如tomcat对动态资源支持比较好，apache适合静态资源访问。
需要解决问题
1 多个服务共享---建立图片服务器
2. 扩容问题----需要支持水平扩展
为了解决这两个问题，我们使用FastDFS集群来解决，FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。它的优势是可以水平扩容，FastDFS存储资源的设备是按组来区分的，当存储空间不足时，便可以通过水平增加分组并相应添加设备来达到扩容的目的，而且是没有上限的。还有个优势是高可用，也就是说FastDFS集群能够做到当提供服务的nginx发生故障时，自动切换到另一台nginx设备上，保障服务的稳定。
FastDFS应用
主要解决了海量数据存储问题，特别适合以中小文件（建议范围：4KB < file_size <500MB）为载体的在线服务。
之所以适合中小文件，是因为每个卷，也就是group对所有storage存储对文件都是冗余备份，如果存储文件过大，每个卷的所有storage server都是冗余的 ，空间很容易饱和。
架构图
- Tracker server 负责调度，均衡，storage server 周期性心跳上报状态
- Tracker server 也是一个集群，防止单点故障，tracker server 每个节点都是对等的，发送给任何一个server 都没有区别
- 每个卷之间的文件是不同的，卷内的文件都是相同的，通过binlog进行同步，storage server的同步信息也会发给tracker server，用于调度判断
上传文件流程：
下载文件流程：
思考
1. 通过冗余备份实现高可用
2.增加tracker层负责路由调度
3 通过冗余备份，还是cluster的思路 ，感觉不是真正的分布式文件存储。
通过比对redis cluster架构，发现我之所以认为不是分布式的原因是存储到卷到时候没有进行hash运算，比如redis到3主3从结构，存储到主节点到时候，对key进行crc16，然后对16384求模，这个key能够相对均匀对分布式在3个主节点上。因为每个节点都是部分数据，如果一个节点挂掉，无法提供服务，因为数据不全。所以需要各配置一个冗余节点，存储备份信息。也就是我们常用对3主3从架构。
查阅一下fastdfs，负载均衡在group之间可以做，但是是静态的负载均衡。具体说一下什么是静态的负载均衡：
负载均衡：
本地流量管理技术主要有一下几种负载均衡算法：
静态负载均衡算法包括：轮询，比率，优先权
动态负载均衡算法包括: 最少连接数,最快响应速度，观察方法，预测法，动态性能分配，动态服务器补充，服务质量，服务类型，规则模式
那么问题来了，hash本身可以实现动态较为均匀分布，那么hash本身也是一种负载均衡方式，是吗？记得nginx的负载均衡方式有round-robin，加权，ip hash，fair，url hash等。其中iphash就是根据ip地址hash运算后进行
一个简单等求模运算就可以把数字均衡分布到3个桶里，实现了均衡分布，实际应用中，需要优化