整活儿了，来看看“流言蜚语”算法的那点破事

元旦的时候我看到一个特别离谱的谣言啊，具体是什么内容我就不说了，我怕脏了大家的眼睛。

但是，我看到一个群里传的那叫一个绘声绘色，大家讨论的风生水起的，仿佛大家就在现场似的。

这事吧本来我呵呵一笑也就过了。但是隔了一会我突然大腿一拍：这是个素材啊。

我可以和大家聊一个共识算法呀。

说到共识算法，大家首先想到的应该都是 Raft、Paxos、Zab 算法这类理解起来比较困难的强一致性算法。

但是还有一个弱一致性的共识算法比较好理解，Gossip 协议。

Gossip，先看这个单词，圈起来，要考的啊，这是一个六级词汇，也是考研单词，意思是“流言蜚语”。

接下来就带你简单的看看这个“流言蜚语”到底是怎么回事。

Gossip 协议

Gossip 协议最早提出的时间得追溯到 1987 年发布的一篇论文：《Epidemic Algorithms for Replicated Database Maintenance》

bitsavers.trailing-edge.com/pdf/xerox/p…

我第一次看到这个论文的名字的时候，我都懵逼了：这也没有 Gossip 的关键词呢。

主要是 Epidemic Algorithms 这两个单词，我又恰好认识。

Algorithms，算法，没啥说的。

Epidemic 是啥？

紧扣当下时事：

所以 Epidemic Algorithms 翻译过来就是流行病算法。

因此 Gossip 的学名应该是又叫做“流行病算法”，只是大家更喜欢叫它 Gossip 而已。毕竟，虽不喜欢听点儿“小道消息”呢？

说论文之前，先简单定个基调。

你觉得一致性协议最基础、最核心、最重要的一个动作是什么？

是不是数据更新？

为了保证各个节点的数据的一致性，必然就涉及到数据的更新操作。

所以，在论文的开篇介绍部分描述了三种方法来进行数据的更新：

• Direct mail（直接邮件）
• Anti-entropy（反熵）
• Rumor mongering（传谣）

Direct mail（直接邮寄）

废话先不说了，直接上个图：

上面这图啥意思呢？

就是一共八个小圆点，假设每个都代表一个服务器，它们之间都是平等的关系，不存在中心节点、主从什么的关系。

其中最上面的红色节点表示该节点有数据变更了，于是把变更的数据直接通知给剩下的节点。

如果其他的节点上发生了数据变更也是同样的道理。

可以简单的理解为一个循环遍历，每发生一次数据变更，为了保持数据的一致性，就得进行一次循环遍历。

这个方案的优点很明显：简单、粗暴、直接。

但是缺点和优点一样明显，我们看看论文里面怎么说：

主要看 but 的部分：

首先不完全可靠，因为这个要求每个站点都必须知道所有站点的存在。但是实际情况是有的站点并不总是知道所有其他站点。

然后，信息（mail）有时会丢失，一旦丢失，就连最终一致性也保证不了，整个凉凉。

其实 Direct mail（直接邮寄）并不是论文里面主要讨论的方案，把它写在第一个起一个抛砖引玉的作用。

主要聊聊 Anti-entropy（反熵）和 Rumor-Mongering（传谣）这两个方案。

先定个整体的