亚马逊的 Dynamo

亚马逊的key-value模式的存储平台 Dynamo


Dynamo是亚马逊的key-value模式 的存储平台 ,可用性和扩展性都很好,性能 也不错:读写访问中99.9%的响应时间都在300ms内[1]。

数据 划分
分布式 系统 常 用的哈希算法切分数据,分放在不同的node上。Read操作时,也是根据key的哈希值寻找对应的node。Dynamo使用了Consistent Hashing算法,node对应的不再是一个确定的hash值,而是一个hash值范围,key的hash值落在这个范围内,则顺时针沿ring找,碰 到的第一个node即为所需。

Dynamo对Consistent Hashing算法的改进在于:它放在环上作为一个node的是一组机器(而不是memcached把一台机器作为node),这一组机器是通过同步机制保证数据一致的。

以上图为例,node1其实包含了多台机器,在一个node里宕了一台机或增加一台机,并不影响整个Dynamo对key的寻找。

如果一个ring内的访问量大了,则可以在两个node间加入一个新node以缓解压力,这时会影响到其后继node的hash范围,需要调整数据。假设 一个ring中原本只有node2、node3、node4,在加入新的node1之后,原先从node2查询的部分key将改为从node1查 询,node1和node2中的数据就需要调整,主要是node1从node2中提取出属于它的数据,这样做需要选取性能压力不高的时候。

数据同步
Dynamo的一个node中的同步是由client端来“解决 ”的,使用所谓的(N, R, W)模型,其中,N表示node中机器的总数,R表示一个读请求需要的机器参与总数,W代表一个写请求需要的机器参与总数,这些值由client端配置。

例如,一个node有5台机器(N=5),client发出写请求——广播到5台机,如果收到3个“写完成”的返回消息,即认为写成功 (W=3);client发出读请求——还是广播到5台机,如果收到2个“读完成”的返回消息,即认为读成功(R=2)。对于数据十分重要的应用 (如金融),配置可以为(5, 5, 5),即要求node中所有机器的写都成功;而对于数据读写访问量极高的应用,配置可以为(5, 1, 1)。

通常W不等于N,于是,在某些情况下一个node内的机器上的数据可能会有不一致,这时Dynamo是通过将多个Read的返回结果“合并”来得出最终结果的,使用了所谓Object Version和Vector clock的技术 ,即跟踪一个Object在不同机器上的版本变化,以确保当多个Read请求结果返回不一致时,能够更具其版本信息得出正确的结果。 Dynamo的这种做法是一种折衷,即为了同时保证读和写的效率,写操作不要求绝对同步,而把不同步可能产生的后果推给了读操作。

数据恢复
Dynamo的一个node中一台机器建有一个Merkle Tree,当两台机器不一致时(如一台机器宕机一段时间),通过这个tree结构,可以快速定位不一致的Object来恢复数据。Merkle Tree又叫Hash Tree,它把key分成几个range,每个range算出一个hash值,作为叶子,再一层层合并计算上去,这样,从root开始比较hash值,就 可以快速找到哪几段range中的hash值变化了。

入门 基础
Dynamo的意思是发电机,顾名思义,这一整套的方案 都像发电机一样,源源不断地提供服务 ,永不间断。以下内容看上去有点教条,但基本上如果你要理解原理,这每一项都是必须知道的。[2]

CAP原则
先来看历史,Eric A. Brewer教授,Inktomi公司的创始人,也是berkeley大学的计算机教授,Inktomi是雅虎搜索现在的台端技术核心支持。最主要的是, 他们 (Inktomi公司)在最早的时间里,开始研究分布计算。CAP原则的提出,可以追溯到2000年的时候(可以想象有多么早!),Brewer教授在一 次谈话中,基于他运作Inktomi以及在伯克利大学里的经验,总结出了CAP原则(文末参考资料中有其演讲资料链接)。图一是来自Brewer教授当年 所画的图:

1.jpg

下载 (22.48 KB)
2010-10-17 23:56


图一:CAP原则当年的PPT

Consistency(一致性):即数据一致性,简单的说,就是数据复制到了N台机器,如果有更新,要N机器的数据是一起更新的。
Availability(可用性):好的响应性能,此项意思主要就是速度。
Partition tolerance(分区容错性):这里是说好的分区方法,体现具体一点,简单地可理解为是节点的可扩展性。
定理:任何分布式系统只可同时满足二点,没法三者兼顾。
忠告:架构 师不要将精力浪费在如何设计 能满足三者的完美分布式系统,而是应该进行取舍。

DHT——分布式哈希表
DHT(Distributed Hash Table,分布式哈希表),它是一种分布式存储寻址方法的统称。就像普通的哈希表,里面保存了key与value的对应关系,一般都能根据一个key去对应到相应的节点,从而得到相对应的value。

