開發十年，就只剩下這套架構體系了！ >>>   

優點：

• 協議本身簡單，組網規模幾乎不受限制，通訊效能好

缺點：

• 不能提供傳統的資料一致性服務，在傳輸中佔用較多的網路流量

社群版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簡單、高效，同時具有很好的可擴充套件性和魯棒性，非常適合大規模、動態、資源受