标签：__ 文件 存储 group FastDFS 上传下载 storage 服务器 解析
FastDFS分布式文件系统概述
概述
- FastDFS是一个轻量级的开源分布式文件系统
- FastDFS主要解决了大容量的文件存储和高并发访问的问题，文件存取时实现了负载均衡
- FastDFS实现了软件方式的RAID，可以使用廉价的IDE硬盘进行存储
- 支持存储服务器在线扩容
- 支持相同内容的文件只保存一份，节约磁盘空间
- FastDFS只能通过Client API访问，不支持POSIX访问方式
- FastDFS特别适合大中型网站使用，用来存储资源文件（如：图片、文档、音频、视频等等）
FastDFS与集中存储方案的对比
fastDFS架构原理
组成
- 客户端
- 访问服务器（TrackerServer）
- 存储服务器（StorageServer）
1、客户端
- 通常是只开发人员编写的应用程序，通过api用来调用tracker和storage
2、访问服务器TrackerServer
trackerServer是访问服务器，是访问storageServer的入口
作用
- 管理storage集群，storgae启动时，可自行注册状态到跟踪服务器上，并定期报告自身信息，包括磁盘存储空间、文件同步状况、文件上传下载次数统计等
- 服务入口，客户端访问storage之前，必须通过tracker，动态获取storage的连接信息
- TrackerServer的高可用
- 一个fastdfs集群可以有多个tracker节点，自主选择一个leader节点
3、存储服务器StorageServer
- storage是数据存储服务器，文件和元数据都保存在存储服务器上，以组（卷，group）为单位，一个group内包涵多台storage机器，数据互为备份。存储空间以group内容量最新的storage为准，所以多台stroage配置要尽量一致。
- 可以采用高可用方式进行数据存储
- fastdfs选择集群不同的存储服务器组/卷来存储，组的存储服务器互相通信，同组内的存储服务器之间会进行文件同步连接
- 存储服务器采用binlog文件记录文件上传、删除更新等操作。binlong中只记录文件名，不记录文件内容
- 文件同步只在组内的存储服务器之间进行，采用推送方式。即源头服务器推送数据到目标服务器
fastDFS上传
流程
- client询问tracker可以上传到哪一个stroage，或者指定获取某个组的stroage
- tracker返回一台可用的storage
- client直接和storage通讯完成文件上传
- storage保存文件后给client返回组名和文件名
文件上传服务端内部处理的详细机制如下
选择tracker
当集群中有多个tracker时，由于tracker之间是完全对等的关系，因此客户端在upload文件时可以任意选择一个trakcer
选择group
- 当客户端没有指定group时，由服务端tracker自动指定。当tracker接收到upload file的请求时，会为该文件分配一个可以存储该文件的group，支持如下选择group的规则：
- Round robin，所有的group间轮询
- Specified group，指定某一个确定的group
- Load balance，剩余存储空间多多group优先
选择storage
当选定group后，tracker会在group内选择一个storage节点给客户端，支持如下选择storage的规则：
- Round robin，在group内的所有storage间轮询
- First server ordered by ip，按ip排序
- First server ordered by priority，按优先级排序（优先级在storage上配置）
选择storage path
当分配好storage server后，客户端将向storage发送写文件请求，storage将会为文件分配一个数据存储目录，支持如下规则：
- Round robin，多个存储目录间轮询
- 剩余存储空间最多的优先
生成Fileid
选定存储目录之后，storage会为文件生一个Fileid:
- storage server ip（32位整数）
- 文件创建时间（unix时间戳，32位整数）
- 文件大小
- 文件crc32校验码
- 随机数（这个字段用来避免文件重名）
- Fileid由上述部分拼接而成，然后将这个二进制串进行base64编码，转换为可打印的字符串
选择文件子目录
当选定存储目录之后，storage会为文件分配一个fileid，每个存储目录下有两级256*256的子目录，storage会按文件fileid进行两次hash，路由到其中一个子目录，然后将文件以fileid为文件名存储到该子目录下
生成文件名返回客户端
当文件存储到某个子目录后，即认为该文件存储成功，接下来会为该文件生成一个文件名返回客户端，文件名由下述几个部分构成
- group name-文件上传后所在的存储组名称
- 存储目录 - 存储服务器配置的虚拟路径，与磁盘选项store_path*对应。如果配置了store_path0则是M00，如果配置了store_path1则是M01，以此类推
- 数据两级目录 - 存储服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件fileid
- 文件后缀名（由客户端指定，主要用于区分文件类型）拼接而成
- 生成的文件名需返回到客户端，需要由客户端进行保存
fastDFS下载
- client询问tracker下载文件的storage，参数为文件标识（组名和文件名）
- tracker返回一台可用的storage
- client直接和storage通讯完成文件下载
由于storage有多个存储节点，存储节点间的文件同步是在后台异步进行的，所以有可能出现在读的时候，文件还没有同步到某些storage server上，为了尽量避免访问到这样的storage，tracker按照如下规则选择group内可读的storage：
- 该文件上传到的源storage - 由于源头的地址被编码在文件名中，只要源头storage存活，优先返回
- 文件创建时间戳==storage被同步到的时间戳 且(当前时间-文件创建时间戳) > 文件同步最大时间（如5分钟) - 文件创建后，认为经过最大同步时间后，肯定已经同步到其他storage了
- 文件创建时间戳 < storage被同步到的时间戳。 - 同步时间戳之前的文件确定已经同步了
- (当前时间-文件创建时间戳) > 同步延迟阀值（如一天）。 - 经过同步延迟阈值时间，认为文件肯定已经同步了
fastDFS同步
- 同一组内的StorageServer之间是对等的，文件上传、删除等操作可以在任意一台StorageServer上进行；
- 文件同步(添加/删除/修改)只在同组内的StorageServer之间进行，采用push方式，即源服务器同步给目标服务器；
- 源头数据才需要同步，备份数据不需要再次同步，否则就会构成环路了；
- 上述第二条规则有个例外，就是新增加一台StorageServer时，由已有的一台StorageServer将已有的所有数据（包括源头数据和备份数据）同步给该新增服务器。
FastDFS文件目录介绍
FastDF服务端目录介绍
TrackerServer
${base_path}
|__data
| |__storage_groups.dat：存储分组信息
| |__storage_servers.dat：存储服务器列表
|__logs
|__trackerd.log：tracker server日志文件
StorageServer
${base_path}
|__data
| |__.data_init_flag：当前storage server 初始化信息
| |__storage_stat.dat：当前storage server统计信息
| |__sync：存放数据同步相关文件
| | |__binlog.index：当前的binlog文件索引号
| | |__binlog.###：存放更新操作记录（日志）
| | |__${ip_addr}_${port}.mark：存放同步的完成情况
| |
| |__一级目录：256个存放数据文件的目录，如：00, 1F
| |__二级目录：256个存放数据文件的目录
|__logs
|__storaged.log：storage server日志文件标签：__,文件,存储,group,FastDFS,上传下载,storage,服务器,解析 来源： https://blog.csdn.net/qq_41249513/article/details/120416213
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。