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簡單、高效，同時具備很好的可擴展性和魯棒性，很是適合大規模、動態、資源受限的網絡環境。