Redis-Cluster-Gossip协议

优势：

• 协议自己简单，组网规模几乎不受限制，通讯性能好

缺点：

• 不能提供传统的数据一致性服务，在传输中占用较多的网络流量

社区版redis cluster是一个P2P无中心节点的集群架构，

• 依靠gossip协议传播协同自动化修复集群的状态。

Gossip是一种去中心化、容错并保证最终一致性的协议。

Gossip解决的问题就是在分布式环境下信息高效分发的问题，

• 这个问题的解决决定着系统的一致性程度。

Gossip协议是基于一种叫作SWIM的协议

• SWIM是一种无中心的分布式协议，
• 各个节点之间经过p2p实现信息交流同步各节点状态的方法。
• 看名字也知道这是一种弱一致性的实现。
• SWIM协议给每一个进程组成员在本地维护一个成员表，
  • 记录该组存活的进程。
  • 该协议经过失效检测器（Failure Detector）和传播组件（Dissemination Component）来完成工做。
• SWIM的失效检测器会检测失效的节点
  • 并将失效节点的更新信息发送给传播组件。
  • SWIM的传播组件经过多播（multicast）的形式将失效信息传播给组内的其余成员。
• 协议的可扩展性体如今：
  • 新成员的加入和退出也以一样的方式进行多播通讯。
  • 而在基本的时间周期内进行失效检测可以保证在限定的时间范围内完成完备性检查，
    • 即每一个失效的进程都能最终被检测到（最终一致性）。
  • 经过多播方式传输协议的问题在于效率很差也不可靠，
    • 经过在ping和ack消息中捎带成员更新信息可以下降丢包率和减小传输时延。
    • 这种传播方式被称为可传导的方式（Infection-style）。

Gossip来源于流行病学的研究

• 一个节点状态发生变化，并向临近节点发送更新信息
• 对于节点状态变化的信息随机发送给b个节点
• 随着时间推移，信息可以传达到全部的节点

协议的核心内容就是节点经过将信息随机发送到b个节点来完成本次信息的传播，

• 其涉及到周期性、配对、交互模式。
• Gossip的交互模式分为两种：
  • Anti-entropy
    • 每一个节点周期性地随机选择其余节点，
    • 而后经过相互交换本身的全部数据来消除二者之间的差别。
  • Rumor mongering。
    • 当一个节点有来新信息后，
    • 该节点变成活跃状态，
    • 并周期性地联系其余节点向其发送新信息。
• 每一个节点维护一个本身的信息表 <key, (value, version)> 
  • 即属性的值以及版本号
• 一个记录其余节点的信息表 <node, <key, (value, version)>> 
• 每一个节点和系统中的某个节点相互配对成为peer
  • 而节点的信息交换方式主要有3种。

    • Push：拥有状态新信息的节点随机选择联系节点并想起发送本身获得信息。

    • Pull：发起信息交换的节点随机选择联系节点并从对方获取信息。

    • Push-Pull混合模式：发起信息交换的节点向选择的节点发送信息。

总之，Gossip简单、高效，同时具备很好的可扩展性和鲁棒性，很是适合大规模、动态、资源受限的网络环境。