Gossip协议理解

概述

Gossip协议，又称epidemic协议，基于流行病传播方式的节点或进程之间信息交换的协议，在分布式系统中被广泛使用。

在1987年8月由施乐-帕洛阿尔托研究中心发表ACM上的论文《Epidemic Algorithms for Replicated Database Maintenance》中被提出。原本用于分布式数据库中节点同步数据使用，后被广泛用于数据库复制、信息扩散、集群成员身份确认、故障探测等。

六度分隔理论（Six Degrees of Separation）：一个人通过6个中间人可以认识世界任何人。数学公式： $n=\frac{log(N)}{log(W)}$ ，n表示复杂度，N表示人的总数，W表示每个人的联系宽度。依据邓巴数，即一个人认识150人，其六度就是 $150^6$ ＝11,390,625,000,000（约11.4万亿）。

基于六度分隔理论，任何信息的传播其实非常迅速，且网络交互次数不会很多。

过程

Gossip协议利用一种随机的方式将信息传播到整个网络中，并在一定时间内使得系统内的所有节点数据一致。一种去中心化思路的分布式协议，解决状态在集群中的传播和状态一致性的保证两个问题。

Gossip协议执行过程：

种子节点周期性的散播消息【假定把周期限定为1秒】
被感染节点随机选择N个邻接节点散播消息【假定fan-out(扇出)设置为6，每次最多往6个节点散播】
节点只接收消息不反馈结果
每次散播消息都选择尚未发送过的节点进行散播
收到消息的节点不再往发送节点散播：A->B，则B进行散播时，不再发给A。

Goosip协议的信息传播和扩散通常需要由种子节点发起。整个传播过程可能需要一定的时间，由于不能保证某个时刻所有节点都收到消息，但是理论上最终所有节点都会收到消息，因此它是一个最终一致性协议。

Gossip协议是一个多主协议，所有写操作可以由不同节点发起，并且同步给其他副本。Gossip内组成的网络节点都是对等节点，是非结构化网络。

应用场景

Gossip协议可以支持以下需求：

Database Replication
消息传播
Cluster Membership
Failure 检测
Overlay Networks
Aggregations（如计算平均值、最大值以及总和）

使用Gossip协议的技术组件或框架：

Riak：使用Gossip协议来共享和传递集群的环状态（ring state）和存储桶属性（bucket properties）
Cassandra：节点间的信息交换使用Gossip协议，所有节点都可以快速了解集群中的所有其他节点
Dynamo：基于Gossip协议的分布式故障检测和成员协议，这样集群中添加或移除节点，其他节点可以快速检测到
Consul：使用称为SERF的Gossip协议，主要有两个目的：1、发现新节点或故障节点；2、为一些重要的事件（如Leader选举）传播提供可靠快速的传播
Amazon S3：使用Gossip协议将服务的状态传递给系统
Redis Cluster：
Zeppelin：

类型

消息传播方式有两种：

Anti-Entropy（反熵）：以固定的概率传播所有的数据
Rumor-Mongering（谣言传播）：仅传播新到达的数据

一般来说，为了在通信代价和可靠性之间取得折中，需要将这两种方法结合使用。

Anti-Entropy

反熵传播是以固定的概率传播所有的数据。所有参与节点只有两种状态：Suspective(病原)、Infective(感染)。这种模型叫做simple epidemics，SI model。处于infective状态的节点代表其有数据更新，并且会将这个数据分享给其他节点；处于susceptible状态的节点代表其并没有收到来自其他节点的更新。

种子节点会把所有的数据都跟其他节点共享，以便消除节点之间数据的任何不一致，它可以保证最终、完全的一致。缺点是消息数量非常庞大，且无限制；通常只用于新加入节点的数据初始化。

每个节点周期性地随机选择其他节点，然后通过互相交换自己的所有数据来消除两者之间的差异。这种方法非常可靠，但是每次节点两两交换自己的所有数据会带来非常大的通信负担，因此不会频繁使用。

Rumor-Mongering

谣言传播是以固定的概率仅传播新到达的数据。所有参与节点有三种状态：Suspective(病原)、Infective(感染)、Removed(愈除)。这种模型叫做complex epidemics，SIR model。相比Anti-Entropy多一种状态：removed，处于removed状态的节点说明其已经接收到来自其他节点的更新，但是其并不会将这个更新分享给其他节点。

Rumor消息会在某个时间标记为removed，然后不会发送给其他节点，所以Rumor-Mongering类型的Gossip协议有极小概率使得更新不会达到所有节点。

消息只包含最新update，谣言消息在某个时间点之后会被标记为removed，并且不再被传播。缺点是系统有一定的概率会不一致，通常用于节点间数据增量同步。

