分布式多副本一致性问题

典型情况：三个副本构成一个group

 

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。