分布式存储发展历程
前段时间
618
活动火热进行,正是购物的好时机。当我们访问这些电
商网站的时候,每一个商品都会有各式各样的图片展示介绍,这些图
片一张两张可以随便丢在服务器的某个文件夹中,可是电商网站如此
大体量的图片,得分门别类的进行管理。再比如我们平时浏览的各大
视频网站的视频,还有我们现在正在浏览的
CSDN
上的各类文章,都
需要在服务器上分门别类的管理好。
在文件管理早期的时候,由于文件本身的数量和占用空间都比较小,
往往在一台服务器上既有程序在运行,也有文件在存储。随着互联网
的不断发展,现在的程序越做越大,图片的内容和数量也越来越多,
不断的侵蚀服务器有限的资源,进而影响到程序本身运行的稳定性。
于是,越来越多的系统在最初设计,或者升级改造的时候,选择将文
件的存储单独拎出来放在一台专用的文件服务器上。和程序服务器相
互独立,相互不受影响。文件服务器的功能也相对比较单一,只需要
对文件进行管理即可。
随着图片的数量越来越多,单个图片自身占用的空间越来越大,单台
服务器对于图片的承载压力也越来越大,就需要拓宽服务器的数量,
通过更多的图片服务器存储文件。这样虽然解决了文件的存储问题,
但是却产生了一个新的问题:怎么从这么多的机器中快速的找寻到需
要的那张图片?于是便引申出了分布式存储的概念,在众多的机器之
中,如何讲文件放进去,如何讲文件取出来。
常见的分布式存储框架
什么是 FastDFS
FastDFS
是前阿里的一位大神余庆开源的一个轻量级分布式文件系
统,它对文件进行管理,功能包括:文件存储、文件同步、文件访问
(文件上传、文件下载)等,解决了大容量存储和负载均衡的问题。
特别适合以文件为载体的在线服务,如相册网站、视频网站等等。
FastDFS
为互联网量身定制,充分考虑了冗余备份、负载均衡、线性
扩容等机制,并注重高可用、高性能等指标,使用
FastDFS
很容易搭
建一套高性能的文件服务器集群提供文件上传、下载等服务。
FastDFS
服务端有两个角色:跟踪器(
tracker
)和存储服务器
(
storage
)。跟踪器主要做调度工作,在访问上起负载均衡的作用。
存储服务器存储文件,完成文件管理的所有功能:就是这样的存储、
同步和提供存取接口,
FastDFS
同时对文件的
metadata
进行管理。
所谓文件的
metadata
就是文件的相关属性,以键值对(
key value
)
方式表示,如:
width=1024
,其中的
key
为
width
,
value
为
1024
。
文件
metadata
是文件属性列表,可以包含多个键值对。
很多人可能不太理解为什么要设计
tracker
这个角色,当存储服务器由
很多个物理机器组成时。客户端要上传
/
下载文件的时候,不知道文件
上传
/
下载到哪个具体的机器。于是客户端会先请求
tracker
,
tracker
会返回具体的
group
和
group
中的具体主机信息。客户端拿着这个具
体的主机信息去请求相应的主机进行文件的上传
/
下载。
跟踪器和存储节点都可以由一台或多台服务器构成。跟踪器和存储节
点中的服务器均可以随时增加或下线而不会影响线上服务。其中跟踪
器中的所有服务器都是对等的,可以根据服务器的压力情况随时增加
或减少。
为了支持大容量,存储节点(服务器)采用了分组(或分卷)的组织
方式:
group
。存储系统由一个或多个
group
组成,
group
与
group
之
间的文件是相互独立的,所有
group
的文件容量累加就是整个存储系
统中的文件容量。一个
group
可以由一台或多台存储服务器组成,一
个
group
下的存储服务器中的文件都是相同的,
group
中的多台存储
服务器起到了冗余备份和负载均衡的作用。
在
group
中增加服务器时,同步已有的文件由系统自动完成,同步完
成后,系统自动将新增服务器切换到线上提供服务。当存储空间不足
或即将耗尽时,可以动态添加
group
。只需要增加一台或多台服务器,
并将它们配置为一个新的卷,这样就扩大了存储系统的容量。
FastDFS
中的文件标识分为两个部分:组名和文件名,二者缺一不可。
FastDFS 的安装与部署
FastDFS
开源的地址在
GitHub
上:
https://github.com/happyfish10
0
源码安装要将对应的源码下载后编译运行安装,当然图省事的话可以
直接使用
docker
快速安装。先看使用
docker
的情况下如何快速安
装,毕竟很多人应该对源码编译安装没啥兴趣。
docker
安装
首先,查询
docker
中关于
FastDFS
有哪些可用的镜像:
docker
search fastdfs
选择需要的镜像,拉取到本地:docker pull delron/fastdfs
镜像文件并不大,本身只有 400+M
通过
Docker
命令来创建
Tracker
服务:
docker run -d --name tracker --network=host -v
/mydata/fastdfs/tracker:/var/fdfs delron/fastdfs tracker
tracker
服务默认的端口为
22122
,
-v
实现了
docker
中的容器和本地
目录之间的挂载。所以在执行
docker
命令前应手动先将本地的
/mydata/fastdfs/tracker 目录创建好。
Tracker
服务创建成功之后,继续通过
docker
的命令创建
Storage
服
务:
docker run -d --name storage --network=host -e
TRACKER_SERVER=192.168.29.128:22122 -v
/mydata/fastdfs/storage:/var/fdfs -e GROUP_NAME=group1
delron/fastdfs storage
在执行上面命令的时候要注意对应的修改下,其中
TRACKER_SERVER
中的
IP
要修改为你的
Tracker
服务所在的服务
IP
地址。并且同样的,先手动将
/ mydata/fastdfs/storage
目录创建
好。
默认情况下在
Storage
服务中是已经预装了
Nginx
服务的,相关的端
口为
8888
;
Storage
自身的端口默认是
23000
。当然如果你发现这些
相关的端口被占用了,或者想要对应的修改端口信息也可以,需要进
入容器中查看下相关的配置文件信息。
进入
Storage
服务的容器中:
docker exec -it d4926e8325e3 bash
在容器中的
/etc/fdfs/
目录下找到
storage.conf
配置文件
可以看到在配置文件的最后一行指定了 http 的端口:
除此之外,还得再来到容器中的
/usr/local/nginx/conf
目录下,将
nginx.conf
配置文件中的
8888
端口一并更改:
Tracker
和
Storage
服务安装完成之后,在服务器的
Storage
本地目录
中放几张用于测试上传的图片。因为之前在启动的时候,已经将本地
目录和
docker
目录进行了一个挂载,所以当进入到
docker
中的
Storage
服务中,依然可以看到本地目录中的测试图片:
使用服务原生的
/ usr/bin/fdfs_upload_file
命令进行文件上传:
/usr/bin/fdfs_upload_file /etc/fdfs/client.conf face2face1.jpg
上传成功之后,返回已上传成功的图片信息。这张图片存于
group1
组
中,
/M00/00/00 /
目录下,重命名为
wKgggGSD2feAXsv4AER92Sd_dzk072.jpg
。然后拿着这串图片地
址,使用浏览器访问:
http://192.168.29.128:8888/group1/M00/00/0
0/wKgggGSD2feAXsv4AER92Sd_dzk072.jpg
可以成功拿到这张上传的图片则说明
FastDFS
服务安装成功。因为
Storage
服务中已经安装了
Nginx
服务,所以访问图片的端口就是
Nginx
监听的
8888
端口,经过
Nginx
的代理拿到上传的那张图片。
注意:
如果无法访问照片的路径,可能是
linux
防火墙的问题,把
Nginx
、
storage
、
tracker
的端口打开,再重启镜像服务就好
springboot整合fastdfs
2.4 测试文件上传
从上图中可以,实现了文件的上传和缩略图的生成。
2.5 文件下载