绯闻女孩传八卦也能作为区块链协议？10分钟告诉你为啥
《Gossip Girl（绯闻女孩）》剧照
你一定看过《绯闻女孩》这部剧，反正营长是一遍又一遍看了无数遍，喜欢喜欢！但咱们今天不讨论这部剧的剧情（其实营长很乐意），营长想和你们说一说与八卦有关的事儿，such as “八卦”协议，也就是“Gossip protocol”，它和区块链有啥关系？别急，请往下看。
随着比特币等数字加密货币的兴起，区块链技术逐渐升温，霎时间，各种区块链技术落地场景应运而生。但是关于区块链技术本身，“去中心化”、“数据不可篡改”、“数据溯源”、“共识机制”等词语散落在大众的脑海中。
鉴于区块链的分布式架构，第一个要解决的问题便是在通信中如何保证信息的一致性，如果分布式集群的处理结果不能得到一致性的保障，那么建立在其上的任何业务也就无法正常运行。广为人知的 Gossip 协议在节点间的信息同步问题中，便能够发挥巨大的作用。
CAP 原理指出，分布式计算系统中不可能同时确保一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance），因此，在设计系统时往往需要弱化对某个特性的支持。
了解一下“八卦”协议？
Gossip 协议就是为一些弱化了一致性的应用场景设计、用来实现节点间的信息同步，解决分布式架构中的信息一致性问题。
Gossip 协议，又称“八卦”协议，用于系统内节点之间的相互通信，就是模拟人类传播八卦的方式而产生的，类似于社交网络消息传播方式或者是流行性疾病的传染方式。Gossip 是以数学为基础、具有扎实理论分析基础的去中心化分布式通讯协议，即系统内节点之间相互通信的通信机制。
Gossip 协议可类比八卦新闻在社交网络中的传播。 最初只有一个或者少数几个人知道某个八卦新闻，得知该八卦新闻的人都在自己的好友圈转发，虽然每个人的好友数量有限，但该八卦新闻却能够在社交网络中快速发酵。
简单来说，在一个网络中，每个节点都随机地和其他节点进行通信，当一个节点要发送消息时，该节点随机地选择对等的节点并发送消息，这些节点收到消息后将重复同样的过程，再将消息转发给网络中其他随机选择的对等节点，最终所有节点的状态都能够达成一致。
要进行“谣言”传播，首先需要有种子节点，种子节点经过一定时间间隔都会随机向其他节点发送自己所拥有的节点列表以及需要传播的消息。任何新加入的节点，通过这样的传播便很快地被整个网络获取。
在最开始，并不需要将信息传递给所有的节点，但随着时间的增长，“谣言”逐步扩散，在“最终”的某一时刻，全网便会得到相同的信息，也即弱化了一致性，强调实现最终一致性。Gossip 解决的问题也就是在分布式环境下信息高效分发的问题，决定了系统的一致性程度。
在超级账本 Fabric 和 Cassandra 数据库中，Gossip 协议在其信息同步中都发挥了重要作用。
在 Hyperledger Fabric 的交易流程中，Peer 节点作为参与交易的主体，主要负责存储完整的区块链数据、执行智能合约，Peer 节点之间可以通过 Gossip 协议来完成区块分发、状态同步等问题。
在每个 Peer 节点上都维护了其它 Peer 节点的信息，通过随机的与其它 Peer 节点通信来交换信息，达到最终一致性。主要过程为通过 GossipClient 客户端的 GossipStream 双向流进行通信，发送 SignedGossipMessage 消息结构。
Apache 的分布式数据库 Cassandra 中，各节点地位平等、各自独立，通过 Gossip 协议进行各个节点间的数据通信，其主要功能是在 Cassandra 集群中的所有节点之间快速高效地传递各个节点的状态和信息。
如果处于交换状态的节点在信息传递时长时间未响应，则此时执行请求的节点就会将目标节点标记为失灵，并通过 Gossip 协议将该节点的状态传出去。
通过这样的方式，Cassandra 数据库就可以确定能够用来高效存储数据的健康节点，并在这些节点上进行数据的操作，从而避免了节点信息交换故障导致的无效或者错误操作，降低了时间成本，同时提高了系统效率。
“八卦”协议模型
明白了 Gossip 协议及其用途，我们来探究一下 Gossip 协议的具体模型，它主要由时间模型和消息更新模型组成。
按照采用的时间模型来看，Gossip 协议可以分为同步 Gossip 协议和异步 Gossip 协议。同步 Gossip 协议是指网络中的节点有确定的时序关系，节点按照一定的时序关系进行数据交换。
而异步单播 Gossip 协议是在每一个时间间隔中随机地唤醒网络中的一个节点，被唤醒的节点再随机地选择邻接节点进行数据交换。因为同步问题较为复杂，所以同步 Gossip 协议在实际生产环境中的应用较少。
按照节点之间信息更新的方式，Gossip 协议可以分为基于单播的 Gossip 协议和基于广播的 Gossip 协议。
单播 Gossip 协议是指被唤醒的节点每次只选择它的一个邻接节点进行数据交换。单播 Gossip 协议的收敛性和收敛速度可证明，且能够收敛于网络的初始均值。但是单播 Gossip 的收敛速度很大程度上依赖于网络结构。
广播 Gossip 协议是指在一次迭代过程中，随机地唤醒一个节点，被唤醒的节点与所有的邻接节点均进行信息交换。广播 Gossip 协议无法保证其收敛状态值等于网络初始状态的均值。
“八卦”协议下的节点交互模式
Gossip的两个节点A、B之间有三种交互模式：
1、Push 模式：B节点将数据（key，value，version）及对应的版本号推送给 A 节点，A 节点更新 B 节点中比自己新的数据。在 Push 模式中，发起信息交换的节点随机选取节点并向其发送自己的信息，一般拥有新信息的节点才会作为发起节点。
假设存在 n 个节点，采用 Push 方式，在数据传播的初期，已收到消息的节点数目呈指数增长，直到有一半节点收到该消息。此后，未收到消息的节点集合将会在每一轮以一个常数因子进行收缩。当消息传播过程结束时该常数因子为，因为在一轮中没有收到消息的节点的占。因此，收缩过程将会通过轮直到所有的节点均收到消息，Push 模式在每一轮中发送的消息数量为。
2、Pull 模式：A 仅将数据 key、version 推送给 B，B 将本地比 A 新的数据（key，value，version）推送给 A，A 更新本地。
在 Pull 模式中，发起数据交换的节点随机选择节点并获取所选节点的数据，一般无新数据的节点才会作为发起节点。Pull 方式与 Push 方式相反，在数据传播的初期，收到消息的节点的数量增长缓慢；当已有一半节点收到消息之后，每轮过后未收到消息的节点占比将呈平方收缩。
这是因为在一轮开始时假设有个未收到消息的节点，每一个节点将有的概率收到消息，因此节点保持未收到消息状态的概率为，这一轮结束后未收到消息的节点数量为。因此，未收到消息的节点数量的收缩过程仅需要轮，该过程中每一轮传递的消息数量为。
3、Push-Pull 模式：在 Pull 的基础上，A 再将本地比 B 新的数据推送给 B，然后 B 再更新本地数据。也就是在 Pull 之后，A 再对比自己掌握的信息，更新 B 手中掌握的信息。
Push-Pull 模式是结合了具备可预测性的 Push 机制和具备平方收缩特性的 Pull 机制，在这种模式下，消息双向发送。发起信息交换的节点先初始化一个时间计数器来代表信息的生命值，初始计数为 0。
信息的生命值会随着每次传播而递增。发起信息交换的节点随机选取节点并向其发送自己的消息，同时从所选取的节点上获取该节点的消息，这个过程将持续进行直到消息的生命值超过。
假设存在 n 个节点，在全连通网络中采用 Push-Pull 的方式，那么完成 Gossip 过程需要轮和次数据交换。
- 想象 A、B 是老同学，毕业后工作在同一家公司，朝夕相处， A 想要了解 B 的信息，B 就只需要把 A 不知道的事情告诉他，类似于“推”模式。
- 倘若只是工作在同一栋楼，两人掌握的信息依然有一定的交集，A 与 B 在简单的交流后，B 就可以告诉 A 所不知道的信息，就类似于“拉”模式。
- 如果两个人毕业后在不同的国家，在信息内容上基本没有交集，这时候就需要将自己知道的全部信息告诉彼此，也就类似于“推-拉”模式。
通过这样类似“推”、“拉”的方式，完成了节点间信息的同步。
知识拓展：其他通信协议
在分布式中，除了 Gossip 这个通信协议，还有 Totem 协议、Paxos 协议等。
其中，Totem 协议在节点间形成单环结构，通过 token，利用类似于“丢手绢”的形式，实现消息的传递，只有拿到 token 的节点才能够发送消息，以此来保证消息的有序性。
Paxos 协议通俗来讲，类似于二阶段提交，就是在第一个阶段由一个节点询问其它节点是否可以进行消息的提交，如果超过半数节点响应，则可以进行消息提交，否则失败；在第二阶段超过半数响应才能够进行消息写入，同时需要满足一定的前提。
相比 Totem 协议、Paxos 协议等强一致性的协议，Gossip 协议适当放宽了对一致性的要求，降低了系统实现的难度，强调在一定约束下实现最终一致性，即总会在某一个时刻，系统达到一致的状态。
Trias CTO 魏明
作者简介：
Trias 联合创始人 & CTO，北京大学博士；曾任中国航天软件研发中心高级架构师、西门子研究院工程师；发表国内外论文十余篇，申请专利十余项。