架构设计：文件服务存储设计

在架构设计：文件服务的设计与实现一文中，经过实现一个文件服务来梳理了一个架构设计的通常流程，并获得以下静态架构图

本文继续聊聊文件服务中的子模块：「存储模块」的设计，包括：

• 引入「存储模块」后的架构调整
• 本地文件存储
• libfuse
• RAID
• 分布式文件存储

架构调整

前面的架构没有对存储进行特别设计，直接使用了本地存储。考虑到后期文件数量可能会愈来愈多，本地存储可能没法支撑，且本地存储的安全性也没有保障。为了便于后期扩展，须要对「存储」部分进行设计。

存储的方式有不少，本地存储、NAS、分布式存储，为了能支持不一样的存储方式，须要对「存储模块」进行抽象。考虑到「存储模块」涉及到IO，是一个相对底层的模块。「上传」这个核心模块不能依赖于具体的存储，因此这里也须要对其进行依赖反转。

见紫色部分，UploadService调用了FileInfoRepository来存储FileInfo，而FileInfoRepository是个接口，具体实现由存储模块中的实现类来实现。

public interface FileInfoRepository {
 public Path save(FileInfo fileInfo) throws IOException;
}
public class LocalFileInfoRepository implements FileInfoRepository {
 public Path save(FileInfo fileInfo) throws IOException {
 ...
 }
}
public class NASFileInfoRepository implements FileInfoRepository {
 public Path save(FileInfo fileInfo) throws IOException {
 ...
 }
}
public class DistributedFileInfoRepository implements FileInfoRepository {
 public Path save(FileInfo fileInfo) throws IOException {
 ...
 }
}
复制代码

本地存储

咱们先看本地存储。最简单的实现，就是直接使用IO将文件写到对应的目录下就能够了。可是，本地存储会有以下几个问题：

• 若是文件服务支持多租户，全部租户文件都写在同一个目录下，没有作区分，可能致使文件混乱，迁移繁琐。且文件数量增长会比较快。
• 随着文件数量的增多，某些文件系统的访问速度可能会降低
• 文件数增长，单机磁盘可能容量不够
• 没有容错和备份，磁盘损坏可能致使数据的永久丢失

下面咱们针对上面的问题，来一个个的解决。

多租户

首先，对于多租户来讲，在咱们的架构中，实际对应的是Group，咱们按照Group的不一样，来划分目录便可。即不一样的租户有不一样的文件根目录，后期某个租户迁移时，直接迁移对应目录便可。这也稍微解决了单目录文件数量多的问题。

单目录文加数量过多

对于单目录下，随着文件数量的增长致使访问速度降低的问题，咱们该如何解决呢？

若是你作过度布式系统，那么想想，咱们是否能够把单目录当作是一个服务器，访问目录下的文件当作是一个个的请求呢？若是能够，那解决单目录下访问速度慢的问题是否是就变成了「如何解决单服务器下，负载太高」的问题了？那解决服务端负载太高的方法是否适用于解决目录访问速度降低的问题呢？

咱们从下面几个方面来分析一下：

• 解决服务端负载太高的方法
• 目录访问和服务器的区别
• 解决服务端负载太高的方法对目录的适用性

首先来看「解决服务端负载太高的方法」！答案很明显：分流+负载均衡！

分布式服务的负载均衡有几种方式呢？

• 随机
• 轮询
• 加权随机
• 加权轮询
• 源地址Hash
• 一致性Hash

再来看「目录访问和服务器的区别」，虽然能够把目录当作服务器，可是二者仍是有区别的：

• 部署一个服务要花费较长的时间，启动服务最快也要几秒钟，且须要额外的硬件
• 而目录是系统基本功能，建立目录很是的快速，只要磁盘够，建立目录基本没有任何限制

也就是说，对于目录来讲，咱们不须要考虑建立成本。

那么针对服务器负载高的解决方案是否适合目录访问呢？或者哪一种方式适合目录访问呢？咱们一个个来分析：

