`

Amazon Dynamo的NWR模型

阅读更多

Amazon Dynamo的NWR模型,把CAP的选择权交给了用户,让用户自己选择CAP中的哪两个。

 

N代表N个副本(replication),W代表写入数据时至少要写入W份副本才认为成功,R表示读取数据时至少要读取R份副本。对于R和W的选择,要求W+R > N。 

 

优化写性能(AP)

当我们需要优化写性能(写多读少)的时候,可以配置W = 1 (写完一个副本就成功,其他的副本就异步去慢慢复制都可以),如果N=3,那么根据公式W+R>N,则R = 3(读取数据的时候需要读3个副本以判断数据是否有冲突)。 这种情况只要写任何节点成功就认为成功,但是读的时候必须从所有的节点都读出数据。

 

优化读性能(CP)

当我们需要优化读性能(读多写少)的时候,可以配置 W=N(写完所有的副本才成功,只能同步复制),根据公式W+R>N,则 R=1(只需读一个副本即可)。这种情况任何一个节点读成功就认为成功,但是写的时候必须写所有三个节点成功才认为成功。

 

平衡读写性能(AC)

当我们数据不多,单台能搞定,且不需要容错和扩展性的时候,可以配置N=1(只有一份数据),根据公式W+R>N,则W=1,R=1。这种情况就简化为单机问题了。

 

 

多个线程会同时更新一份数据,在这种情况下怎么保证一致性?

 

Amazon Dynamo使用多版本并发控制,即乐观锁。如果用户A读出来的数据的版本是v1,当用户A计算完成后要更新数据时,却发现数据的版本号已经被更新成了v2,那么服务器就会拒绝更新导致更新失败,这时候就需要用户A自己处理冲突,方法为:重新读取v2数据,然后重新计算,重新更新。这里跟在svn提交代码发生冲突的情况是一样的,svn提交代码遇到冲突,需要先更新代码,解决冲突之后才能再次提交。

 

如何发现不同节点上面的副本不一致?

 

还有更糟糕的时候(W=1),用户A更新一个副本,在A的更新还没有异步复制到其他副本之前,如果用户B也更新了其他副本,那么数据就处于不一致的状态了,同样需要用户自己处理。

  

Amazon  Dynamo使用Vector Clock向量时钟)。每个节点各自记录自己的版本信息,包括:1)更新数据的节点名称,2)版本号

 

如下所示,有A、B和C三个节点,W=1,R=N=3:

 

  1. 节点A写了两次)一个写请求,第一次被节点A处理了。节点A会增加一个版本信息(A,1)。我们把这个时候的数据记做D1(A,1)。 然后另外一个对同样key的请求还是被节点A处理了于是有D2(A,2)。这个时候,D2是可以覆盖D1的,不会有冲突产生。
  2. 节点A的数据成功异步复制到节点B和节点C,节点A、节点B、节点C处于一致)现在我们假设D2异步复制到了所有其他节点(节点B节点C),节点B节点C收到的数据不是来自用户,而是由节点A异步复制(为了让所有副本保持一致)来的,所以节点B节点C不产生新的版本信息,因此现在节点B节点C所持有的数据还是D2(A,2)。于是节点A节点B节点C上的数据及其版本号都是一样的。
  3. 节点B写了一次)如果有一个新的写请求到了节点B上,于是节点B生成数据D3(A,2; B,1),意思是:数据D全局版本号为3,节点A更新了2次,节点B更新了1次。
  4. 节点C写了一次:节点B的改变还没异步复制到节点C之前节点C就写完了)如果D3还没有异步复制节点C的时候,节点C又处理了一个新的写请求,于是,节点C上的数据是D4(A,2; C,1)。
  5. 好,最精彩的事情来了:如果这个时候来了一个读请求,因为W=1,R=N=3,所以R会从所有三个节点(A、B、C)上读,此时,他会读到三个版本:
  • A结点:D2(A,2)
  • B结点:D3(A,2; B,1);
  • C结点:D4(A,2; C,1)

  6.这个时候可以判断出,D2已经是旧版本(已经包含在D3/D4中),可以舍弃。

  7.但是D3和D4是明显的版本冲突,只能交给用户自己去做版本冲突管理。就像前面说的svn源代码版本管理一样。

 

 

1
2
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics