**
gossip演算法因為cassandra而名聲大噪，gossip看似簡單，但要真正弄清楚其本質遠沒看起來那麼容易。為了尋求gossip的本質，下面的內容主要參考gossip的原始**：<>。
gossip演算法如其名，靈感來自辦公室八卦，只要乙個人八卦一下，在有限的時間內所有的人都會知道該八卦的資訊，這種方式也與病毒傳播類似，因此gossip有眾多的別名「閒話演算法」、「疫情傳播演算法」、「病毒感染演算法」、「謠言傳播演算法」。
但gossip並不是乙個新東西，之前的泛洪查詢、路由演算法都歸屬於這個範疇，不同的是gossip給這類演算法提供了明確的語義、具體實施方法及收斂性證明。
gossip演算法又被稱為反熵（anti-entropy），熵是物理學上的乙個概念，代表雜亂無章，而反熵就是在雜亂無章中尋求一致，這充分說明了gossip的特點：在乙個有界網路中，每個節點都隨機地與其他節點通訊，經過一番雜亂無章的通訊，最終所有節點的狀態都會達成一致。每個節點可能知道所有其他節點，也可能僅知道幾個鄰居節點，只要這些節可以通過網路連通，最終他們的狀態都是一致的，當然這也是疫情傳播的特點。
要注意到的一點是，即使有的節點因宕機而重啟，有新節點加入，但經過一段時間後，這些節點的狀態也會與其他節點達成一致，也就是說，gossip天然具有分布式容錯的優點。
gossip是乙個帶冗餘的容錯演算法，更進一步，gossip是乙個最終一致性演算法。雖然無法保證在某個時刻所有節點狀態一致，但可以保證在」最終「所有節點一致，」最終「是乙個現實中存在，但理論上無法證明的時間點。
因為gossip不要求節點知道所有其他節點，因此又具有去中心化的特點，節點之間完全對等，不需要任何的中心節點。實際上gossip可以用於眾多能接受「最終一致性」的領域：失敗檢測、路由同步、pub/sub、動態負載均衡。
但gossip的缺點也很明顯，冗餘通訊會對網路頻寬、cup資源造成很大的負載，而這些負載又受限於通訊頻率，該頻率又影響著演算法收斂的速度，後面我們會講在各種場合下的優化方法。
根據原**，兩個節點（a、b）之間存在三種通訊方式:
如果把兩個節點資料同步一次定義為乙個週期，則在乙個週期內，push需通訊1次，pull需2次，push/pull則需3次，從效果上來講，push/pull最好，理論上乙個週期內可以使兩個節點完全一致。直觀上也感覺，push/pull的收斂速度是最快的。
假設每個節點通訊週期都能選擇（感染）乙個新節點，則gossip演算法退化為乙個二分查詢過程，每個週期構成乙個平衡二叉樹，收斂速度為o(n2 )，對應的時間開銷則為o(logn )。這也是gossip理論上最優的收斂速度。但在實際情況中最優收斂速度是很難達到的，假設某個節點在第i個週期被感染的概率為pi ,第i+1個週期被感染的概率為pi+1 ，則pull的方式:
而push為：
顯然pull的收斂速度大於push，而每個節點在每個週期被感染的概率都是固定的p(0個gossip的節點的工作方式又分兩種：
anti-entropy模式有完全的容錯性，但有較大的網路、cpu負載；rumor-mongering模式有較小的網路、cpu負載，但必須為資料定義」最新「的邊界，並且難以保證完全容錯，對失敗重啟且超過」最新「期限的節點，無法保證最終一致性，或需要引入額外的機制處理不一致性。我們後續著重討論anti-entropy模式的優化。
協調機制是討論在每次2個節點通訊時，如何交換資料能達到最快的一致性，也即消除兩個節點的不一致性。上面所講的push、pull等是通訊方式，協調是在通訊方式下的資料交換機制。協調所面臨的最大問題是，因為受限於網路負載，不可能每次都把乙個節點上的資料傳送給另外乙個節點，也即每個gossip的訊息大小都有上限。在有限的空間上有效率地交換所有的訊息是協調要解決的主要問題。
在討論之前先宣告幾個概念：
為了保證一致性，規定資料的value及version只有宿主節點才能修改，其他節點只能間接通過gossip協議來請求資料對應的宿主節點修改。
5.1 精確協調（precise reconciliation）
精確協調希望在每次通訊週期內都非常準確地消除雙方的不一致性，具體表現為相互傳送對方需要更新的資料，因為每個節點都在併發與多個節點通訊，理論上精確協調很難做到。精確協調需要給每個資料項獨立地維護自己的version，在每次互動是把所有的(key,value,version)傳送到目標進行比對，從而找出雙方不同之處從而更新。但因為gossip訊息存在大小限制，因此每次選擇傳送哪些資料就成了問題。當然可以隨機選擇一部分資料，也可確定性的選擇資料。對確定性的選擇而言，可以有最老優先（根據版本）和最新優先兩種，最老優先會優先更新版本最老的資料，而最新更新正好相反，這樣會造成老資料始終得不到機會更新，也即飢餓。
當然，開發這也可根據業務場景構造自己的選擇演算法，但始終都無法避免訊息量過多的問題。
5.2 整體協調（scuttlebutt reconciliation）
整體協調與精確協調不同之處是，整體協調不是為每個資料都維護單獨的版本號，而是為每個節點上的宿主資料維護統一的version。比如節點p會為(p1,p2,...)維護乙個一致的全域性version，相當於把所有的宿主資料看作乙個整體，當與其他節點進行比較時，只需必須這些宿主資料的最高version，如果最高version相同說明這部分資料全部一致，否則再進行精確協調。
整體協調對資料的選擇也有兩種方法：
經過驗證，cassandra實現了基於整體協調的push/pull模式，有幾個元件：
三條訊息分別對應push/pull的三個階段：
還有三種狀態：
heartbeat：心跳資訊
cassandra主要是使用gossip完成三方面的功能：
gossip是一種去中心化、容錯而又最終一致性的絕妙演算法，其收斂性不但得到證明還具有指數級的收斂速度。使用gossip的系統可以很容易的把server擴充套件到更多的節點，滿足彈性擴充套件輕而易舉。
唯一的缺點是收斂是最終一致性，不使用那些強一致性的場景，比如2pc。
Gossip演算法原理
gossip演算法如其名，靈感來自辦公室八卦，只要乙個人八卦一下，在有限的時間內所有的人都會知道該八卦的資訊，這種方式也與病毒傳播類似，因此gossip有眾多的別名 閒話演算法 疫情傳播演算法 病毒感染演算法 謠言傳播演算法 但gossip並不是乙個新東西，之前的泛洪查詢 路由演算法都歸屬於這個範疇...
Gossip演算法學習筆記
主要參考了 分布環境下的gossip演算法 這篇 幷包含在網上整理的一些資料。簡介 gossip 演算法又被稱為反熵 anti entropy 熵是物理學上的乙個概念，代表雜亂無章，而反熵就是在雜亂無章中尋求一致.gossip 的特點 在乙個有界網路中，每個節點都隨機地與其他節點通訊，經過一番雜亂無...
Gossip 協議詳解
gossip protocol 也叫 epidemic protocol 流行病協議 gossip protocol在1987年8月由施樂 帕洛阿爾托研究中心發表acm上的 epidemic algorithms for replicated database maintenance 中被提出。原本...