Gossip 协议
Gossip 协议也叫 Epidemic Protocol（流行病协议），主要用于消息传播，是一种一致性算法。协议也非常好理解，正如协议的名称，如流行病一样靠“感染”节点进行持续传播。使用 Gossip 协议的有：Redis Cluster、Consul、Apache Cassandra等。
要说 Gossip 就不得不提“六度分隔理论”，简单的说：你和任何一个陌生人之间所间隔的人不会超过五个，也就是说，最多通过五个人你就能够认识任何一个陌生人。由时任哈佛大学的心理学教授 Stanley Milgram 在1967年提出。
Facebook 研究了已注册的15.9亿使用者资料，在2016年公布标题为 “Three and a half degrees of separation” 的研究结果。发现世界比人们想象的更紧密，世界上的每个人（至少在 Facebook 活跃的15.9亿人）平均通过3.57个人就可以与任意另外一个人产生联系。
基于六度分隔理论，信息的传播会非常迅速，而且网络交互次数不会很多。Gossip 协议是基于六度分隔理论的很好实现。
Gossip协议基本思想就是：一个节点想要分享一些信息给网络中的其他的节点，于是随机选择一些节点进行信息传递。这些收到信息的节点接下来把这些信息传递给其他一些随机选择的节点。整体过程描述如下。
Gossip 协议的可扩展性极好，一般只需要 O(LogN) 轮就可以将信息传播到所有的节点，其中 N 代表节点的个数。即使集群节点的数量增加，每个节点的负载也不会增加很多，几乎是恒定的。这就允许集群管理的节点规模能横向扩展到几千几万个，集群内的消息通信成本却不会增加很多。
网络中任何节点的宕机和重启都不会影响 Gossip 消息的传播，Gossip 协议具有天然的分布式系统容错特性。
Gossip 协议是去中心化的协议，所以集群中的所有节点都是对等的，任何节点出现问题都不会阻止其他节点继续发送消息。任何节点都可以随时加入或离开，而不会影响系统的整体服务质量。
消息传播是指数级的快速传播，因此当有新信息传播时，消息可以快速地发送到全局节点。系统状态的不一致可以在很快的时间内收敛到一致。
节点随机向少数几个节点发送消息，消息最终是通过多个轮次的传播而到达全网，不可避免的造成消息延迟。不适合于对实时性要求较高的场景。
节点会定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤，因此就不可避免的存在消息重复发送给同一节点的情况，造成了消息的冗余，同时也增加了收到消息的节点的处理压力。
如果有一个恶意传播消息的节点，Gossip协议的分布式系统就会出问题。
go语言版本的Gossip协议包（memberlist）的使用
由于工作的契机，最近学习了下Gossip，以及go语言的实现版本HashiCorp/memberlist。网上有个最基本的memberlist使用的example，在下边的链接中，感兴趣可以按照文档运行下感受感受。本文主要讲解memberlist v0.1.5 的使用细节。
Gossip是最终一致性协议，是目前性能***，容错性***的分布式协议。目前Prometheus的告警组件alertmanager、redis、s3、区块链等项目都有使用Gossip。本文不介绍Gossip原理，大家自行谷歌。
简单的几步即可搭建gossip集群
感谢已经有网友为我们实现了一个example（
）。
哪里有问题，还请大家多多指正
在一个班级里怎么样用gossip协议去传播消息？
Gossip协议是一种去中心化的消息传递协议，可以用于在一个班级里传播消息。以下是一种可能的实现方式：
将班级中每个学生看做一个节点，在每个节点上运行Gossip协议的实现程序；
当一个学生想要向班级中的其他学生传递消息时，他可以将消息发送给一个随机的邻居节点；
接收到消息的节点可以有两种选择：
当一个节点收到一条消息时，可以通过随机选择的方式，选择将消息向哪个邻居节点继续传递，从而让消息在班级中广泛传播。
一文了解啥是Gossip协议？
你好呀，我是动作缓慢的程序猿。
元旦的时候我看到一个特别离谱的谣言啊，具体是什么内容我就不说了，我怕脏了大家的眼睛。
但是，我看到一个群里传的那叫一个绘声绘色，大家讨论的风生水起的，仿佛大家就在现场似的。
这事吧本来我呵呵一笑也就过了。但是隔了一会我突然大腿一拍：这是个素材啊。
我可以和大家聊一个共识算法呀。
说到共识算法，大家首先想到的应该都是 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（传谣）这两个方案。
先定个整体的基调：
Anti-entropy（反熵），是传播节点上的所有的数据
Rumor-Mongering（传谣），是传播节点上的新到达的、或者变更的数据
说白了，一个是全量，一个是增量。
Anti-entropy（反熵）
部分同学可能对“反熵”这个词感到莫名其妙哈，其实主要是不了解啥是“熵”。
其实说白了，“熵”的通俗理解就是“混乱程度”。
比如你的房间，如果你不去整理那么各自物品的摆放就会越来越混乱，也就是越来越“熵”。而你整理房间的这个操作就是“反熵”。
这个东西你可以简单的先这样理解，我一时半会也给你说不清楚，这东西要聊下去的话得上升到宇宙和哲学的高度。
我主要怕你听不懂。
在论文里面是这样的描述 Anti-entropy 模式的：
每个服务器有规律地随机选择另一个服务器，这二者通过交换各自的内容来抹平它们之间的所有差异，这种方案是非常可靠的。
（but 开始了）但需要检查各自服务器的全量内容，言外之意就是数据量略大，因此不能使用太频繁。
实验表明，反熵虽然可靠，但传播更新的速度比直接邮件慢得多。
如果不同步，那么两者之间的数据差异越来越大，也就是越来越熵。
同步的目的是缩小差异，达到最终一致性，这就是反熵。
定义就是这么个定义。
Rumor mongering（传谣）
比起反熵，传谣从字面上就很好理解了。
比如我是一个大学生，并不能完全认识整个学校的人。但是学校里面的同学之间都有千丝万缕的联系。
假设有一天，我刚好碰见校花一个人走在路上，我就上去和她讨论了一下计算机领域里面的共识算法等相关问题，关于这些问题我们进行了深入的讨论并且交换了彼此的理解和看法。
咱这边就是说，整个过程是越讨论越激烈，不知道怎么走着走着就走到了情人坡。
应该每个大学都有一个叫做情人坡的地方吧。
然后被别的妹子看见了。她就给她闺蜜说：你知道歪歪吗？对，就是大一新生，那个大帅比。我那会看到他和校花在情人坡那边溜达。
然后一传十、十传百。这个消息全校师生都知道了。
“歪歪和校花在情人坡那边溜达”这个消息就通过 gossip 的传谣模式，达到了最终一致性。
“传谣”和“反熵”的差别在于只传递新信息或者发生了变更的信息，而不需要传递全量的信息。
比如上面的这个例子中，只需要同步“歪歪和校花在情人坡那边溜达”这个最新的消息就行。
而不需要同步“歪歪是谁，校花是谁，情人坡在哪”等等这些之前大家早就达成一致性的信息。
在提到“传谣”和“反熵”的时候，论文中还有这么个定义：
simple epidemics：单纯性传染病
在这种模式下，包含两种状态：infective（传染性） 和 susceptible（易感染）。
处于 infective 状态的节点代表其有数据更新，需要把数据分享（传染）给其他的节点。
处于 susceptible 状态的节点代表它还没接受到其他节点的数据更新（没有被感染）。
所以，后面我提到“感染”的时候，你应该要知道我是从这里看到的，不是胡编的。
关于“传谣”和“反熵”，再借用周志明老师《凤凰架构》里面的正经一点的描述，是这样的：
达到一致性耗费的时间与网络传播中消息冗余量这两个缺点存在一定对立，如果要改善其中一个，就会恶化另外一个。
由此，Gossip 设计了两种可能的消息传播模式：反熵（Anti-Entropy）和传谣（Rumor-Mongering），这两个名字都挺文艺的。
熵（Entropy）是生活中少见但科学中很常用的概念，它代表着事物的混乱程度。
反熵的意思就是反混乱，以提升网络各个节点之间的相似度为目标，所以在反熵模式下，会同步节点的全部数据，以消除各节点之间的差异，目标是整个网络各节点完全的一致。
但是，在节点本身就会发生变动的前提下，这个目标将使得整个网络中消息的数量非常庞大，给网络带来巨大的传输开销。
而传谣模式是以传播消息为目标，仅仅发送新到达节点的数据，即只对外发送变更信息，这样消息数据量将显著缩减，网络开销也相对较小。
一个网站
摊牌了，其实我是看到了这个网站，才决定写这篇文章的。
因为这个网站里面直接有非常仿真的动画模拟 gossip 协议的同步过程，一个动图胜过千言万语。
地址先放在这里，大家可以自己访问玩儿一下：
先给你看一眼它的工作过程：
甭管看没看懂吧，这玩意至少看起来很厉害的样子。
接下来就给你介绍一下它是怎么玩的：
首先我们看这里的 Nodes 和 Fanout。
Nodes 其实很好理解，就是节点数，这里的 40 就代表下面的小圆圈的个数，比如我今年 18 岁，那么我把它改成 18 它就是这样的：
主要是这个 Fanout 是个啥玩意呢？
在这个网页的头部的轮播图里面，***张图是这样的：
答案就藏在这个 Learn more 里面。
这段话里面就解释了，什么是 Fanout。同时也简单的介绍了 gossip 协议的基本工作原理。
它说 gossip 协议在概念上非常简单，编码也非常简单。它们背后的基本想法是这样的：
一个节点想与网络中的其他节点分享一些信息。然后，它定期从节点集合中随机选择一个节点并交换信息，收到信息的节点也做同样的事情。
该信息定期发送到 N 个目标，N 被称为扇出（Fanout）。
所以，前面的 Fanout=4，含义就是某个节点，每次会把自己想要分享的信息同步给集群中的另外 4 个节点。
在模拟器中体现出来应该是这样的：
上面这个图你可以看到有很多线，但是它们的起点都是一个红色的节点。
这个红色的节点就是你用鼠标随意点击小圆圈中的一个或者多个都可以，鼠标一点击就会变成红色，就是完犊子了，红码了，表示“被感染”了。
上面的线条是怎么搞出来的呢？
有了一个红色的小圆圈之后，点击上面的“Show Paths”就会出现路径了：
但是不是说好 Fanout=4 吗，为什么怎么多的路径？
因为，虽然这个节点知道这么多其他节点，但是它只会选择其中的 4 个进行感染。
上面这个图还是有点复杂，所以我把参数都调小一点，这样看起来就清爽多了：
集群中有一个节点的信息更新了，这个节点知道其他 5 个节点的存在，但是它只会把信息推送给其中的两个，点击 Send Message 按钮之后就会像是这样：
你可以发现上面这个图里面已经有三个红色的节点了，有两条路径变粗了，含义是从这个路径传播过来的。
整个集群最终会全部完成“感染”，达成最终一致性：
同时，gossip 协议它也具备容错性：
按照页面上的提示，我们是可以通过 “Delete” 按钮删除一部分路径的，比如下面这样：
删除两个路径，代表这几个节点之间是不可达的，但是最终这个集群还是会全部被感染。
再来个动图演示一下，可以看到路径删除后，这个节点再也不会给对应的节点通讯，但是整个集群还是达到了收敛：
你自己也可以打开网站去玩一下，还有一个小技巧是这样的：
点击 Pl*** 按钮，是可以随时暂停的，这样就更容易观察到整个传播的过程。
最后，关于这个图里面，还有一个关键的东西没有说，就是里面的这个公式：
在 Learn More 里面也有提到这个公式，其实它就是 gossip 协议的复杂度，O(logN) ：
比如，每次都设置为 Fanout=4，那么节点数和预估传播轮次之间的关系是这样的：
40 个节点，2.66 轮
80 个节点，3.16 轮
160 个节点，3.66 轮
320 个节点，4.16 轮
640 个节点，4.66 轮
...
可以看到，随着节点数的翻倍增加，传播轮次并没有明显的增加。
这就是前面 Learn More 截图里面提到的这个词：Scalable
这是个四级词汇啊，会考的，记住了，是“可伸缩”的意思。
采用 gossip 协议的集群，Scalable is very 的 nice。
其他注意点
在这个网站上，最重要的就是它的动图模拟功能了，但是也不要忽略了它里面的其他部分的描述。
比如这一段话，我就觉得非常的重要。
这一段话里面提到了两个问题，我一个个的说。
首先它说在网站模拟的过程中，所有节点发送消息似乎都是同步的，就像有一个全局循环一样。
在模拟中这样做，是因为这样看起来更加的直观。
但是，在一个真正的 gossip 协议中，每个节点都有自己的周期，它们之间根本没有也不需要同步。
上面是说什么意思呢？
我再说的直白一点，每个节点往外同步消息的时候，是按照自己的周期来处理的，比如每 10 秒一次。根本就不关心其他节点什么时候触发同步消息的操作，只需要管好自己就行了。
第二问题我认为就很重要了：
How do the nodes know about each other?
节点之间怎么知道其他节点的存在的？
其中一个方式就是当节点加入集群时，必须知道该集群中的一个节点的信息。通过前面的动图我们知道，如果一个节点被另外一个节点知道，那么它最终也一定会被感染。
那问题就来了：新节点加入时又是如何知道集群中一个节点信息的呢？
很简单，我知道的一个方案就是人工指定。
Redis 集群采用的就是 gossip 协议来交换信息。当有新节点要加入到集群的时候，需要用到一个 meet 命令。
这玩意就是人工指定。
还有一个可以注意一下的是这个：
这里提到了另外一个模拟的网站：
它可以通过控制这几个参数，来测算集群达成一致性的时间。
上面这个图表示的就是在信息交换频率(GOSSIP INTERVAL)为 0.2s，Fanout 节点数为 3，总节点数为 30，丢包率和节点失败率为 0 的这个情况。
在这个情况下，对应的到达最终一致性的时间图长这样：
基本上在一秒的时间就搞定了。
你也可以自己去修改一下参数，看看对应的时间图的变化。
比如，我只修改节点数，把它从 30 修改为 3000，时间图变成了这样：
在 1.75s 左右完成了收敛。
节点扩大 100 倍，但是时间增加不到 1s，确实是很优秀。
这玩意好是好，但是给你看个***的，来感受一下这恐怖的传播规模：
从动图中可以看出，前面一两次传播还好，至少眼睛还能看出个大概，但是到了后几轮，大多数节点都被感染了，但是还在继续对外传播消息。
这消息数量，简直是看的让人头皮发麻。
六度分隔理论
最后再说一个有意思的东西，叫做“六度分隔理论”：
1967年，哈佛大学的心理学教授Stanley Milgram想要描绘一个连结人与社区的人际连系网。做过一次连锁信实验，结果发现了“六度分隔”现象。简单地说：“你和任何一个陌生人之间所间隔的人不会超过六个，也就是说，最多通过六个人你就能够认识任何一个陌生人。
六度分割理论，也叫小世界理论。这其实和 Gossip 协议也有千丝万缕的联系。
我在小破站上看到一个相关的视频，我觉得解释的还是挺清楚的，你如果有兴趣的话可以去看看：
在视频里面，有这样的一个画面：
好家伙，这不是我们前面的网站上面的翻版嘛，看起来可太亲切了。
这个理论刚刚提出来的时候还是“最多通过六个人你就能够认识任何一个陌生人”。
但是随着这几年社交网络的急速发展，地球都被拉小到了一个“村”的概念了。
所以这个数字在逐渐的减少：
而且如果把这个范围拉小一点，比如局限在程序员这个小范围内，那就更小了。
有时候拉个业务对接群，进去一看好家伙还有前同事，你说这个圈子能有多大。
本文已收录到个人博客，欢迎大家来玩。
gossip的性能有哪些
gossip的性能是：在Gossip性能中，我们可以认为: β=b/nβ=b/n（因为对每个节点而言，被其他节点选中的概率就是b/nb/n)。
我们令t=clog(n)t=clog(n)，可以得到y≈(n+1)−1ncb−2y≈(n+1)−1ncb−2。
这表明，仅需要O(log(n))O(log(n))个回合，gossip协议即可将信息传递到所有的节点。根据分析可得，Gossip协议具有以下的特点:
1、低延迟。仅仅需要O(log(n))O(log(n))个回合的传递时间。
2、非常可靠。仅有1ncb−21ncb−2个节点不会收到信息。
3、轻量级。每个节点传送了cblog(n)cblog(n)次信息。
Gossip的缺陷是：分布式网络中，没有一种完美的解决方案，Gossip 协议跟其他协议一样，也有一些不可避免的缺陷，主要是两个。
1、消息的延迟：由于 Gossip 协议中，节点只会随机向少数几个节点发送消息，消息最终是通过多个轮次的散播而到达全网的，因此使用 Gossip 协议会造成不可避免的消息延迟。不适合用在对实时性要求较高的场景下。
2、消息冗余：Gossip 协议规定，节点会定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤，因此就不可避免的存在消息重复发送给同一节点的情况，造成了消息的冗余。
同时也增加了收到消息的节点的处理压力。而且，由于是定期发送，因此，即使收到了消息的节点还会反复收到重复消息，加重了消息的冗余。
Consul 介绍
Consul有多个组件，但总体而言，它是基础架构中的一款服务发现和配置的工具。 它提供了几个关键功能：
Consul 是一个分布式，高可用的系统。 为了快速了解Consul的工作原理，本节只介绍基础知识，不会介绍详细的细节。
向Consul提供服务的每个节点都运行一个Consul代理。 发现其他服务或获取/设置键/值数据不需要运行代理。 代理负责健康检查节点上的服务以及节点本身。
代理与一个或多个Consul服务器通信。Consul 服务器是数据存储和复制的地方。 服务器自己选出一个 leader。 虽然Consul可以在一台服务器上运行，但推荐使用3到5台来避免数据丢失的情况。 每个数据中心都建议使用一组Consul服务器。
需要发现其他服务或节点的基础架构组件可以查询任何Consul服务器或任何Consul代理。 代理自动将查询转发到服务器。
每个数据中心都运行Consul服务器集群。 当跨数据中心服务发现或配置请求时，本地Consul服务器将请求转发到远程数据中心并返回结果。
Consul解决的问题是多种多样的，但是每个单独的特征已经被许多不同的系统解决了。 尽管没有单一的系统提供Consul的所有功能，但还有其他的选择可以解决这些问题。
ZooKeeper，doozerd和etcd在他们的架构中都是相似的。 所有这三个服务器节点都需要一定数量的节点才能运行（通常是简单多数）。 它们是高度一致的，并且公开了可以通过应用程序中的客户端库来构建复杂的分布式系统的各种基元。
Consul 还使用单个数据中心内的服务器节点。 在每个数据中心，Consul服务器都需要一个仲裁来操作并提供强大的一致性。 不过，Consul拥有对多个数据中心的本地支持，以及连接服务器节点和客户端的功能丰富的系统。
所有这些系统在提供键/值存储时都具有大致相同的语义：读取具有强烈的一致性，为了在网络分区的情况下保持一致性，牺牲了可用性。 但是，当这些系统用于高级案例时，这些差异会变得更加明显。
这些系统提供的语义对于构建服务发现系统是有吸引力的，但重要的是要强调必须构建这些功能。 ZooKeeper等软件仅提供原始K / V存储，并要求应用程序开发人员构建自己的系统以提供服务发现。 相比之下，Consul为服务发现提供了一个可用的框架，并且消除了猜测工作和开发工作。 客户端只需注册服务，然后使用DNS或HTTP接口执行发现。 其他系统需要一个自己定制的解决方案。
一个引人注目的服务发现框架必须包含健康检查和失败的可能性。 知道如果节点A失败或服务崩溃，则节点A提供Foo服务是没有用的。 原生系统使用心跳检测，定期更新和TTL。 这些方案需要与节点数量成线性关系，并将需求放在固定数量的服务器上。 此外，故障检测窗口至少与TTL一样长。
ZooKeeper提供临时节点，这些节点是客户端断开连接时删除的K / V条目。 这些比心跳系统更复杂，但仍然存在固有的可扩展性问题，并增加了客户端的复杂性。 所有客户端必须保持与ZooKeeper服务器的活动连接并执行保持活动。 另外，这需要“厚厚的客户端”，这些客户端很难编写，经常导致调试难题。
Consul 使用非常不同的体系结构进行健康检查。 Consul客户端不是只有服务器节点，而是在集群中的每个节点上运行。 这些客户端是gossip pool的一部分，可以提供多种功能，包括分布式健康检查。 gossip协议实现了一个高效的故障检测器，可以扩展到任何规模的集群，而不用将任务集中在任何选定的服务器组上。 客户端还可以在本地运行更丰富的运行状况检查，而ZooKeeper临时节点对活跃性进行非常原始的检查。 通过Consul，客户端可以检查Web服务器是否返回200的状态码，内存使用情况，有足够的磁盘空间等。和ZooKeeper一样，Consul客户端公开一个简单的HTTP接口，避免将系统的复杂性暴露给客户端。
Consul为服务发现，运行状况检查，K / V存储和多个数据中心提供一流的支持。 为了支持比简单K / V存储更多的功能，所有这些其他系统都需要额外的工具和库。 通过使用客户端节点，Consul提供了一个简单的API，只需要瘦客户端。 另外，完全可以通过使用配置文件和DNS接口完全避免使用API，以获得完整的服务发现解决方案，而完全没有任何开发。
使用Chef，Puppet和其他配置管理工具的人来构建服务发现机制并不罕见。 这通常通过查询全局状态来在定期收敛运行期间在每个节点上构建配置文件来完成。
不幸的是，这种方法有一些陷阱。 配置信息是静态的，不能比收敛运行更频繁地更新。 一般这是在几分钟或几小时的间隔。 另外，没有机制将系统状态结合到配置中：不健康的节点可能进一步接收流量，进一步加剧问题。 使用这种方法还可以支持多个数据中心，因为中央服务器组必须管理所有数据中心。
Consul专门设计为服务发现工具。 因此，它对集群的状态更具有动态性和响应性。 节点可以注册和注销他们提供的服务，使得依赖的应用程序和服务能够快速发现所有提供者。 通过使用集成的健康检查，Consul可以将流量从不健康的节点发送出去，从而使系统和服务能够正常恢复。 可以通过配置管理工具提供的静态配置可以移动到动态键/值存储中。 这允许应用程序配置更新，而不会收敛缓慢。 最后，由于每个数据中心独立运行，支持多个数据中心与单个数据中心没有区别。
也就是说，Consul并不是配置管理工具的替代品。 这些工具对于设置应用程序（包括Consul本身）至关重要。 静态配置***由现有工具管理，而动态状态和发现则由Consul更好地管理。 配置管理和集群管理的分离也有一些有利的副作用：Chef和Puppet在没有全局状态的情况下变得更简单，服务或配置更改不再需要定期运行，并且由于配置管理运行 不需要全局状态。
Nagios和Sensu都是用于监控的工具。 当问题发生时，它们用于快速通知操作员。
Nagios使用一组配置为在远程主机上执行检查的中央服务器。 这种设计使Nagios难以规模化，因为大型船队迅速达到垂直尺度的限制，Nagios不容易水平缩放。 Nagios在现代DevOps和配置管理工具中也非常难以使用，因为在添加或删除远程服务器时必须更新本地配置。
Sensu有一个更现代化的设计，依靠当地的代理商运行支票，并推动结果AMQP经纪人。 许多服务器从代理获取并处理健康检查的结果。 这个模型比Nagios更具可扩展性，因为它允许更多的水平缩放和服务器和代理之间的较弱耦合。 但是，中央经纪人已经具有扩展限制，并且是系统中的单一故障点。
Consul提供与Nagios和Sensu相同的健康检查能力，对现代DevOps友好，并避免了其他系统固有的扩展问题。 Consul在本地运行所有检查，如Sensu，避免给中央服务器造成负担。 检查状态由Consul服务器维护，这是容错的，没有单点故障。 最后，Consul可以扩展到更多的检查，因为它依赖于边缘触发的更新。 这意味着更新仅在检查从“通过”转换为“失败”或反之亦然时才被触发。
在一个大型的船队里，大部分的支票都是通过的，连失败的少数人都是执着的。 通过仅捕获更改，Consul减少了运行状况检查所使用的网络和计算资源的数量，从而使系统具有更高的可扩展性。
一个精明的读者可能会注意到，如果一个Consul代理死亡，那么没有边缘触发更新将会发生。 从其他节点的角度来看，所有的检查都会显示为稳定状态。 不过，Consul也是这样的。 客户端和服务器之间使用的gossip协议集成了一个分布式故障检测器。 这意味着如果一个Consul代理失败，将会检测到失败，并且因此所有由该节点运行的检查都可以被假定为失败。 这个故障检测器将工作分配到整个集群中，而最重要的是使边缘触发结构能够工作。
Eureka是一个服务发现工具。 该体系结构主要是客户机/服务器，每个数据中心有一套Eureka服务器，通常每个可用性区域一个。 通常Eureka的客户端使用嵌入式SDK来注册和发现服务。 对于不是本地集成的客户端，使用Ri***on等来透明地发现通过Eureka的服务。
Eureka提供了一个弱一致的服务观点，使用尽力而为复制。 当客户端向服务器注册时，该服务器将尝试复制到其他服务器，但不提供保证。 服务注册有一个短的生存时间（TTL），要求客户端向服务器发送心跳。 不健康的服务或节点将停止心跳，使他们超时并从注册表中删除。 发现请求可以路由到任何服务，由于尽力而为的复制，服务可能会陈旧或丢失数据。 这个简化的模型允许简单的集群管理和高可扩展性。
Consul提供了一套超级功能，包括更丰富的健康检查，key/value存储以及多数据中心意识。 Consul在每个数据中心都需要一组服务器，每个客户端都有一个代理，类似于使用像Ri***on这样的。 Consul代理允许大多数应用程序成为Consul不知道的，通过配置文件执行服务注册，并通过DNS或负载平衡器sidecars发现。
Consul提供强大的一致性保证，因为服务器使用Raft协议复制状态。 Consul支持丰富的健康检查，包括TCP，HTTP，Nagios / Sensu兼容脚本或基于Eureka的TTL。 客户端节点参与基于gossip的健康检查，该检查分配健康检查的工作，而不像集中式心跳一样成为可扩展性挑战。 发现请求被路由到当选的Consul leader，这使得他们在默认情况下是非常一致的。 允许陈旧读取的客户端使得任何服务器能够处理他们的请求，从而允许像Eureka这样的线性可伸缩性。
Consul强烈的一致性意味着它可以作为领导选举和集群协调的锁定服务。 Eureka不提供类似的保证，并且通常需要运行ZooKeeper来获得需要执行协调或具有更强一致性需求的服务。
Consul提供了支持面向服务的体系结构所需的工具包。 这包括服务发现，还包括丰富的健康检查，锁定，key/value，多数据中心联合，事件系统和ACL。 Consul和consul-template和envconsul等工具的生态系统都尽量减少集成所需的应用程序更改，以避免需要通过SDK进行本地集成。 Eureka是一个更大的Netflix OSS套件的一部分，该套件预计应用程序相对均匀且紧密集成。 因此，Eureka只解决了一小部分问题，希望ZooKeeper等其他工具可以一起使用。
gossip协议的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于gossip协议详解、gossip协议的信息别忘了在本站进行查找喔。