分布式文件存储 FastDFS

一、概念简述

FastDFS 是由淘宝开发平台部资深架构师余庆开发，是一个轻量级、高性能的开源分布式文件系统( Distributed File System ），用纯 C 语言开发，包括文件存储、文件同步、文件访问（上传、下载）、存取负载均衡、在线扩容、相同内容只存储一份等功能，适合有大容量存储需求的应用或系统。

它对文件进行管理，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标。解决了大容量存储和负载均衡的问题。特别适合以中小文件( 建议范围：4KB < file_size <500MB ）为载体的在线服务，如相册网站、视频网站等等具有显著的效果。

同类的分布式文件系统有谷歌的 GFS、HDFS（Hadoop）、TFS（淘宝）等。

二、FastDFS架构

FastDFS 服务端有三个角色：客户端（client），跟踪器（tracker）和存储器（storage）构成。基本架构如下图所示

跟踪器（tracker）

Tracker 是 FastDFS 的 协调者，负责管理所有的 storage server 和 group，每个 storage 在启动后会连接 Tracker，告知自己所属的 group 等信息，并保持周期性的心跳，tracker 根据 storage 的心跳信息，建立 group ==> [storage serverlist] 的映射表。

Tracker 需要管理的元信息很少，会全部存储在内存中；另外 tracker 上的元信息都是由 storage 汇报的信息生成的，本身不需要持久化任何数据，这样使得 tracker 非常容易扩展，直接增加 tracker 机器即可扩展为 tracker cluster 来服务，cluster 里每个 tracker 之间是完全对等的，所有的 tracker 都接受 stroage 的心跳信息，生成元数据信息来提供读写服务。

跟踪器在访问上起负载均衡的作用。可以随时增加或下线而不会影响线上服务。

存储节点（storage）

存储系统（Storage server）由以组 group（或卷 volume）为单位组成。一个 group 内包含多台 storage 机器，数据互为备份，存储空间以 group 内容量最小的 storage为准。

存储节点中的服务器均可以随时增加或下线而不会影响线上服务。

客户端（client）

客户端（client），作为业务请求的发起方，通过专有接口，使用TCP/IP协议与跟踪器服务器或存储节点进行数据交互。

三、FastDFS 的存储策略

为了支持大容量，存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的（同步已有的文件由系统自动完成同步），卷中的多台存储服务器起到了冗余备份和负载均衡的作用。

在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。

当存储空间不足或即将耗尽时，可以 动态 添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。

四、FastDFS 的文件同步

写文件时，客户端将文件写至 group 内一个 storage server 即认为写文件成功，storage server 写完文件后，会由后台线程将文件同步至同 group 内其他的 storage server。

每个 storage 写文件后，同时会写一份 binlog，binlog 里不包含文件数据，只包含文件名等元信息，这份 binlog 用于后台同步，storage 会记录向 group 内其他 storage 同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，所以最好能保证集群内所有 server 的时钟保持同步。

storage 的同步进度会作为元数据的一部分汇报到 tracker 上，tracker 在选择读 storage 的时候会以同步进度作为参考。这样就避免文件同步完成之前访问文件不存在的问题，就是 tracker 会告诉 client 去访问执行存储的那台 storage。

五、FastDFS 整体流程图

从 client 发起请求，由跟踪器（tracker，主）来处理，查询可用的存储器（storage），返回给 client storage 的 ip 和端口；client 根据 ip 和端口访问 storage 完成上传图片等服务；成功后返回地址，如：group1/M00/00/01/wKgBwFkueeWAU81OAADxa3SgCic420.png

六、结合 keepalived

keepalived 概念

keepalived 是以 VRRP（ Virtual Router Redundancy Protocol ）协议为实现基础的，即虚拟路由冗余协议，实现路由器高可用的协议。

工作原理

Keepalived 的作用是检测服务器的状态，如果有一台 web 服务器宕机，或工作出现故障，Keepalived 将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后 Keepalived 自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。

选举制度

将 N 台提供相同功能的路由器组成一个路由器组，这个组里面有一个 master 和多个 backup ，master 上面有一个对外提供服务的 vip（该路由器所在局域网内其他机器的默认路由为该 vip），master 会发组播，当 backup 收不到 vrrp 包时就认为 master 宕掉了，这时就需要根据 VRRP 的优先级来选举一个 backup 当 master。这样的话就可以保证路由器的高可用了。

主从模式

Keepalived 通过请求一个 vip 来达到请求真实 IP 地址的功能，而 VIP 能够在一台机器发生故障时候，自动漂移到另外一台机器上，从来达到了高可用。

一主多从模式：
在当前架构中仅允许存在一台 master，其他均为 backup。当 backup 接收不到 vrrp 消息时，会根据权重来选举一个 backup 出来代替 master。
master 故障恢复后，再次夺回 master。

七、FastDFS插件

• fastdfs-nginx-module：

在大多数业务场景中，往往需要为 FastDFS 存储的文件提供 http 下载服务，而尽管 FastDFS 在其 storage 及 tracker 都内置了 http 服务， 但性能表现却不尽如人意；作者余庆在后来的版本中增加了基于当前主流 web 服务器的扩展模块(包括 nginx/apache )，其用意在于利用 web 服务器直接对本机 storage 数据文件提供 http 服务，以提高文件下载的性能。

• fastdfs_client_php：

FastDFS 的 PHP 扩展，用于和 PHP 进行交互。

FastDFS + Keepalived + Nginx 架构

注意：千万不要使用 kill -9 命令强杀 FastDFS 进程,否则可能会导致 binlog 数据丢失。