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种

  1. alive:存活的
  2. suspect:可疑的,对于PingMsg没有应答或应答超时
  3. dead:已死亡

Redis Cluster

Redis3.0版本加入Redis Cluster,主从架构的Redis Cluster架构图:
Gossip协议理解_第1张图片
其中虚线表示各个节点之间的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中的实现

你可能感兴趣的:(理论,分布式)