围绕RAID的基本想法就是把多个便宜的小磁盘组合到一起，成为一个磁盘组式的逻辑硬盘，因此， *** 作系统仅把它们看作一个单一的逻辑存储单元或磁盘。通过这种手段使逻辑硬盘的性能达到或超过一个容量巨大、价格昂贵的磁盘。RAID常被用在服务器计算机上，并且常使用完全相同的硬盘作为组合。由于硬盘价格的不断下降与和RAID功能更加有效地与主板整合，它也成为了高级最终用户的一个选择，特别是需要大量存储的工作，如：视频与音频制作。
利用如磁盘条纹化 (RAID 0) 和 磁盘镜像 (RAID 1) 的技巧，把数据分布到各个磁盘上,来达到亢余性、低延迟、读写的高带宽、硬盘毁坏后的最大可恢复性。
采用 RAID 的主要原因是:
1、增强了速度
2、扩容了存储能力(以及更多的便利)
3、可高效恢复磁盘
有两种可以实现RAID的方法：硬RAID和软RAID。
最初的RAID分成了不同的等级，每种等级都有其理论上的优缺点。这些年来，出现了对于RAID观念不同的应用。
参考>1 直接附加存储:解决方案允许硬盘支持瞬时安全擦除功能,可以在数秒内彻底擦除、销毁数据,使硬盘下线或再利用变得更便捷。直接连接到PC或服务器,典型地
2 网络连接存储:NAS设备是直接连接到网络的存储设备。它具有一个文件服务器的服务员能力和接受多个存储驱动器。冗余是在RAID功能的形式提供的,因为NAS支持多
3 灾难保护的存储:顾名思义,灾难
冗余服务器是指重复配置系统的一些部件。
当系统发生故障时，冗余配置的部件介入并承担故障部件的当系统发生故障时，比如某一设备发生损坏，冗余配置的部件可以作为备援，及时介入并承担故障部件的工作，由此减少系统的故障时间。
冗余尤用于应急处理。冗余可以存在于不同层面，如网络冗余、服务器冗余、磁盘冗余、数据冗余等。
扩展资料
在服务器里，冗余系统配件主要有：
1、电源：高端服务器产品中普遍采用双电源系统，这两个电源是负载均衡的，即在系统工作时它们都为系统提供电力，当一个电源出现故障时，另一个电源就承担所有的负载。
2、RAID：廉价冗余磁盘阵列，顾名思义，它由几个磁盘组成，通过一个控制器协调运动机制使单个数据流依次写入这几个磁盘中。
3、 I/O卡：对服务器来说，主要指网卡和硬盘控制卡的冗余。网卡冗余是在服务器中插上双网卡。冗余网卡技术原为大型机及中型机上的技术，现在也逐渐被PC服务器所拥有。
4、CPU：系统中主处理器并不会经常出现故障，但对称多处理器（SMP）能让多个CPU分担工作以提供某种程度的容错。
5、风扇冗余：风扇冗余是指再服务器的关键发热部件上配置的降温风扇有主用和备用两套，这两套风扇具有自动切换功能。
在架构设计：文件服务的设计与实现一文中，通过实现一个文件服务来梳理了一个架构设计的一般流程，并得到如下静态架构图
本文继续聊聊文件服务中的子模块：「存储模块」的设计，包括：
前面的架构没有对存储进行特别设计，直接使用了本地存储。考虑到后期文件数量可能会越来越多，本地存储可能无法支撑，且本地存储的安全性也没有保障。为了便于后期扩展，需要对「存储」部分进行设计。
存储的方式有很多，本地存储、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多个徒弟，技术杠杠的！
冗余就是超出需要量的多余部分，在服务器中起到后备的作用，以防某部件故障就影响到系统整体运行。简单的就是服务器磁盘需要使用RAID
1，RAID
5等RAID配置，在一块磁盘故障时不会影响到系统运行与数据安全。再进一步则有冗余的IO服务器等
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）