分布式之gossip共识算法分析

写在前面

假如你的业务对系统的可用性要求非常高，就算集群只剩下一个节点，也要能够正常对外提供服务（虽然此时系统能力已经骤降，但至少还在！），因为raft 要求大多数节点可用所以就没有用武之地了。此时，我们就可以考虑使用gossip协议了，使用该协议来实现一种去中心化的集群，从而实现只有一个节点集群依然坚挺。

1：gossip都有哪些内容

gossip有如下3部分内容：

直接邮寄：收到更新的节点直接随机选择若干个节点，将更新同步到这些节点上
反熵：异步的以对比的方式来同步数据，实现数据最终一致性
谣言传播：异步的随机选择若干个节点，传播数据，然后收到数据的节点，再随机选择若干个节点，随机传播数据，重复这个过程，直到所有节点都收到了数据

分别来看下这3种方式。

2：直接邮寄

这种方式比较简单，先将需要同步的更新缓存到队列中，然后随机选择若干个节点，同步更新，如下图节点A随机选择了节点B和节点D来同步数据：

但是这种方式只能实现数据的安全性（因为同步到多个副本了），无法实现最终一致性，所以还需要反熵以及谣言传播机制。

3：反熵

这种方式是集群中的节点定时选择一个其他节点来并对比二者数据，达到最终一致性，其实就是一个取数据并集的过程，如下节点A同步数据到节点D：

具体的同步方式有三种，推，即上图的方式。拉：

推拉：

在工程上，为了加快同步的速度，以及对比的次数我们可以使用推拉方式的环状复制，假设有A，B，C,D 4个节点，则这个过程可能如下图：

假设A的数据是1，B的数据是2，C的数据是3，D的数据是4，则达到最终一致性的同步过程如下:

1：A对B推拉数据 
    A数据为12，B数据为12
2：B对C推拉数据
    A数据为12，B数据为123，C数据为123
3：C对D推拉数据
    A数据为12，B数据为123，C数据为1234，D数据为1234
4：D对A推拉数据（注意这里如果没有5，A重新推拉B，则B将缺失数据4）
    A数据为1234，B数据为123，C数据为1234，D数据为1234
5：A对B推拉数据（各节点就达到了最终数据一致性）
    A数据为1234，B数据为1234，C数据为1234，D数据为1234

这种方式适合于节点已知稳定不变，且节点数较少的场景中，如果是节点比较多或者是节点数动态变化时就需要使用谣言传播来达到最终一致性了，接着也来看下。

4：谣言传播

这是一种类似于谣言传播的数据同步方式，一传十，十传百，具体是一个节点随机的选择一批节点同步更新，然后收到更新的节点重复这个过程，直到所有的节点都收到了更新为止，如下：

如上图就是节点A首先同步给节点B和节点D,然后节点B同步给节点C和节点E,这样所有的节点就都有了来自节点A的更新，达到了最终一致性。

写在后面

小结

本文分析了基于raft算法的中心化架构存在的问题，基于此引出了适用于非中心化架构的gossip协议，并一起看了其直邮，反熵，谣言传播三种更新同步的方式。希望本文能够帮助到你，如果你有什么问题，就留言我们一起讨论吧！

参考文章列表

分布式理论之共识算法gossip 。