磁盘阵列和存储服务器的区别在于性质不同、用途不同、组成不同。
1、性质不同
磁盘阵列是一种方法,存储服务器是物理设备。独立磁盘冗余阵列是把相同的数据存储在多个硬盘的不同的地方的方法。存储服务器是指为特定目标而设计,因此配置方式也不同。它可能是拥有一点额外的存储,也可能拥有很大的存储空间的服务器。
2、用途不同
存储服务器用于提供存储数据的服务,RAID技术用于高了数据存取速度、实现了对数据的冗余保护。
3、组成不同
磁盘阵列通过把数据放在多个硬盘上,输入输出 *** 作能以平衡的方式交叠,改良性能。因为多个硬盘增加了平均故障间隔时间,储存冗余数据也增加了容错。
存储服务器
存储服务器通常是独立的单元,有的时候它们会被设计成4U机架式,或者也可以由两个箱子组成一个存储单元以及一个位于附近的服务器。
存储服务器是指为特定目标而设计,因此配置方式也不同。它可能是拥有一点额外的存储,也可能拥有很大的存储空间的服务器。
有的人认为存储服务器就是在服务器上附加一些特性,也有一些人把它定义为一种专门面向特定功能的简装箱,还有的人则认为这个术语应该是特指NAS设备。
这里我们将尝试给存储服务器一个严格的定义,将它与普通服务器区分开来,同时也列举市场上一些存储服务器的实例。
在架构设计:文件服务的设计与实现一文中,通过实现一个文件服务来梳理了一个架构设计的一般流程,并得到如下静态架构图
本文继续聊聊文件服务中的子模块:「存储模块」的设计,包括:
前面的架构没有对存储进行特别设计,直接使用了本地存储。考虑到后期文件数量可能会越来越多,本地存储可能无法支撑,且本地存储的安全性也没有保障。为了便于后期扩展,需要对「存储」部分进行设计。
存储的方式有很多,本地存储、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多个徒弟,技术杠杠的!
数据库服务器依赖于存储服务器的数据,这意味着数据库数据文件被放置在存储服务器上。
数据以记录的形式存储在数据库中;数据库将数据作为文件存储在存储服务器上。
数据库服务器由在局域网和数据库管理系统软件中运行的一台或多台计算机组成,数据库服务器为客户端应用程序提供数据服务。存储服务器是为特定目标设计的,因此配置也不同。它可能是一个稍有额外存储空间的服务器,或者它可能有很多存储空间。
扩展资料:
数据库服务器特征:
1、编程量减少
数据库服务器提供了用于数据 *** 纵的标准接口API(Application Programming Interface,应用程序编程接 口)。
2、数据库安全高
数据库服务器提供监控性能、并发控制等工具。由DBA(Database Administrator,数据库管理员)统一负 责授权访问数据库及网络管理。
3、数据可靠性管理
数据库服务器提供统一的数据库备份/恢复、启动/停止数据库的管理工具。
4、计算机资源利用充分
数据库服务器把数据管理及处理工作从客户机上分离出来,使网络中各计算机资源能灵活分配、各尽其用。
参考资料来源:百度百科-存储服务器
参考资料来源:百度百科-数据库服务器
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)