• 随机：在建立文件时，咱们随机的选择一个目录进行建立。那么问题来了，咱们一开始该建立多少目录呢？新增目录后，是否须要调整程序？由于随机基数变了。对于服务来讲，一开始须要作容量规划，肯定有几个服务，由于建立一个服务的成本仍是挺高的，比重启服务的成本要高很多。可是建立目录的成本却很是的低，初期先肯定目录数量的方式并不合适。
• 轮询：问题和随机相似。
• 加权随机：同随机
• 加权轮询：同轮询
• 源地址Hash：对于服务来讲是对源地址hash，对文件来讲，能够对文件进行hash。hash完如何与目录进行匹配呢？
• 一致性Hash：同上

能够看到，主要的问题就是建立目录的问题！如何保证在目录数量改变时，不须要调整程序呢？

实际上git已经给出了答案：

• 对文件内容取sha1散列
• 获得的散列值的前两位做为目录
• 目录不存在就新建
• 若是已存在就直接保存
• 后面的散列值做为文件名

也就是说，根据sha1散列的前两位对文件进行归类。这样既解决了目录建立问题，也解决了文件分布问题。可能的问题是，「sha1散列2^80次，可能会发生一次碰撞」。这个问题对于通常文件系统来讲，好像也没有担忧的必要。

数据安全

解决了「单目录文件过多，致使访问速度降低」的问题，咱们来看下一个问题：数据安全。

文件数据是存放在电脑磁盘上的，若是硬盘损坏，可能致使文件的丢失。这实际仍是一个「单点问题」！

「单点问题」的解决方案是什么呢？冗余啊！

最简单的方案就是定时去备份数据，能够有以下几种方案：

• 人工备份
• 代码实现
• libfuse
• RAID

咱们继续一个个的讨论。

人工备份

首先是人工备份，这是最low的方案，固然也是最简单的，即有人按期去备份就好了。问题是时效性不高，例如一天备份一次，若是磁盘在备份前坏了，那就会丢失一天的数据。同时恢复比较耗时，须要人工处理。

代码实现

第二个方案是代码实现，即在上传文件时，程序就自动备份。以上面的架构为例，能够添加一个BackupListener，当上传完成后，经过事件，自动备份上传的文件。同时下载时须要断定文件是否完整，若是有问题则使用备份数据。此方案时效性获得了保障，可是将数据备份和业务放到了一块儿，且须要编码实现，增长了业务代码量。

libfuse

第三个方案是libfuse，libfuse是用户态文件系统接口。下面是libfuse官方简介：

FUSE (Filesystem in Userspace)是一个构建用户态文件系统的接口。libfuse项目包括两个组件：一个fuse内核模块以及libufuse用户态库。libfuse用户态库提供了与FUSE内核模块的通信实现。

经过libfuse能够实现一个用户态文件系统。libfuse提供方法，支持挂载文件系统、取消挂载文件系统、读取内核请求及做出响应。lifuse提供了两类API：高层级的同步API和低层级的异步API。不过不管哪一种方式，内核都是经过回调的方式和主程序通信。当使用高层级API的时候，回调基于文件名和路径而不是索引节点（inodes），而且回调返回后这个进程也同时结束；当使用低层级API的时候，回调基于索引节点（inodes）工做而且响应必须使用独立的API方法返回。

简单来讲，就是能够用libfuse构建一个用户态文件系统。以前在老东家作了一个日志分析平台，日志的收集就使用了libfuse，大体架构以下：

业务系统写日志到挂载的用户态文件系统中，用户态文件系统自动转发到了后续的处理中间件：redis、消息队列、文件系统。

在这里也能够用相似的功能，即在文件上传后，用户态文件系统自动备份。此方案解耦了文件备案逻辑与业务逻辑。

RAID

最后一个方案是RAID，即廉价冗余磁盘阵列。RAID不但可备份文件，还支持并发读写，提升上传下载速率。

经常使用的RAID有：RAID0，RAID1，RAID01/RAID10，RAID5和RAID6等。咱们来看看这几种RAID的特色，以及是否适用于咱们的文件服务。你会发现从RAID0到RAID6，又是一个从单点到分布式的过程。

