11 | Gossip协议：流言蜚语，原来也可以实现一致性
该思维导图由 AI 生成，仅供参考
Gossip 的三板斧
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Gossip协议是一种实现最终一致性的算法，通过流言蜚语的方式在分布式系统中传播信息，使得系统内的所有节点数据一致。该协议的核心内容包括直接邮寄、反熵和谣言传播三板斧。直接邮寄虽然实现简单，但可能会丢失数据，因此需要结合反熵来实现最终一致性。反熵是一种通过异步修复实现最终一致性的方法，包括推、拉和推拉三种方式。谣言传播则适合动态变化的分布式系统。在实际环境中，反熵的实现需要解决数据缺失和节点之间的分片不一致等问题，通过设计闭环流程按顺序修复节点的数据差异来实现一致性。文章强调了根据场景特点权衡妥协，设计出最适合的系统功能，并建议将反熵功能做成可配置的，能在不同场景中按需使用。 Gossip协议和反熵在分布式系统中的应用是本文的重点。反熵作为一种异步修复、实现最终一致性的协议，在存储组件中应用广泛，而谣言传播则适合动态变化的分布式系统。在实际场景中，直接邮寄、反熵修复和谣言传播的选择取决于系统特点和需求。文章还提出了一个课堂思考问题，即如何降低一致性检测时的性能消耗，鼓励读者分享看法进行讨论。 总之，本文通过深入讨论Gossip协议和反熵在分布式系统中的应用，为读者提供了对这些技术特点的全面了解，同时引发了读者对性能优化的思考。
《分布式协议与算法实战》，新⼈⾸单¥59
全部留言(51)
- 最新
- 精选
Jialin课堂笔记（综合第四讲和第十一讲内容） 1.Gossip 协议存在的原因？ 为了实现 BASE 理论中的“最终一致性原则”。两阶段提交协议和 Raft 算法需要满足“大多数服务节点正常运行”原则，如果希望系统在少数服务节点正常运行的情况下，仍能对外提供稳定服务，这时就需要实现最终一致性。 最终一致性是指系统中所有的数据副本在经过一段时间的同步后，最终能够达到一个一致的状态。 2.最终一致性原则中的一致性标准（实际工程实践） • 以最新写入的数据为准，比如 AP 模型的 KV 存储采用的就是这种方式 • 以第一次写入的数据为准，如果不希望存储的数据被更改，可以以它为准 3.实现最终一致性的具体方式 • 读时修复：在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点的副本数据不一致，系统就自动修复数据 • 写时修复：在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败就将数据缓存下来，然后定时重传，修复数据的不一致性 • 异步修复：这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复 4.Gossip 协议实现最终一致性 • 直接邮寄，即写时修复，直接发送更新数据，当数据发送失败时，将数据缓存在失败重试队列，然后重传。这种方式虽然存在丢数据问题，但是实现简单、数据同步及时，不需要校验数据一致性对比，性能消耗低 • 反熵，即异步修复，集群中的节点，每隔段时间就随机选择某个其他节点，然后通过互相交换自己的所有数据来消除两者之间的差异，实现数据的最终一致性。主要有推、拉、推拉三种实现方式。适合集群节点数已知、少量、稳定的场景，主要由于反熵需要节点两两交换和比对自己所有的数据，执行反熵时通讯成本会很高，性能消耗高。需要注意的是实现反熵时一般设计一个闭环的流程，一次修复所有节点的副本数据不一致，因为我们希望能在一个确定的时间范围内实现数据副本的最终一致性，而不是基于随机性的概率，在一个不确定的时间范围内实现数据副本的最终一致性 • 谣言传播，指的是当一个节点有了新数据后，这个节点变成活跃状态，并周期性地联系其他节点向其发送新数据，直到所有的节点都存储了该新数据。由于谣言传播非常具有传染性，它适合动态变化的分布式系统 5.思考题：既然使用反熵实现最终一致性时，需要通过一致性检测发现数据副本的差异，如果每次做一致性检测时都做数据对比的话，肯定是比较消耗性能的，那有什么办法降低一致性检测时的性能消耗呢？ 除了老师在文章中提到的通过校验和进行数据一致性检测，可以借鉴通信原理中数据校验方法，如奇偶校验、CRC校验和格雷码校验等方式，但是这些方式只能检测出错误，但是无法纠错，可以通过重传的方式进行纠错。作者回复: 加一颗星:)
2020-03-06747
小晏子一致性检测是对比两个节点上的数据是否一致，如果每次都是全量比对，那么肯定性能不是很高，那为了提升性能，那么最好是不比对或增量数据比对，这里抛个砖， 1. 假设从某一时刻开始，所有节点数据都是一致的，每个节点都记录从这个时刻开始的数据变化， 2. 当反墒放生时，先看相关的两个节点上数据变化是否为空，如果为空就证明两个节点此时数据一致，不需要数据同步。 3. 如果相关的两个节点上数据有变化，则只比较变化的数据，然后只同步变化的差集，同时也要更新数据变化状态记录， 4. 在某个时间段内数据的变化只增不减，某个时刻所有节点做全量比对，然后重置数据变化记录。 5. 为了快速比较，可以同时计算数据变化记录的hash值用于比较，hash值一样就说明数据变化是相同的，两节点数据一致，否则就需要一致性查询并同步。作者回复: 加一颗星:)
2020-03-0624
忆水寒老师，有个疑惑。文章中说直接邮寄肯定要实现的，在固定节点的系统中可以实现反墒修复一致性。那么两者如何兼容呢？是不是每次有新数据写入，先执行直接邮寄。然后周期性的执行反墒修复数据一致性呢？作者回复: 加一颗星:)，是的。
2020-03-06421- myrfy老师，gossip中，遇到数据冲突，以谁为准呢？
作者回复: 加一颗星:)，取决于场景，比如KV数据，以新数据为准。
2020-03-06415 
老辉老师，如果反熵过程中，组成的环上的一个节点挂了，怎么同步数据一致。作者回复: 加一颗星:)，绝大部分时候，系统是稳定运行的，如果出现了节点故障这种异常情况，一般而言，咱们需要先处理节点故障，然后再执行反熵，实现副本数据的最终一致。
2020-03-17214
kylexy_0817韩老师好，我觉得其实就目的而言，Gossip的三板斧都是为了反熵，即都是为了降低系统因为数据不一致引起的混乱程度，只是实现方法不一样，第一种用到消息队列，就是消息订阅发布模式；第二种不经消息队列，直接推拉消息到随机节点；第三种就是散播谣言，这里方法是推，还应该会涉及一个散播算法，避免消息重复下发，避免消息风暴。不知我的理解到不到位？作者回复: 加一颗星:)，可以这么类比理解:)
2020-04-2610- Scottmerkle tree可以用来减少比较差异负担的开销吗
作者回复: 加一颗星:)，是个办法:)
2020-03-089 
翠羽香凝老师，感觉谣言传播有很多细节值得讨论，比如：谣言何时停止？什么时候算是网络里都达到了一致性？而不是无止境的传下去？又比如：谣言传播可能会有很多消息被反复重传，会不会造成网络性能的下降？作者回复: 加一颗星:)，问题1：这个问题比较共性，我后面做个补充吧。问题2：会的，尽管谣言传播能以去中心化的方式，在动态变化的集群中，实现数据副本的最终一致性，但通讯成本较高。
2020-03-1136
崔伟协直接邮寄，反熵，谣言传播三者的区别是什么作者回复: 加一颗星:)，功能和适用场景不同，直接邮寄：直接发送更新数据，若失败，缓存、重传；反熵：修复数据副本差异，实现最终一致；谣言传播：去中心化的、节点相互传播新数据，适用动态变化的分布式场景。
2020-03-096
test这三种方式，是不是主要的区别就是在过程中充当发起者的是单一个节点、轮询节点、多个节点？作者回复: 加一颗星:)，这是其中一个区别，但三个协议最最主要的区别，是功能和适用场景不同，直接邮寄：直接发送更新数据，若失败，缓存、重传；反熵：修复数据副本差异，实现最终一致；谣言传播：去中心化的、节点相互传播新数据，适用动态变化的分布式场景。
2020-06-033
