元旦的时候我看到一个特别离谱的谣言啊,具体是什么内容我就不说了,我怕脏了大家的眼睛。
但是,我看到一个群里传的那叫一个绘声绘色,大家讨论的风生水起的,仿佛大家就在现场似的。
这事吧本来我呵呵一笑也就过了。但是隔了一会我突然大腿一拍:这是个素材啊。
我可以和大家聊一个共识算法呀。
说到共识算法,大家首先想到的应该都是 Raft、Paxos、Zab 算法这类理解起来比较困难的强一致性算法。
但是还有一个弱一致性的共识算法比较好理解,Gossip 协议。
Gossip,先看这个单词,圈起来,要考的啊,这是一个六级词汇,也是考研单词,意思是“流言蜚语”。
接下来就带你简单的看看这个“流言蜚语”到底是怎么回事。
Gossip 协议
Gossip 协议最早提出的时间得追溯到 1987 年发布的一篇论文:《Epidemic Algorithms for Replicated Database Maintenance》
我第一次看到这个论文的名字的时候,我都懵逼了:这也没有 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(传谣)这两个方案。
先定个整