1 简介
分布式文件系统(Distributed File System,DFS)是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点(可简单的理解为一台计算机)相连;或是若干不同的逻辑磁盘分区或卷标组合在一起而形成的完整的有层次的文件系统。
- 随着文件数据的越来越多,通过tomcat或nginx虚拟化的静态资源文件在单一的一个服务器节点内是存不下的,如果用多个节点来存储也是不利于管理和维护,所以我们需要一个系统来管理多台计算机节点上的文件数据,这就是分布式文件系统。
- 分布式文件系统是一个允许文件通过网络在多台节点上分享的文件系统,多台计算机节点共同组成一个整体,为更多的用户提供分享文间。比如常见的网盘,本质就是一个分布式的文件存储系统。虽然我们是一个分布式的文件系统,但是对用户来说是透明的,用户使用像是访问本地磁盘一样。
- 分布式文件系统可以提供冗余备份,所以容错能力很高。 系统中有某些节点宕机,但是整体文件服务不会停止,还是能够为用户提供服务,整体还是运作的,数据也不会丢失。
- 分布式文件系统的可扩展性强,增加或减少节点都很简单,不会影响线上服务,增加完毕后会发布到线上,加入到集群中为用户提供服务。
- 分布式文件系统可以提供负载均衡能力,在读取文件副本的时候可以由多个节点共同提供服务,而且可以通过横向扩展来确保性能的提升和负载。
2 为什么要使用分布式文件系统
2.1 单机系统
单台服务器项目部署的话,我们一般在指定的目录下建立静态资源文件夹,例如:/opt/module/web/static/
,通过nginx或者tomcat来实现对文件的访问。
优点:实现起来比较简单,不需要任何复杂的技术,保存数据库和访问也比较方便。
缺点:当文件资源访问比较频繁的情况下,会占用大量的资源,影响正常的业务运行,对生产环境产生冲击。
2.2 文件服务器
为了解决单机系统文件资源大量访问造成的问题,引入了独立文件服务器,可以通过部署ftp服务,将文件上传到指定的目录,再将这个目录挂载到tomcat或者nginx中,这样前端可以通过访问独立的文件服务器来访问文件资源。
优点:将文件服务器分离出来之后,可以大大减轻业务端的压力。独立存储,也方便备份和负载均衡。
缺点:独立服务器部署无法进行容灾(宕机就无法使用),无法垂直扩容等。
2.3 分布式文件系统
独立的文件服务器宕机的时候,即时你做了人工的定时系统备份,你也是需要人工去切换到另外一台服务器的。还有,如果文件系统存储达到100T的情况,单机服务器完全无法保证请求的性能。
业务继续发展,单台服务器存储和响应也很快到达了瓶颈,新的业务需要文件访问具有高响应性、高可用性来支持系统。分布式文件系统,一般分为三块内容来配合,服务的存储、访问的仲裁系统,文件存储系统,文件的容灾系统来构成,仲裁系统相当于文件服务器的大脑,根据一定的算法来决定文件存储的位置,文件存储系统负责保存文件,容灾系统负责文件系统和自己的相互备份。
优点:扩展能力: 毫无疑问,扩展能力是一个分布式文件系统最重要的特点;高可用性: 在分布式文件系统中,高可用性包含两层,一是整个文件系统的可用性,二是数据的完整和一致性;弹性存储: 可以根据业务需要灵活地增加或缩减数据存储以及增删存储池中的资源,而不需要中断系统运行。
缺点:复杂性较高,需要专业的人员去维护。
3 HDFS与FastDFS
3.1 对比
HDFS和FastDFS对比
测试项 | HDFS | FastDFS |
---|---|---|
25个小文件上传 | 13599ms | 1949ms |
318个图片上传 | 63460ms | 9585ms |
3个700m视频上传 | 62092ms | 58137ms |
3个2g视频上传 | 171743ms | 131861ms |
25个小文件下载 | 13008ms | 1218ms |
318个图片下载 | 24942ms | 7051ms |
3个700m视频下载 | 69266ms | 36144ms |
3个2g视频下载 | 192315ms | 138215ms |
25个小文件删除 | 10517ms | 62ms |
318个图片删除 | 12828ms | 811ms |
3个700m视频删除 | 10286ms | 150ms |
3个2g视频删除 | 10594ms | 255ms |
结论
- FastDFS客户端底层连接服务端使用的是Socket,本身速度就要快很多。
- HDFS在做删除测试时,明显较慢的地方是在创建到服务端的连接上,实际删除文件的速度很快。由于每次测试都需要先创建到服务端的连接,HDFS在这块消耗较大,在实际场景下,差距应该没有这么大。
- 两者的适用场景确有不同,FastDFS更适合小文件的高效存取,而HDFS更适合超大文件上传后使用Mapreduce去做大数据处理。
- HDFS,主要解决并行计算机中的分布式存储数据的问题,其单个数据文件通常很大,采用了分块存储的方式,所以是大数据大文件存储来使用的场景。
- FastDFS主要用户互联网网站,为文件的上传与下载提供在线服务,所以在负载均衡、动态扩容等方面支持的比较好,FastDFS不会对文件进行分块存储,用于存储中小文件都是很不错的,比如头像、小的音频文件等等。
3.2 HDFS
3.2.1 概念
HDFS(Hadoop Distributed File System)是hadoop生态系统的一个重要组成部分,是hadoop中的的存储组件,在整个Hadoop中的地位非同一般,是最基础的一部分,因为它涉及到数据存储,MapReduce等计算模型都要依赖于存储在HDFS中的数据。HDFS是一个分布式文件系统,以流式数据访问模式存储超大文件,将数据分块存储到一个商业硬件集群内的不同机器上。
优点
- 高容错性:数据自动保存多个副本,副本丢失后,自动恢复
- 适合批处理:移动计算而飞数据。数据位置暴露给计算框架
- 适合大数据处理:GB,TB,设置PB级数据。百万规模以上文件数量。10K+节点规模。
- 流式文件访问:一次性写入,多次读取。保证数据一致性。
- 可构建在廉价机器上:通过多副本提高可靠性。提供容错和恢复机制。
缺点
- 不适合低延迟数据访问场景:比如毫秒级,低延迟与高吞吐率
- 不适合小文件存取场景:占用NameNode大量内存。寻道时间超过读取时间。
- 不适合并发写入,文件随机修改场景:一个文件只能有一个写者。仅支持append
3.2.2 基础组件
NameNode
- 是Master节点,有点类似Linux里的根目录
- 管理数据块映射
- 处理客户端的读写请求
- 配置副本策略
- 管理HDFS的名称空间
- 内存中存储的是=fsimage+edits
SecondaryNameNode
- 保存着NameNode的部分信息(不是全部信息NameNode宕掉之后恢复数据用)
- NameNode的冷备份
- 合并fsimage和edits然后再发给namenode。(防止edits过大的一种解决方案)
DataNode
- 负责存储client发来的数据块block
- 执行数据块的读写操作
- 由NameNode调配使用
fsimage
- 元数据镜像文件(文件系统的目录树。)
edits
- 元数据的操作日志(针对文件系统做的修改操作记录)
3.3 FastDFS
3.3.1 概念
FastDFS 是一个开源的高性能分布式文件系统(DFS)。 它的主要功能包括:文件存储,文件同步和文件访问,以及高容量和负载平衡。主要解决了海量数据存储问题,特别适合以中小文件(建议范围:4KB < file_size <500MB)为载体的在线服务。
3.3.2 核心功能
FastDFS 系统有三个角色:跟踪服务器(Tracker Server)、存储服务器(Storage Server)和客户端(Client)。
Tracker Server:跟踪服务器,主要做调度工作,起到均衡的作用;负责管理所有的 storage server和 group,每个 storage 在启动后会连接 Tracker,告知自己所属 group 等信息,并保持周期性心跳。
Storage Server:存储服务器,主要提供容量和备份服务;以 group 为单位,每个 group 内可以有多台 storage server,数据互为备份。
Client:客户端,上传下载数据的服务器,也就是我们自己的项目所部署在的服务器。
3.3.3 核心原理
CSDN下载地址:
https://download.csdn.net/download/qq_15769939/15801405
文件上传
文件下载
4 相关信息
- 博文不易,辛苦各位猿友点个关注和赞,感谢
网友评论