具体RAID相关内容可参考wiki，文末有连接！

• RAID 0：至关因而一个支持并发的单点应用。就是将两个以上的磁盘并联起来，成为一个大容量的磁盘。同时在存放数据时，将数据分段后分散存储在这些磁盘中。这样就能并行的处理读写，提升了读写速度。可是没有数据冗余和容错能力，假如一个磁盘坏了，那全部数据都会丢失。也就是说RAID0只起到了扩容和提升读写速度的做用。就咱们的文件服务来讲，选RAID0确定是不合适的，由于最重要的数据安全没有获得保障，它比单磁盘的数据安全还要差！
• RAID 1：至关因而个单线程的主从应用。将磁盘分为两组，一组工做磁盘、一组镜像磁盘。当写入时，同时写工做磁盘和镜像磁盘，因此写入速度上会比RAID0慢一点。当一个工做磁盘坏了，能够用镜像磁盘。RAID1提供了数据安全保障，性能也足够高。缺点就是利用率低，只用了磁盘的50%。不过对于通常场景来讲，RAID1是个不错的选择。咱们的文件服务也能够选择RAID1
• RAID10/RAID01是RAID0和RAID1的组合
• RAID10：至关因而支持并发的集群应用。即先对数据备份，而后数据被分段写入
• RAID01：至关因而支持并发的分布式系统。即先将数据分段，而后对分段数据备份写入

看下面的两张图应该能更好的理解：

不管是RAID10仍是RAID01，对磁盘的使用效率都不高。那如何提升磁盘使用率呢？就有了RAID3。

• RAID3：至关于有注册中心的分布式系统。RAID3的一个前提是，通常状况下，磁盘不会同时坏两个。因此RAID3使用一个磁盘记录校验数据，其它盘做为数据盘，写入数据时，将数据分为n-1份，写到数据盘中，将校验数据写入校验盘。当其中一个磁盘损坏了，能够经过校验盘和其它数据盘来恢复数据。RAID3读取速度很快，可是写入时由于要计算校验值，因此较慢。适合读多写少的状况。咱们的文件服务恰好是这样的场景，因此也适合RAID3。可是眼尖的朋友确定已经发现问题了，这里有个单点问题，就是校验盘。由于校验盘读写次数明显大于数据盘，损坏的概率也就更大，频繁更换校验盘，重建校验数据也是一件很麻烦的事情。那怎么解决这个问题呢？
• RAID5：经过将校验数据也分散到各个磁盘中来解决这个问题。RAID5至关因而去中心化的分布式系统。当一个磁盘损坏时，能够经过其它磁盘的数据和校验数据来恢复该磁盘的数据和校验数据。和RAID3一样的问题，重建数据速度比较慢，同时对于多个磁盘同时损坏的状况也无能为力。RAID5也一样适用于咱们的文件服务。
• RAID 6：至关于融合了注册中心和去中心化的分布式系统，也能够说有两套注册中心的分布式系统。它在RAID5的基础上增长了两个校验盘，以另外一种校验算法来进行校验。当磁盘损坏时，经过其它数据盘的数据和校验数据以及校验盘的校验数据来恢复数据。RAID6能恢复两块磁盘同时损坏状况下的数据，相应的其写入数据更慢，实现难度也更高。除非数据安全要求很高，通常不经常使用。

对于本地存储来讲，RAID是个相对实用的解决方案，既能提升数据安全、快速扩容，也提升了读写速率。可是不管扩展多少磁盘，容量仍是相对有限，吞吐也相对有限，同时因为其仍是单点，若是文件服务自己挂掉，就会致使单点故障。因此就有了分布式文件系统。

分布式文件系统下次单独讨论！

参考资料

• libfuse：github.com/libfuse/lib…
• wiki RAID：zh.wikipedia.org/wiki/RAID
• 《Git版本控制管理》
• 《操做系统概念》

架构设计：文件服务存储设计