当一个节点有新的信息后，这个节点变成活跃状态，并周期性地联系其他节点向其发送新信息。直到所有的节点都知道该新信息。因为节点之间只是交换新信息，所以大大减少通信的负担。

通讯方式

Anti-Entropy和Rumor-Mongering都涉及到节点间的数据交互方式，节点间的交互方式主要有三种：Push、Pull及Push&Pull。

Push：发起信息交换的节点A随机选择联系节点B，并向其发送自己的信息，节点B在收到信息后更新比自己新的数据，一般拥有新信息的节点才会作为发起节点。
Pull：发起信息交换的节点A随机选择联系节点B，并从对方获取信息。一般无新信息的节点才会作为发起节点。
Push&Pull：发起信息交换的节点A向选择的节点B发送信息，同时从对方获取数据，用于更新自己的本地数据。

如果把两个节点数据同步一次定义为一个周期，则在一个周期内，Push需通信1次，Pull需2次，Push/Pull则需3次。消息数增加，但从效果上来讲，Push/Pull最好，理论上一个周期内可以使两个节点完全一致。直观上，Push/Pull的收敛速度也是最快的。

优缺点

优点

可扩展性（Scalable）
Gossip协议是可扩展的，一般需要O(logN)轮就可以将信息传播到所有的节点，其中N代表节点的个数。每个节点仅发送固定数量的消息，并且与网络中节点数目无法。在数据传送的时候，节点并不会等待消息的ack，所以消息传送失败也没有关系，因为可以通过其他节点将消息传递给之前传送失败的节点。系统可以轻松扩展到数百万个进程。
容错（Fault-tolerance）
网络中任何节点的重启或宕机都不会影响Gossip协议的运行。
去中心化（Decentralized）
无中心节点，所有节点都是对等的，任意节点无需知道整个网络状况，只要网络连通，任意节点可把消息散播到全网；任何节点出现问题都不会阻止其他节点继续发送消息。任何节点都可以随时加入或离开，而不会影响系统的整体服务质量（QoS）
最终一致性（Convergent Consistency）
可实现信息指数级的快速传播，在有新信息需要传播时，消息可快速发送到全局节点，在有限时间内做到所有节点都拥有最新数据。

缺点

消息延迟：节点随机向少数几个节点发送消息，消息最终是通过多个轮次的散播而到达全网；不可避免的造成消息延迟。
消息冗余：节点定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤；不可避免的引起同一节点消息多次接收，增加消息处理压力。

由于以上优缺点，适合于AP场景的数据一致性处理，常见应用有：P2P网络通信、Apache Cassandra、Redis Cluster、Consul。

实现

Consul

Consul使用两种不同的Gossip池：

LAN池
Consul中的每个数据中心有一个LAN池，包含这个数据中心的所有成员，包括clients和servers。LAN池有以下几个目的:
- 成员关系信息允许client自动发现server，减少所需要的配置量
- 分布式失败检测机制使得由整个集群来做失败检测这件事，而不是集中到几台机器上
- 使得类似领导人选举这样的事件变得可靠且迅速
WAN池
WAN池是全局唯一的，无论位于哪个数据中心的server都应该加入到WAN池中。由WAN池提供的成员关系信息允许server做一些跨数据中心的请求。一体化的失败检测机制允许Consul优雅地去处理：整个数据中心失去连接，或仅仅是别的数据中心的某一台失去连接。

Consul在gossip上的实现实际上是使用的memberlist库，其实现集群内节点发现、节点失效探测、节点故障转移、节点状态同步等。

节点状态有3种

alive：存活的
suspect：可疑的，对于PingMsg没有应答或应答超时
dead：已死亡

Redis Cluster

Redis3.0版本加入Redis Cluster，主从架构的Redis Cluster架构图：
在这里插入图片描述
其中虚线表示各个节点之间的Gossip通信。

Gossip协议是个松散的协议，没有对数据交换的格式做特别的约束，各框架可自由设定实现机制。Redis Cluster有以下9种消息类型的定义，详情可见注释。

Dynamo

memberlist

memberlist是hashicorp开源的go语言实现版本，参考GitHub。

GitHub给出的README文档：

list, err := memberlist.Create(memberlist.DefaultLocalConfig())
if err != nil {
	panic("Failed to create memberlist: " + err.Error())
}
// Join an existing cluster by specifying at least one known member.
n, err := list.Join([]string{"1.2.3.4"})
if err != nil {
	panic("Failed to join cluster: " + err.Error())
}
// Ask for members of the cluster
for _, member := range list.Members() {
	fmt.Printf("Member: %s %s\n", member.Name, member.Addr)
}