分布式一致性协议——Gossip

关于分布式一致性问题我已经在《分布式一致性协议——Raft》的聊过，还不清楚的朋友可以回头看一下。这篇文章将介绍另一种分布式一致性协议——Gossip。

思考下，大规模集群时，如果还是采用 raft 协议，会不会有问题？

根据上篇文章，我们知道 leader 会广播到 follower ，集群规模较大，势必会造成网络拥挤、网络超时等问题，无论从可用性还是性能角度考虑，都会存在问题。

因为大规模集群需要考虑一下问题：

1. 集群规模大，可靠性降低，即使出现部分网络问题，数据也应该能最终到达所有节点；

2. 节点广播数据，会消耗大量带宽；

基于以上两点考虑，gossip 协议被提出来用来解决大规模集群的一致性问题。

Gossip 翻译过来是 “流言蜚语”，以点对点方式通信， 每个节点会周期性地将自身的信息以及自身已经掌握的其他节点的信息传递给随机的节点，经过短暂的时间【时间复杂度O(log n) 】最终所有节点达成一致的协议。

每个节点最多和 3 各节点通信，每次状态发生变化时， 信息都会带一个自增的 version， 以保证新的 version 消息能够覆盖旧的消息。注意为了避免不必要的消息通信，通常只会在状态发生变化时才会发送消息。

version 和 变化的状态值，并没有持久化，一旦宕机可能就会丢失，所以在 gossip 的具体实现时，通常还会加一个预写的单调递增的 “代”信息，类似于 raft 中 leader 每次选举都会生成一个 term。

用来启动并初始化 gossip 的节点，我们称为种子节点，除此之外别无用处。

所以种子节点需要考虑以下问题：

1. 为避免通信问题，种子节点列表通常是固定的；

2. 多数据中心集群时， 需保证每个数据中心都有种子节点；

3. 为避免单点故障，每个数据中心的种子节点通常需要有多个节点，但不能太多, 3个最好；

4. 所有节点都配置为种子节点时不可取的，会影响通信效率。

Gossip 协议重要用途之一就是维护集群中可用节点列表，在很多分布式系统中都有使用，比如 Redis集群、Cassandra 集群、Consul 集群等。

Redis 集群中各节点间的元数据同步就是使用了 gossip 协议。比如集群中动态扩展节点时，需要同步集群的元数据。

微服务注册中心 consul，也使用了 gossip 协议来管理集群成员关系并且来广播消息。

总的来说，通过 gossip 协议，可以减少集群配置，并且可以在不停机的情况下动态扩展集群。

由于 gossip 是基于点对点的通信方式，时间复杂度低，因此更适用于规模较大的集群，而之前提到的 raft 、zab、paxios 则是一种基于广播的 quorum 方式，吞吐量会随着集群的扩大而降低，因此更适用于小集群。

如果觉得还不错的话，关注、分享、在看（关注不失联~）， 原创不易，且看且珍惜~