分布式多副本一致性问题 [推荐]

Posted zbuger

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式多副本一致性问题 [推荐]相关的知识,希望对你有一定的参考价值。

1. 强一致性:所有的副本更新成功才返回。

                  

如上图C表示Client,【P、S1、S2】构成一个同步组,P表示Primary node,S1,S2是两个secondary node,强同步模型的工作流程为C向P写数据,P向S1,S2转发,只有3个都写成功,才向C返回成功,否则写失败。这种模型对于append操作很容易实现,如果副本没有全部更新成功,向C返回失败即可,不必重新同步P和两个S的数据;但如果是overwrite,则如果在同步过程中部分成功,还要考虑数据的正确性。


同时,P向S1、S2同步的过程,可以进行优化,借鉴GFS的流水线复制方式(P->S1 &S1->S2),以便充分利用每个node的带宽资源。

 

2. 最终一致性:在经过一个不一致窗口后,副本最终处于一致的状态

 


如上图是一种简单的最终一致性实现模型,通过增加一组U(update)节点来实现。具体做法是,C的每次更新以binlog的方式顺序的追加到Update节点(多台来避免单点),然后Update节点定期(如10ms)的将binlog重放到三个副本上(N1,N2,N3)。三个副本可以同时提供读服务,读到的数据可能不是最新的,这就要求上层业务能容忍或者在上层做一些容错(如上层的业务每次会等待不一致窗口过去后再读取数据)。

 

最终一致性的实现方式还包括大名鼎鼎的Dynamo,使用读写成功的副本数R,W来控制,当R+W > N(副本数)时,即可保证最终一致性。

 

如果在最终一致性的基础上要保证每次读能读到最新的数据,可在上述模型上做点小改进。

 

  

每次C更新到U上后,必须至少同步到一个group中的P上,即P上的数据一定是最新的,系统的读请求由P节点来满足以保证每次读到的数据是最新的,付出的代价就是,两个从副本不能分担负载,使得P易成为热点,当P挂掉时,选择一个S成为新的P。

以上是关于分布式多副本一致性问题 [推荐]的主要内容,如果未能解决你的问题,请参考以下文章

拜托!这才是分布式系统CAP的正确打开方式!

分布式系统之Raft共识算法

raft算法总结

阅读推荐指数:5颗星★★★★★关于多副本纠删码,你想知道的全都在这里

⭐阅读推荐指数:5颗星★★★★★⭐关于多副本纠删码,你想知道的全都在这里

架构杂谈《四》