Gossip协议那些事

本文节选自《深入分布式缓存》一书第二章。

对于分布式系统而言，由于状态分散在集群中的各个节点上，集群的状态同步面临着集中式系统所不具备的问题：

• 其中的每一个节点如何较快的得知集群状态全集的某些特征？

• 如何避免多个节点就某个状态发生分歧，使得集群的状态实时或最终一致？

分布式系统中的各个节点通过一定的交互方式（分布式协议）解决上述问题。

Gossip就是一种去中心化思路的分布式协议，解决状态在集群中的传播和状态一致性的保证两个问题。因为其实现简单，具备较高的容错性和性能，成为了分布式系统最广泛使用的状态同步协议之一。

1. 状态的传播

以Gossip协议同步状态的思路类似于流言的传播,如图2-25所示。

                           

图2-25 流言传播

A节点率先知道了某个流言（msg），它首先将此信息传播到集群中的部分节点（比如相邻的两个节点）B和C，后者再将其传递到它们所选择的“部分”节点，例如B选择了D和E，C选择了将流言传播到B和F。以此类推，最终来自于A的这条流言在3轮交互后被传播到了集群中的所有节点。

在分布式系统的实践中，这个“流言”可能是：某个节点所感知到的关于其它节点是否宕机的认识；也可能是数据水平拆分的缓存集群中，关于哪些hash桶分布在哪些节点上的信息。每个节点起初只掌握部分状态信息，不断地从其它节点收到gossip信息，每个节点逐渐地掌握到了整个集群的状态信息。因此解决了状态同步的第一个问题：全集状态的获取。

对于集群中出现的部分网络分割，消息也能通过别的路径传播到整个集群。如图2-26所示：

图2-26 网络分割示意

2. 状态的一致

状态同步的第二个问题：对于同一条状态信息，不同的节点可能掌握的值不同，也能通过基于gossip通信思路构建的协议包版本得到解决。例如水平拆分的redis缓存集群，初始状态下hash桶在各个节点的分布如图2-27所示：

图2-27 状态一致案例

此时各个节点预先通过某种协议（比如Gossip）得知了集群的状态全集，此时新加入了节点D，如图2-28所示：

图2-28 加入节点D的变化

D分担了C的某个hash桶，此时C/D和集群中其它节点就C所拥有哪些hash这件事发生了分歧：A/B认为C目前有6/7/8个hash桶。此时通过为gossip消息体引入版本号，使得关于C的最新状态信息（只有6/7两个桶了）在全集群达到一致。例如B收到来自A和C的gossip消息时会将版本号更新的消息（来自C的v2）更新到自己的本地副本中。

各个节点的本地副本保存的集群全量状态也可能用来表示各个节点的存活状态。对于部分网络分割的情况如图2-29所示：

图2-29 网络分割下的状态

例如A和C的网络断开，但A和C本身都正常运行，此时A和C互相无法通信，C会将A标记为不可用状态。对于中心化思路的协议，如果C恰好是中心节点，那么A不可用的信息将会同步到集群的所有节点上，使得这些节点将其实可用的A也标记为宕机。而基于gossip这类去中心化的协议进行接收到消息后的实现逻辑扩展（例如只有当接收到大多数的节点关于A已经宕机的消息时，才更新A的状态），最终保证A不被误判为宕机。

3. 特性总结

Gossip的核心是在去中心化结构下，通过的信息部分传递，达到全集群的状态信息传播，传播的时间收敛在O（Log（N））以内，其中N是节点的数量。同时基于gossip协议，可以构建出状态一致的各种解决方案。

新书推荐：《深入分布式缓存》

购书，扫描二维码：

同时，推荐一个java技术公众号。

纯洁的微笑

名称：纯洁的微笑

ID: keeppuresmile

简介：主要关注服务后端开发内容，在Java技术干货、微服务实践、高可用架构、大数据治理等方面均有深入实践。此公号分享他的生活故事和技术见解，关注即可看到博主一路走过来的经验与教训，博客：www.ityouknow.com。