海量存储之十四

这一次,我们来讲讲数据安全和读写高可用


oh no,亲,于是我们又掉入了CAP所描述的陷阱。好吧,那么我们也就进入这个领域,来看看这数据安全所代表的一切。


在20年以前,数据安全对于大部分用户来说,只意味着数据库ACID中的”D”,数据写入到数据库,并返回成功后,这个数据也就是安全的了,在老师教给我们的计算机原理课上,似乎最多也就讲到,数据库有冷备份,也有热备份,因此写入数据库内的数据是安全的。


然而,真的如此么?



最简单的问题,就是,如果这台机器的硬盘挂掉,那应该怎么办呢?


于是,有些人就想到,那我们用多块硬盘来备份不就好了?于是,RAID技术就应运而生了。Raid技术的核心,就是利用磁盘阵列的手段,提升数据的写入效率和安全性。


那么,raid也不是完美的,首先,磁盘放在机器上,这机器的磁盘就不可能无限增加的。单机的磁盘容量受到磁盘架个数的限制。


于是,有一些人就想到:那我们就专门的设计一种可以挂无数磁盘的柜子来好了。这就是盘柜技术的产生,关键词 SAN,不过这东西不是我们要讨论的东西,所以我们就不在这里细说了。


但因为盘柜技术本身有其优势也有一定的局限性,所以目前这套东西不大为人所知了。


似乎所有人谈起存储必谈GFS,HDFS…但其实个人认为在原教旨主义的文件系统上,更多的依靠硬件的盘柜,也不失为一套非常好的解决方案。


正所谓分久必合合久必分,目前Oracle携ExtraData 一体机技术在市场上杀的风生水起,不也是盘柜技术的新时代体现么?呵呵。。


好了,废话不多扯,盘柜在目前不大容易成为主流,主要原因是


1. 冗余容错性不好
2. 价格较贵
3. 核心技术把持在大公司手里
Etc.


那么,既然盘柜技术不大容易成为主流,那么目前的主流是什么呢?


这就是多机的同步技术,利用廉价的tcp/ip网络,将多台pc server联系到一起,使用软件逻辑而非硬件逻辑来进行数据的多磁盘备份。


这其实就已经涉及到了问题的核心:什么是数据安全和数据高可用?我们将数据安全的级别从低到高,做成表格列在下面。



           


可见,从目前来看,解决数据安全的唯一办法是将数据同步的写到多个不同的地方(可以是用raid5的方式写,也可以用raid10的方式,不过核心都是一个— 冗余。
 
而且不能简单的就用单机的冗余,必须要多机冗余才靠得住。
 
如果要最安全,那么数据就要同步的复制多机。
 


下面,我们就专注于这同步复制多机的case,来看看目前我所知的几种常见的,以解决高可用为基础的数据冗余方案吧。
 


需要强调的是,这些方案本身,没有绝对的一家独大之说,每一种方案,都有其自己的特性和适用场景,所以不存在某一种方案一定比其他方案好的这种说法,每一种模式都有其自己的优势和劣势。


所谓可用性,就是尽可能的保证,无论发生什么变故,数据库都能够正常的提供读写访问的这种方式。


而所谓安全性,就是尽可能的保证,无论发生什么变故,数据库内,持久化的数据都不会丢失。


这里的数据丢失,其实是个很宽泛的词汇,为了表达的更为清楚,我们需要仔细的描述一个最关键的问题:什么时候能够叫做“数据写入成功”,换句话说,也就是,数据存储系统,与前端的无状态调用者之间的承诺关系是什么呢?


认清这个问题,对于我们定义数据安全,至关重要。


从一个请求走到网络,提交给存储系统的过程,细化下来可以认为是以下几个动作的分解:
 

             



可以认为,在时间线上来说,所有的这些操作都可能出现!异常!,导致写失败。这里又涉及到以前我们提到的网络三种反馈状态问题了,让我分阶段来进行讨论:


A. 客户端发起请求出现失败 -> 客户端明确的知道自己失败,所以所有操作都未进行,对整个系统的一致性没有影响。


B. 发起请求后,因为网络因素,导致请求未被server接受 -> 客户端等待,直到超时,但Server未接受请求。客户端应认为失败。


C. Server端接受到写入请求,但内部操作失败-> Server端应该保证操作的原子性,并反馈client操作失败。


D. Server端一系列操作成功,反馈Client,但因为网络异常导致Client无法接收请求 ->Server端成功,但Client端等待超时,则client端对操作有疑问。


E. Client端收到Server端反馈的成功 -> 认为成功。


可以认为,只有最后一步成功的时候,才算做成功,而其他操作,因为网络因素导致的异常,都认为是失败的。


从上面的分析中可以看出,存储对于完整性的保证,只存在于E步骤成功时。


而client端能明确的知道操作失败的,是A,,C场景。


Client端不能明确知道操作成功或失败的,是B,D,场景,需要人工验证,或默认丢超时异常,并被认为是失败。


而我们所定义的数据安全性,就是指,当E完成时,也就是Server对client端反馈成功时,则数据在各种变故出现时,所能保证的完整性的一种体现( T_T ..真绕。。。)


而我们要在后面,花费大量篇幅来讨论的,就是“进行一系列操作处理”这个过程,如何能保证数据的完整性的问题。


因为篇幅的关系,今次就介绍第一种,也是最简单的一种,使用异步复制队列的方式来提升可用性和安全性吧。


这是所有数据存储中基本都提供的一种模式,而大部分的其他方案的核心和基础都是这个异步的复制的模型的权衡版本。所以,我们就从这里开始。


要讲清这个问题,我们先来看一张图
 

                  


 
所谓异步传输,简单来说就是数据写入主机后,不等待其他机器反馈结果请求,直接反馈用户写入成功的一种策略。
 


好处:


数据写入速度快(因为只需要保证一台机器写成功,那么就算成功了)。


副作用:


如果主机写了位置102,但备机还没来得及收102的数据到备机,这时候主机down机。数据实际上还未写入备机呢。于是就出现了数据丢失。


好,就到这里。。下次我们来讨论,在这种情况下,如何能够保证可用性。

个人资料
0_0
等级:7
文章:111篇
访问:5.0w
排名: 6
上一篇: 一个状态模式的小改进
下一篇:索引与优化like查询
猜你感兴趣的圈子:
阿里中间件技术交流圈
标签: 盘柜、数据安全、client、成功、失败、面试题
隐藏