这里随带一提,在DHT算法中,一致性哈希作为第一个实用的算法,在大多数系统中都使用了它。一致性哈希基本解决了在P2P环境 中最为关键的问题 ——如何在动态的网络 拓扑中分布存储和路由。每个节点仅需维护少量相邻节点的信息,并且在节点加入/退出系统时,仅有相关的少量节点参与到拓扑的维护中。至于一致性哈希的细节就不在这里详细说了,要指明的一点是,在Dynamo的数据分区方式之后,其实内部已然是一个对一致性哈希的改造了。

进入Dynamo的世界
有了上面一章里的两个基础介绍之后,我们开始进入Dynamo的世界。

Dynamo的数据分区与作用
在Dynamo的实现中提到一个关键的东西,就是数据分区。 假设我们的数据的key的范围是0到2的64次方(不用怀疑你的数据量会超过它,正常甚至变态情况下你都是超不过的,甚至像伏地魔等其他类Dynamo系 统是使用的 2的32次方),然后设置一个常数,比如说1000,将我们的key的范围分成1000份。然后再将这1000份key的范围均匀分配到所有的节点(s个 节点),这样每个节点负责的分区数就是1000/s份分区。

如图二,假设我们有A、B、C三台机器,然后将我们的分区定义了12个。

2.jpg

下载 (10.15 KB)
2010-10-17 23:56


图二:三个节点分12个区的数据的情况

因为数据是均匀离散到这个环上的(有人开始会认为数据的key是从1、2、3、4……这样子一直下去的,其实不是的,哈希计算出来的值,都是一个离散的结 果),所以我们每个分区的数据量是大致相等的。从图上我们可以得出,每台机器都分到了三个分区里的数据,并且因为分区是均匀的,在分区数量是相当大的时 候,数据的分布会更加的均匀,与此同时,负载也被均匀地分开了(当然了,如果硬要说你的负载还是只集中在一个分区里,那就不是在这里要讨论的问题了,有可 能是你的哈希函数 是不是有什么样的问题了)。

为什么要进行这样的分布呢,分布的好处在于,在有新机器加入的时候,只需要替换原有分区即可,如图三所示:

3.jpg

下载 (13.34 KB)
2010-10-17 23:56


图三:加入一个新的节点D的情况

同样是图二里的情况,12个分区分到ABC三个节点,图三中就是再进入了一个新的节点D,从图上的重新分布情况可以得出,所有节点里只需要转移四分之一的 数据到新来的节点即可,同时,新节点的负载也伴随分区的转移而转移了(这里的12个分区太少了,如果是1200个分区甚至是12000个分区的话,这个结 论就是正确的了,12个分区只为演示用)。
从Dynamo的NRW看CAP法则
在Dynamo系统中,第一次提出来了NRW的方法。
N:复制的次数;
R:读数据的最小节点数;
W:写成功的最小分区数。

这三个数的具体作用是用来灵活地调整Dynamo系统的可用性与一致性。

举个例子来说,如果R=1的话,表示最少只需要去一个节点读数据即可,读到即返回,这时是可用性是很高的,但并不能保证数据的一致性,如果说W同时为1的 话,那可用性更新是最高的一种情况,但这时完全不能保障数据的一致性,因为在可供复制的N个节点里,只需要写成功一次就返回了,也就意味着,有可能在读的 这一次并没有真正读到需要的数据(一致性相当的不好)。如果W=R=N=3的话,也就是说,每次写的时候,都保证所有要复制的点都写成功,读的时候也是都 读到,这样子读出来的数据一定是正确的,但是其性能大打折扣,也就是说,数据的一致性非常的高,但系统的可用性却非常低了。如果R + W > N能够保证我们“读我们所写”,Dynamo推荐使用322的组合。

Dynamo系统的数据分区让整个网络的可扩展性其实是一个固定值(你分了多少区,实际上网络里扩展节点的上限就是这个数),通过NRW来达到另外两个方 向上的调整。

Dynamo的一些增加可用性的补救
针对一些经常可能出现的问题,Dynamo还提供了一些解决的方法。
第一个是hinted handoff数据的加入:在一个节点出现临时性故障时,数据会自动 进入列表中的下一个节点进行写操作,并标记为handoff数据,在收到通知需要原节点恢复时重新把数据推回去。这能使系统的写入成功大大提升。
第二个是向量时钟来做版本控制:用一个向量(比如说[a,1]表示这个数据在a节点第一次写入)来标记数据的版本,这样在有版本冲突的时候,可以追溯到出 现问题的地方。这可以使数据的最终一致成为可能。(Cassandra未用vector clock,而只用client timestamps也达到了同样效果。)
第三个是Merkle tree来提速数据变动时的查找:使用Merkle tree为数据建立索引,只要任意数据有变动,都将快速反馈出来。
第四个是Gossip协议:一种通讯协议,目标是让节点与节点之间通信,省略中心节点的存在,使网络达到去中心化。提高系统的可用性。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值