架构设计:文件服务存储设计
发布网友
发布时间：2022-11-19 15:17
共1个回答
热心网友
时间：2024-07-27 08:57
在架构设计：文件服务的设计与实现一文中，通过实现一个文件服务来梳理了一个架构设计的一般流程，并得到如下静态架构图
本文继续聊聊文件服务中的子模块：「存储模块」的设计，包括：
前面的架构没有对存储进行特别设计，直接使用了本地存储。考虑到后期文件数量可能会越来越多，本地存储可能无法支撑，且本地存储的安全性也没有保障。为了便于后期扩展，需要对「存储」部分进行设计。
存储的方式有很多，本地存储、NAS、分布式存储，为了能支持不同的存储方式，需要对「存储模块」进行抽象。考虑到「存储模块」涉及到IO，是一个相对底层的模块。「上传」这个核心模块不能依赖于具体的存储，所以这里也需要对其进行依赖反转。
见紫色部分，UploadService调用了FileInfoRepository来存储FileInfo，而FileInfoRepository是个接口，具体实现由存储模块中的实现类来实现。
我们先看本地存储。最简单的实现，就是直接使用IO将文件写到对应的目录下就可以了。但是，本地存储会有如下几个问题：
下面我们针对上面的问题，来一个个的解决。
首先，对于多租户来说，在我们的架构中，实际对应的是Group，我们按照Group的不同，来划分目录即可。即 不同的租户有不同的文件根目录 ，后期某个租户迁移时，直接迁移对应目录即可。这也稍微解决了单目录文件数量多的问题。
对于单目录下，随着文件数量的增加导致访问速度下降的问题，我们该如何解决呢？
如果你做过分布式系统，那么想一想， 我们是否可以把单目录看成是一个服务器，访问目录下的文件看成是一个个的请求呢 ？如果可以，那解决单目录下访问速度慢的问题是不是就变成了「如何解决单服务器下，负载过高」的问题了？那解决服务端负载过高的方法是否适用于解决目录访问速度下降的问题呢？
我们从下面几个方面来分析一下：
首先来看「解决服务端负载过高的方法」！答案很明显： 分流+负载均衡 ！
分布式服务的负载均衡有几种方式呢？
再来看「目录访问和服务器的区别」，虽然可以把目录看成服务器，但是两者还是有区别的：
也就是说，对于目录来说，我们不需要考虑创建成本。
那么针对服务器负载高的解决方案是否适合目录访问呢？或者哪种方式适合目录访问呢？我们一个个来分析：
可以看到，主要的问题就是创建目录的问题！如何保证在目录数量改变时，不需要调整程序呢？
实际上git已经给出了答案：
也就是说，根据sha1散列的前两位对文件进行归类。这样既解决了目录创建问题，也解决了文件分布问题。可能的问题是，「sha1散列2^80次，可能会发生一次碰撞」。这个问题对于一般文件系统来说，好像也没有担心的必要。
解决了「单目录文件过多，导致访问速度下降」的问题，我们来看下一个问题： 数据安全 。
文件数据是存放在电脑磁盘上的，如果硬盘损坏，可能导致文件的丢失。这实际还是一个「单点问题」！
「单点问题」的解决方案是什么呢？ 冗余 啊！
最简单的方案就是定时去备份数据，可以有如下几种方案：
我们继续一个个的讨论。
首先是 人工备份 ，这是最low的方案，当然也是最简单的，即有人定期去备份就行了。问题是时效性不高，例如一天备份一次，如果磁盘在备份前坏了，那就会丢失一天的数据。同时恢复比较耗时，需要人工处理。
第二个方案是 代码实现 ，即在上传文件时，程序就自动备份。以上面的架构为例，可以添加一个BackupListener，当上传完成后，通过事件，自动备份上传的文件。同时下载时需要判定文件是否完整，如果有问题则使用备份数据。此方案时效性得到了保障，但是将数据备份和业务放到了一起，且需要编码实现，增加了业务代码量。
第三个方案是 libfuse ，libfuse是用户态文件系统接口。下面是libfuse官方简介：
简单来说，就是可以用libfuse构建一个用户态文件系统。之前在老东家做了一个日志分析平台，日志的收集就使用了libfuse，大致架构如下：
业务系统写日志到挂载的用户态文件系统中，用户态文件系统自动转发到了后续的处理中间件：redis、消息队列、文件系统。
在这里也可以用类似的功能，即在文件上传后，用户态文件系统自动备份。此方案解耦了文件备案逻辑与业务逻辑。
最后一个方案是 RAID ，即廉价冗余磁盘阵列。RAID不但可备份文件，还支持并发读写，提高上传下载速率。
常用的RAID有：RAID0，RAID1，RAID01/RAID10，RAID5和RAID6等。我们来看看这几种RAID的特点，以及是否适用于我们的文件服务。你会发现从RAID0到RAID6，又是一个从单点到分布式的过程。
看下面的两张图应该能更好的理解：
无论是RAID10还是RAID01，对磁盘的使用效率都不高。那如何提高磁盘使用率呢？就有了RAID3。
对于本地存储来说，RAID是个相对实用的解决方案，既能提高数据安全、快速扩容，也提高了读写速率。但是无论扩展多少磁盘，容量还是相对有限，吞吐也相对有限，同时由于其还是单点，如果文件服务本身挂掉，就会导致单点故障。所以就有了分布式文件系统。
分布式文件系统下次单独讨论！
最后打个广告，帮朋友开的专栏《零基础Unity3D 游戏 开发》，适合没有基础、想从事 游戏 开发的小白！朋友从事 游戏 多年，开发了多款 游戏 ，收了30多个徒弟，技术杠杠的！
