Gossip协议

当你希望保证自己的系统在极端情况下（比如集群中只有一个节点在运行）的可用性，只需要实现最终一致性，可以通过 Gossip 协议实现这个目标。

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

Gossip 的三板斧

Gossip 的三板斧分别是：直接邮寄（Direct Mail）、反熵（Anti-entropy）和谣言传播（Rumor mongering），它们是实现最终一致性的常用三种方法。

直接邮寄：就是直接发送更新数据，当数据发送失败时，将数据缓存下来，然后重传。直接邮寄虽然实现起来比较容易，数据同步也很及时，但可能会因为缓存队列满了而丢数据。也就是说，只采用直接邮寄是无法实现最终一致性的。

反熵：是一种通过异步修复实现最终一致性的方法，指的是集群中的节点，每隔段时间就随机选择某个其他节点，然后通过互相交换自己的所有数据来消除两者之间的差异，实现数据的最终一致性（反熵中的熵是指混乱程度，反熵就是指消除不同节点中数据的差异，提升节点间数据的相似度，降低熵值）。在实现反熵的时候，主要有推、拉和推拉三种方式。

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

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

谣言传播：广泛地散播谣言，它指的是当一个节点有了新数据后，这个节点变成活跃状态，并周期性地联系其他节点向其发送新数据，直到所有的节点都存储了该新数据，谣言传播非常具有传染性，它适合动态变化的分布式系统。

如何使用反熵实现最终一致

在分布式存储系统中，实现数据副本最终一致性，最常用的方法就是反熵。一般的数据缺失分为这样 2 种情况：1. 缺失分片；2. 节点之间的分片不一致。针对第2种情况需要设计一个闭环的流程，按照一个顺序修复，执行完流程后，也就是实现了一致性。

可以按照一定顺序来修复节点的数据差异，先随机选择一个节点，然后循环修复，每个节点生成自己节点有、下一个节点没有的差异数据，发送给下一个节点，进行修复，一直循环到第二次来到倒数第二个节点为止。

在实现反熵时，实现细节和最初算法的约定有些不同。比如，不是一个节点不断随机选择另一个节点，来修复副本上的熵，而是设计了一个闭环的流程，一次修复所有节点的副本数据不一致。这是因为 gossip 的传播时间是不可控的，但循环闭环修复，是可控的。

因为反熵需要做一致性对比，很消耗系统性能，所以建议你将是否启用反熵功能、执行一致性检测的时间间隔等，做成可配置的，能在不同场景中按需使用。

总结

1. 作为一种异步修复、实现最终一致性的协议，反熵在存储组件中应用广泛，比如 Dynamo、InfluxDB、Cassandra，在后续需要实现最终一致性时，可以优先考虑反熵。
2. 因为谣言传播具有传染性，一个节点传给了另一个节点，另一个节点又将充当传播者，传染给其他节点，所以非常适合动态变化的分布式系统，比如 Cassandra 采用这种方式动态管理集群节点状态。

在实际场景中，实现数据副本的最终一致性时：

• 一般而言，直接邮寄的方式是一定要实现的，因为不需要做一致性对比，只是通过发送更新数据或缓存重传，来修复数据的不一致，性能损耗低。

• 在存储组件中，节点都是已知的，一般采用反熵修复数据副本的一致性。

• 当集群节点是变化的，或者集群节点数比较多时，这时要采用谣言传播的方式，同步更新数据，实现最终一致。