gossip在分布式场景中非常常见，那么gossip到底是什么东西，能做什么呢？

背景

Gossip protocol 也称Epidemic Protocol，如其名，是基于流行病传播方式的节点或进程间通讯的协议。

特点

• Scalable（扩展性）在O(logN)周期内消息可以传播到所有节点。

• Fault-tolerance（容错）当集群中因为网络故障等原因依旧可以保持工作，一个节点可以多次收到要传播的消息。

• Robust（健壮性）节点对等，部分节点宕机不影响整体，但会有拜占庭问题，一个节点恶意发送消息，传播到所有节点。

• Convergent consistency（最终一致性）在很短时间可以把消息同步到所有节点。

类型

• 反熵（Anti-Entropy）

按照固定的频率传播全部数据

• 谣言传播（Rumor-Mongering）

仅传播最新的数据

反熵是SI mode，节点只有两种状态，Suspective 和 Infective，叫做 simple epidemics。在SI mode下，一个节点会把所有数据和其他节点共享，以消除节点之间的不一致性。他可以保证最终完全一致性。
谣言传播是SIM mode，在这种模型下，节点之间可以频繁的发送消息，因为消息只包含最新消息。而且一个rumor消息会在一定时间后标记为removed状态，不在传播，会造成部分消息丢失。隐私SIM mode下有一定概率造成数据不一致。

通信方式

• push

节点A主动向节点B发送消息(key,value,version)，节点B更新比自己新的消息

• pull

节点A仅将消息(key,version)发送给节点B，节点B将本地比节点A新的数据(key,value,version)推给节点A

• push & pull

比pull多一步，节点A将本地新的数据推给B

缺陷

• 消息的延迟

节点只会随机向周围少数节点发送消息，最终通过多次传播到达全网，因此会有一定的时间延迟，不适合对实时性要求高的系统

• 消息的冗余

节点定期发送消息，收到消息的节点也会重复该步骤，因此会不可避免的造成消息发送到同一个节点上来，同时也增加了消息处理的压力。 另外由于节点发送消息是收到不反馈的，因此也加重了消息的冗余。

应用场景

Apache cassandra， redis cluster模式，consul