Gossip协议理解
概述
Gossip协议，又称epidemic协议，基于流行病传播方式的节点或进程之间信息交换的协议，在分布式系统中被广泛使用。
在1987年8月由施乐-帕洛阿尔托研究中心发表ACM上的论文《Epidemic Algorithms for Replicated Database Maintenance》中被提出。原本用于分布式数据库中节点同步数据使用，后被广泛用于数据库复制、信息扩散、集群成员身份确认、故障探测等。
六度分隔理论（Six Degrees of Separation）：一个人通过6个中间人可以认识世界任何人。数学公式： n = l o g ( N ) l o g ( W ) n=\frac{log(N)}{log(W)} n=log(W)log(N)，n表示复杂度，N表示人的总数，W表示每个人的联系宽度。依据邓巴数，即一个人认识150人，其六度就是 15 0 6 150^6 1506＝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)
}
与memberlist交互入口就是Config配置struct类，源码见链接。
这个类里面定义各种配置，如BindAddr、BindPort、AdvertiseAddr、AdvertisePort。同时基于Config，有3种实现类方便初始化一个Gossip集群：
- DefaultLANConfig：局域网，基础类
- DefaultWANConfig：广域网，基于DefaultLANConfig，调整一些参数
- DefaultLocalConfig：本地网，基于DefaultLANConfig，调整一些参数
memberlist提供的功能主要分为两块：维护成员状态（gossip）及数据同步（boardcast、SendReliable）。
参考
- 漫谈gossip协议与其在rediscluster中的实现