分布式协议-Gossip协议

Gossip 协议，顾名思义，就像流言蜚语一样，利用一种随机、带有传染性的方式，将信息 传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致。属于最终一致性算法

实现最终一致性的常用三种方法

1、直接邮寄（Direct Mail）

2、反熵（Anti-entropy）

3、谣言传播（Rumor mongering）

直接邮寄（Direct Mail）

直接发送更新数据，当数据发送失败时，将数据缓存下来，然后重传

直接邮寄虽然实现起来比较容易，数据同步也很及时，但可能会因为缓存队列满了而丢数据

反熵（Anti-entropy）

反熵指的是集群中的节点，每隔段时间就随机选择某个其他节点，然后通过互相交换自己的所有数据来消除两者之间的差异，实现数据的最终一致性

本质上，反熵是一种通过异步修复实现最终一致性的方法

在实现反熵的时候，主要有推、拉和推拉三种方式

Push模式：主动将自身状态推送给目标节点。

Pull模式：从目标节点拉取状态信息。

Push-Pull模式：结合两者，交换双方的状态。

反熵需要节点两两交换和比对自己所有的数据，执行反熵时通讯成本会很高，所以不建议在实际场景中频繁执行反熵，并且可以通过引入校验和(Checksum)等机制，降低需要对比的数据量和通讯消息等

执行反熵时，相关的节点都是已知的，而且节点数量不能太多，如果是一个动态变化或节点数比较多的分布式环境(比如在 DevOps 环境中检测节点故障，并动态维护集群节点状态)，这时反熵就不适用

谣言传播

当一个节点有了新数据后，这个节点变成活跃状态，并周期性地联系其他节点向其发送新数据，直到所有的节点都存储了该新数据

总结

Gossip 不要求节点知道所有其它节点，因此又具有去中心化的特点，节点之间完全对等，不需要任何的中心节点。实际上 Gossip 可以用于众多能接受“最终一致性”的领域：失败检测、路由同步、Pub/Sub、动态负载均衡。

Gossip 的缺点也很明显，冗余通信会对网路带宽、CUP 资源造成很大的负载，而这些负载又受限于通信频率，该频率又影响着算法收敛的速度