前言
前两篇文章分别介绍了Paxos和Raft，本篇将介绍另一种公式协议：Gossip协议
Paxos和Raft都是强一致性协议(各个节点之间的数据可能短期，但一定保证对外的数据一定是唯一的)，为了实现强一致性，就需要非常复杂的设计，尤其PAXOS从理解上就很难
但如果降低下标准，可以接受短期的不一致，只保证最终的一致性，事情就变得简单多了，比如redis集群，有些节点的数据可能不是最新数据，导致定位时出现错误，但redis集群本身有容错机制，错误了就可以重定向，总能找到正确的数据。所以类似这种场景，就可以降低标准，不需要完全的一致性了
Gossip协议就是这种最终一致性协议，所谓最终一致就是只在无修改后的一段时间后，所有节点都数据一直
Goossip协议翻译过来就是“八挂”，之前也被称为“病毒传播算法”，是指一个集群中没有主节点，任何节点都可以执行修改命令，然后像病毒传播一样，一传十，十传百，最终所有节点都会知道这次修改
本文继续延续之前通俗演绎的方式，依然用村里的故事讲述Gossip协议
传播
还是之前那个村子的故事，这把又没有村长了，现在还回到给村子起名这个事，规定任何人都可以修改村子的名字，任何人也可以把自己得知村子的名字告诉村外人
那比如张三把村子修改为“靠山村”，怎么告知其他村民呢，非常简单，就像谣言传播的方式一样，张三随机告诉一些村民，这些村民得知后又随机告诉另一些村民，久而久之，大家都知道这个村叫“靠山村”了
冲突
再回到一致性最关注的问题，冲突，假设现在张三把村子改成“靠山村”，而李四要改成“靠海村”，那村民到底听谁的？
这个问题在PAXOS中及其复杂，但gossip中就非常简单：每个村民的修改必然有提出的先后顺序，比如张三9点提出的，李四10点提出的，那李四的修改就是更新的消息
而村民的规则非常简单，只要听到的消息比自己的消息新，就接受
就这么简单么？还真就这么简单，不需要提案确认等等复杂操作，那会有什么问题么？
问题就是某村民听说了张三的9点消息，后来李四的修改传出来了但他还没收到，他就会以为村子还叫“靠山村”。但这个问题恰恰是goossip可以接受的短期不一致，最终消息传啊传，李四把村子改成“靠海村”的消息这个村民一定会知道，也就是最终一致
在一个消息传递速度不确定的问题，加入一个村民先得知李四10点得消息，此时才听说张三9点得消息，那么问题也很简单，这个村民已经有更新得消息了，自然会拒绝旧消息
反熵
上面得描述有一个问题，村民人传人得方式，每个村民通知给谁都是很随意的选择几个人传播信息，但这样会有概率出现一个村民是个超级倒霉蛋，恰好谁都没通知到他
为了避免这种事情，goossip引入了反熵，也非常简单：每个村民都会定时去找一些其他村民互通有无，这样就可以为最终一致兜底了
总结
gossip协议舍弃了强一致，所以他的实现非常简单，同时它没有主节点，任何节点都可以改，也都可以读，所以效率非常高，在CAP理论中，gossip协议偏AP，而raft这种旧偏CP
