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简单、高效，同时具有很好的可扩展性和鲁棒性，非常适合大规模、动态、资源受限的网络环境。

来源：oschina

链接：https://my.oschina.net/u/3847203/blog/3024666