Gossip 協(xié)議解析
原文發(fā)布于 systemdesign.one 網(wǎng)站。翻譯自 Gossip Protocol Explained 。
什么是Gossip協(xié)議？
分布式系統(tǒng)中典型的問題包括以下幾點(diǎn)[1]，[11]：
維護(hù)系統(tǒng)狀態(tài)（節(jié)點(diǎn)的存活性）
節(jié)點(diǎn)之間的通信
解決這些問題的潛在方案如下[1]：
集中式狀態(tài)管理服務(wù)
點(diǎn)對點(diǎn)狀態(tài)管理服務(wù)
集中式狀態(tài)管理服務(wù)
集中式狀態(tài)管理服務(wù)（如 Apache Zookeeper ）可以配置為服務(wù)發(fā)現(xiàn)，以跟蹤系統(tǒng)中每個(gè)節(jié)點(diǎn)的狀態(tài)。盡管這種方法提供了強(qiáng)一致性保證，但其主要缺點(diǎn)是狀態(tài)管理服務(wù)成為單點(diǎn)故障，并且在大規(guī)模分布式系統(tǒng)中會(huì)遇到可伸縮性問題[1]，[11]。
點(diǎn)對點(diǎn)狀態(tài)管理服務(wù)
點(diǎn)對點(diǎn)狀態(tài)管理方法傾向于高可用性和最終一致性。Gossip 協(xié)議算法可用于實(shí)現(xiàn)具有高可伸縮性和改進(jìn)的韌性的點(diǎn)對點(diǎn)狀態(tài)管理服務(wù)[1]。
Gossip 協(xié)議也被稱為流言協(xié)議，因?yàn)樾畔鬟f方式類似于疾病傳播的方式。Gossip 協(xié)議中的通信概念類似于辦公室員工之間傳播謠言或社交媒體網(wǎng)站上信息傳播的方式[4]，[8]。
廣播協(xié)議
分布式系統(tǒng)中流行的消息廣播技術(shù)如下：
點(diǎn)對點(diǎn)廣播
急切可靠廣播
Gossip協(xié)議
點(diǎn)對點(diǎn)廣播
生產(chǎn)者直接將消息發(fā)送給消費(fèi)者的方式是點(diǎn)對點(diǎn)廣播。生產(chǎn)者上的重試機(jī)制和消費(fèi)者上的去重機(jī)制使得點(diǎn)對點(diǎn)廣播是可靠的。當(dāng)生產(chǎn)者和消費(fèi)者同時(shí)發(fā)生故障時(shí)，消息將會(huì)丟失[3]。
急切可靠廣播
每個(gè)節(jié)點(diǎn)通過可靠的網(wǎng)絡(luò)鏈接將消息重新廣播給其他每個(gè)節(jié)點(diǎn)。這種方法提供了更好的容錯(cuò)能力，因?yàn)樵谏a(chǎn)者和消費(fèi)者同時(shí)發(fā)生故障時(shí)，消息不會(huì)丟失。剩余的節(jié)點(diǎn)將重新廣播消息。急切可靠廣播的注意事項(xiàng)如下[3]，[8]：
由于廣播 n 個(gè)節(jié)點(diǎn)的 O(n2) 條消息，導(dǎo)致顯著的網(wǎng)絡(luò)帶寬使用
由于 O(n) 線性廣播，發(fā)送節(jié)點(diǎn)可能成為瓶頸
每個(gè)節(jié)點(diǎn)都存儲(chǔ)系統(tǒng)中所有節(jié)點(diǎn)的列表，導(dǎo)致存儲(chǔ)成本增加
Gossip 協(xié)議
Gossip 協(xié)議是一種用于在龐大的分布式系統(tǒng)中傳輸消息的去中心化點(diǎn)對點(diǎn)通信技術(shù)[1]，[8]。Gossip 協(xié)議的關(guān)鍵概念是每個(gè)節(jié)點(diǎn)定期向其他隨機(jī)節(jié)點(diǎn)的子集發(fā)送消息[8]，[2]。整個(gè)系統(tǒng)最終將以很高的概率接收到特定的消息[11]，[3]。通俗地說，Gossip 協(xié)議是一種通過有限的本地交互來使節(jié)點(diǎn)構(gòu)建全局地圖的技術(shù)[1]。
Gossip 協(xié)議構(gòu)建在穩(wěn)健、可伸縮和最終一致的算法之上。Gossip 協(xié)議通常用于在分布式系統(tǒng)中維護(hù)節(jié)點(diǎn)成員列表、實(shí)現(xiàn)共識(shí)和故障檢測[2]。此外，額外的信息，如應(yīng)用層數(shù)據(jù)，可以附加在 Gossip 消息中[1]。
Gossip 協(xié)議是可靠的，因?yàn)楣?jié)點(diǎn)故障可以通過另一個(gè)節(jié)點(diǎn)的消息重新傳輸來克服。FIFO 廣播、因果廣播和全序廣播可以通過 Gossip 協(xié)議實(shí)現(xiàn)[3]。
Gossip 協(xié)議的參數(shù)，如周期和廣播數(shù)，可以調(diào)整以提高 Gossip 協(xié)議的概率保證。以下工具提供 Gossip 協(xié)議的高端模擬和可視化[8]，[5]：
serf 收斂模擬器
Gossip 模擬器
Gossip 協(xié)議的以下特性使其成為大規(guī)模分布式系統(tǒng)中通信協(xié)議的最佳選擇[12]：
限制每個(gè)節(jié)點(diǎn)傳輸?shù)南?shù)量
限制帶寬消耗，以防止應(yīng)用性能降低
容忍網(wǎng)絡(luò)和節(jié)點(diǎn)故障
只有當(dāng)執(zhí)行的操作是可交換的且不需要序列化時(shí)，才能使用 Gossip 協(xié)議來保持節(jié)點(diǎn)一致。?tombstone?是一種特殊的條目，用于使具有匹配鍵的數(shù)據(jù)條目無效，而無需實(shí)際刪除數(shù)據(jù)。Gossip 協(xié)議使用?tombstone?來從節(jié)點(diǎn)中刪除數(shù)據(jù)。
Gossip 協(xié)議的類型
在選擇特定用例的 Gossip 協(xié)議類型時(shí)，必須考慮 Gossip 協(xié)議傳播消息所需的時(shí)間以及在傳播消息中產(chǎn)生的網(wǎng)絡(luò)流量。Gossip 協(xié)議可以大致分為以下幾種類型[8]，[10]：
抗熵模型
謠言傳播模型
聚合模型
抗熵 Gossip 協(xié)議
抗熵算法是為了減少類似數(shù)據(jù)庫的有狀態(tài)服務(wù)的副本之間的熵。比較復(fù)制的數(shù)據(jù)并修復(fù)副本之間的差異[10]。具有最新消息的節(jié)點(diǎn)會(huì)在每個(gè) Gossip 循環(huán)中與其他節(jié)點(diǎn)共享它[8]。
抗熵模型通常傳輸整個(gè)數(shù)據(jù)集，導(dǎo)致不必要的帶寬使用?？梢允褂眯ｒ?yàn)和、最近更新列表和 Merkle 樹等技術(shù)來識(shí)別節(jié)點(diǎn)之間的差異，以避免傳輸整個(gè)數(shù)據(jù)集并降低網(wǎng)絡(luò)帶寬使用?？轨?Gossip 協(xié)議將發(fā)送無限數(shù)量的消息而不終止[8]。
謠言傳播 Gossip 協(xié)議
謠言傳播協(xié)議也稱為傳播協(xié)議。謠言傳播循環(huán)相對于抗熵循環(huán)發(fā)生得更頻繁，并以最壞情況的負(fù)載淹沒網(wǎng)絡(luò)[10]。謠言傳播模型僅使用最新的更新傳輸?shù)焦?jié)點(diǎn)，因此使用的資源較少，如網(wǎng)絡(luò)帶寬[8]。
在幾輪通信后，消息將被標(biāo)記為已刪除，以限制消息數(shù)量。通常有很高的概率使消息傳遞到所有節(jié)點(diǎn)[8]。
聚合 Gossip 協(xié)議
聚合 Gossip 協(xié)議通過對每個(gè)節(jié)點(diǎn)的信息進(jìn)行抽樣并將值組合起來生成系統(tǒng)范圍的聚合值[10]。
進(jìn)一步的系統(tǒng)設(shè)計(jì)學(xué)習(xí)資源
訂閱系統(tǒng)設(shè)計(jì)通訊，以便不再錯(cuò)過新的博客文章。您還將在通訊注冊時(shí)收到接近系統(tǒng)設(shè)計(jì)面試的終極指南。
通過 Gossip 協(xié)議傳播消息的策略
Gossip 協(xié)議是構(gòu)建高可用性服務(wù)的最佳框架。選擇通過 Gossip 協(xié)議傳播消息的策略應(yīng)該基于服務(wù)需求和可用的網(wǎng)絡(luò)條件。每種通過 Gossip 協(xié)議傳播消息的策略都涉及帶寬、延遲和可靠性方面的權(quán)衡。這些傳播消息的策略適用于抗熵和謠言傳播模型。通過 Gossip 協(xié)議傳播消息的不同策略如下[8]，[5]，[2]：
推送模型
拉取模型
推拉模型
推送模型
當(dāng)只有少量更新消息時(shí)，推送模型是高效的，因?yàn)樗鼤?huì)產(chǎn)生流量開銷。推送模型中，具有最新消息的節(jié)點(diǎn)將消息發(fā)送給其他節(jié)點(diǎn)的隨機(jī)子集[8]。
拉取模型
每個(gè)節(jié)點(diǎn)在拉取模型中主動(dòng)輪詢隨機(jī)節(jié)點(diǎn)的子集，以查找任何更新消息。當(dāng)存在許多更新消息時(shí)，此方法是高效的，因?yàn)楹苡锌赡苷业骄哂凶钚赂孪⒌墓?jié)點(diǎn)[8]。
推拉模型
推拉模型是快速可靠地傳播更新消息的最佳策略[2]。節(jié)點(diǎn)可以推送新的更新消息，也可以拉取新的更新消息。在初始階段使用推送方法是高效的，因?yàn)橹挥泻苌俚墓?jié)點(diǎn)具有更新消息。在最后階段，由于有很多具有許多更新消息的節(jié)點(diǎn)，使用拉取方法是高效的[8]。
Gossip 協(xié)議性能
從特定節(jié)點(diǎn)傳播消息的節(jié)點(diǎn)數(shù)量稱為?fanout?。傳播消息跨越整個(gè)群集所需的 Gossip 循環(huán)數(shù)量稱為?cycle?[8]，[5]。
傳播消息跨越群集所需的 cycle 數(shù) = 以 fanout 為基數(shù)的 O(log n) ，其中 n = 節(jié)點(diǎn)總數(shù)
例如，對于傳播消息到 25000 個(gè)節(jié)點(diǎn)，大約需要 15 個(gè) Gossip cycle 。可以將 Gossip 間隔設(shè)置為 10 毫秒，以在大型數(shù)據(jù)中心內(nèi)大約 3 秒內(nèi)傳播消息。為了減少不必要的負(fù)載，Gossip 協(xié)議中的消息傳播應(yīng)該自動(dòng)過期[4]。Gossip 協(xié)議實(shí)現(xiàn)的性能可以用以下指標(biāo)來衡量[8]：
殘余：尚未接收到消息的剩余節(jié)點(diǎn)數(shù)量應(yīng)該最小化
流量：節(jié)點(diǎn)之間平均發(fā)送的消息數(shù)應(yīng)該最小化
收斂：每個(gè)節(jié)點(diǎn)應(yīng)盡快接收到消息
時(shí)間平均：將消息發(fā)送到每個(gè)節(jié)點(diǎn)所花費(fèi)的平均時(shí)間應(yīng)該較低
時(shí)間最后：最后一個(gè)節(jié)點(diǎn)接收到消息所花費(fèi)的時(shí)間應(yīng)該較低
一項(xiàng)案例研究顯示，擁有 128 個(gè)節(jié)點(diǎn)的系統(tǒng)在運(yùn)行 Gossip 協(xié)議時(shí)，CPU 消耗不到 2％ ，帶寬消耗不到 60 KBps[11] 。
Gossip協(xié)議特性
沒有正式定義 Gossip 協(xié)議的方式。一般來說，Gossip 協(xié)議應(yīng)滿足以下特性[8]：
節(jié)點(diǎn)選擇必須是隨機(jī)的，以執(zhí)行廣播
每個(gè)節(jié)點(diǎn)只能獲得本地信息，對集群狀態(tài)不了解
節(jié)點(diǎn)之間的通信涉及周期性的兩兩進(jìn)程交互
每個(gè) Gossip cycle 的傳輸容量有限
每個(gè)節(jié)點(diǎn)都采用相同的 Gossip 協(xié)議
假設(shè)節(jié)點(diǎn)之間的網(wǎng)絡(luò)路徑是不可靠的
節(jié)點(diǎn)交互頻率較低
節(jié)點(diǎn)交互會(huì)導(dǎo)致狀態(tài)交換
Gossip 算法
Gossip算法的高級概述如下[6]，[1]：
每個(gè)節(jié)點(diǎn)維護(hù)一組子集節(jié)點(diǎn)及其元數(shù)據(jù)的列表
定期向隨機(jī)的活動(dòng)對等節(jié)點(diǎn)的端點(diǎn)發(fā)出 Gossip
每個(gè)節(jié)點(diǎn)檢查接收到的 Gossip 消息，將最高版本號(hào)合并到本地?cái)?shù)據(jù)集中
節(jié)點(diǎn)的心跳計(jì)數(shù)器在特定節(jié)點(diǎn)參與 Gossip 交換時(shí)遞增。只要心跳計(jì)數(shù)器保持增長，節(jié)點(diǎn)就會(huì)被標(biāo)記為健康。另一方面，如果心跳計(jì)數(shù)器在長時(shí)間內(nèi)沒有改變，說明發(fā)生了網(wǎng)絡(luò)分區(qū)或節(jié)點(diǎn)故障，該節(jié)點(diǎn)被視為不健康[1]。Gossip 協(xié)議中的對等節(jié)點(diǎn)選擇具有不同的標(biāo)準(zhǔn)[12]：
利用由編程語言提供的庫，如 java.util.random
與最少接觸的節(jié)點(diǎn)交互
實(shí)施網(wǎng)絡(luò)拓?fù)涓兄慕换?/p>
Gossip協(xié)議實(shí)現(xiàn)
Gossip 協(xié)議通過 User Datagram Protocol (UDP) 或 Transmission Control Protocol (TCP) 傳輸消息，并具有可配置但固定的廣播數(shù)和間隔[12]。Gossip 協(xié)議使用節(jié)點(diǎn)的對等抽樣服務(wù)來識(shí)別用于 Gossip 消息交換的對等節(jié)點(diǎn)。對等抽樣服務(wù)使用隨機(jī)算法選擇對等節(jié)點(diǎn)。對等抽樣服務(wù)的應(yīng)用程序編程接口(API)應(yīng)提供以下端點(diǎn)[8]：
/gossip/init：返回特定節(jié)點(diǎn)在啟動(dòng)時(shí)所知的節(jié)點(diǎn)列表
/gossip/get-peer：返回獨(dú)立對等節(jié)點(diǎn)的地址（IP地址和端口號(hào)）
對等抽樣服務(wù)執(zhí)行的工作流程如下[8]：
將每個(gè)節(jié)點(diǎn)初始化為系統(tǒng)的部分視圖（帶有子集節(jié)點(diǎn)列表）
將節(jié)點(diǎn)視圖與對等節(jié)點(diǎn)的視圖在 Gossip 交換中合并
換句話說，每個(gè)節(jié)點(diǎn)維護(hù)一個(gè)小的本地成員表，其中包含系統(tǒng)的部分視圖，并通過 Gossip 消息定期刷新該表。Gossip 協(xié)議可以利用概率分布來選擇對等節(jié)點(diǎn)，以減少向相同節(jié)點(diǎn)的重復(fù)消息傳輸[4]。
應(yīng)用程序狀態(tài)可以作為鍵值對通過 Gossip 協(xié)議傳輸。當(dāng)節(jié)點(diǎn)對同一鍵執(zhí)行多個(gè)更改時(shí)，必須傳輸最新的值。Gossip 協(xié)議提供的 API 來組織應(yīng)用程序狀態(tài)交換如下[6]：
/gossip/on-join
/gossip/on-alive
/gossip/on-dead
/gossip/on-change
種子節(jié)點(diǎn)是基于靜態(tài)配置的完全功能節(jié)點(diǎn)。系統(tǒng)中的每個(gè)節(jié)點(diǎn)都必須知道種子節(jié)點(diǎn)。Gossip 系統(tǒng)與種子節(jié)點(diǎn)交互，以防止邏輯分區(qū)[4]，[12]。當(dāng)一個(gè)節(jié)點(diǎn)接收到具有對等節(jié)點(diǎn)的節(jié)點(diǎn)元數(shù)據(jù)的 Gossip 消息時(shí)，以下是高級工作流程[12]：
比較傳入的Gossip消息，以識(shí)別本地節(jié)點(diǎn)數(shù)據(jù)集中的缺失值
比較傳入的Gossip消息，以識(shí)別對等節(jié)點(diǎn)數(shù)據(jù)集中的缺失值
當(dāng)節(jié)點(diǎn)已經(jīng)包含傳入Gossip消息中存在的值時(shí)，選擇更高版本值
在本地節(jié)點(diǎn)數(shù)據(jù)集中添加缺失值
在響應(yīng)中返回對等節(jié)點(diǎn)數(shù)據(jù)集中的缺失值
使用接收到的響應(yīng)更新對等節(jié)點(diǎn)數(shù)據(jù)集
通常，在節(jié)點(diǎn)啟動(dòng)時(shí)將整個(gè)節(jié)點(diǎn)元數(shù)據(jù)傳輸通過 Gossip 協(xié)議。每個(gè)節(jié)點(diǎn)可以維護(hù)一個(gè)內(nèi)存中的版本號(hào)，通過 Gossip 協(xié)議只發(fā)送節(jié)點(diǎn)元數(shù)據(jù)的增量更新[6]。
生成時(shí)鐘是一個(gè)遞增的表示服務(wù)器生成的數(shù)字。每當(dāng)節(jié)點(diǎn)重新啟動(dòng)時(shí)，生成時(shí)鐘都會(huì)增加。版本號(hào)保證應(yīng)用程序狀態(tài)的排序和版本控制。版本號(hào)只能遞增[6]。在節(jié)點(diǎn)重新啟動(dòng)時(shí)，可以使用生成時(shí)鐘和版本號(hào)來正確檢測節(jié)點(diǎn)元數(shù)據(jù)的更改[12]。
Gossip 定時(shí)器是 Gossip 協(xié)議的一個(gè)組件，它確保每個(gè)節(jié)點(diǎn)最終包含有關(guān)對等節(jié)點(diǎn)的關(guān)鍵元數(shù)據(jù)，包括網(wǎng)絡(luò)分區(qū)后的節(jié)點(diǎn)。每個(gè)節(jié)點(diǎn)都包含一個(gè)與之關(guān)聯(lián)的心跳。心跳狀態(tài)包含生成和版本號(hào)。應(yīng)用程序狀態(tài)包含表示節(jié)點(diǎn)狀態(tài)的鍵值對和版本號(hào)[6]。
發(fā)起 Gossip 交換的節(jié)點(diǎn)發(fā)送一個(gè) Gossip 摘要同步消息，其中包含 Gossip 摘要列表。Gossip 摘要包含端點(diǎn)地址、生成號(hào)和版本號(hào)。Gossip 摘要確認(rèn)消息包含 Gossip 摘要列表和端點(diǎn)狀態(tài)列表。Gossip 摘要的示例模式如下[6]：
Gossip 協(xié)議的使用案例
Gossip 協(xié)議用于多種應(yīng)用，其中偏向于最終一致性。Gossip 協(xié)議的流行應(yīng)用如下[8]，[5]，[4]，[7]，[12]：
數(shù)據(jù)庫復(fù)制
信息傳播
維護(hù)集群成員資格
故障檢測
生成聚合（計(jì)算平均值、最大值、總和）
生成覆蓋網(wǎng)絡(luò)
領(lǐng)導(dǎo)者選舉
Gossip 協(xié)議可以用于在分布式系統(tǒng)中高概率地檢測節(jié)點(diǎn)的故障。節(jié)點(diǎn)故障的檢測可以節(jié)省 CPU、帶寬和隊(duì)列空間等資源。在分布式系統(tǒng)中，如果一個(gè)單獨(dú)的客戶端無法與特定節(jié)點(diǎn)進(jìn)行交互，僅僅憑此無法斷定該節(jié)點(diǎn)發(fā)生了故障，因?yàn)榭赡馨l(fā)生了網(wǎng)絡(luò)分區(qū)或客戶端故障[1]。只有在多個(gè)節(jié)點(diǎn)（客戶端）通過 Gossip 協(xié)議確認(rèn)特定節(jié)點(diǎn)的活動(dòng)時(shí)，才能確定特定節(jié)點(diǎn)的故障[4]，[11]。
Gossip 協(xié)議比通過 TCP 連接更加可靠，用于數(shù)據(jù)交換和命令與控制。Gossip 協(xié)議使得應(yīng)用程序邏輯中的節(jié)點(diǎn)和子系統(tǒng)屬性的通信抽象出來[11]。例如，節(jié)點(diǎn)統(tǒng)計(jì)信息（如平均負(fù)載和可用內(nèi)存）可以通過 Gossip 消息傳輸，以改進(jìn)本地決策過程。
子系統(tǒng)信息（如隊(duì)列深度、配置更改等的關(guān)鍵元數(shù)據(jù)）甚至請求-響應(yīng)等信息也可以通過Gossip協(xié)議傳輸。通過 Gossip 協(xié)議對節(jié)點(diǎn)更新消息的聚合允許以單個(gè)塊而不是多個(gè)小消息的形式發(fā)送數(shù)據(jù)，從而減少通信開銷[11]。
消息可以通過識(shí)別節(jié)點(diǎn)的活動(dòng)狀態(tài)在群集中進(jìn)行最優(yōu)路由[9]。在不涉及集中式服務(wù)的情況下進(jìn)行本地節(jié)點(diǎn)級別的決策是 Gossip 協(xié)議可擴(kuò)展的關(guān)鍵[4]，[11]。消息可以使用向量時(shí)鐘進(jìn)行版本化，節(jié)點(diǎn)可以忽略較舊的消息版本[9]，[2]。Gossip 協(xié)議的現(xiàn)實(shí)世界應(yīng)用案例包括以下幾種[12]，[8]，[4]，[9]，[11]：
Apache Cassandra?使用 Gossip 協(xié)議來維護(hù)集群成員資格、傳輸節(jié)點(diǎn)元數(shù)據(jù)（標(biāo)記分配）、使用 Merkle 樹修復(fù)未讀數(shù)據(jù)和檢測節(jié)點(diǎn)故障
Consul?利用?swim-gossip?協(xié)議變體進(jìn)行組成員資格、領(lǐng)導(dǎo)者選舉和 consul 代理的故障檢測
CockroachDB?使用 Gossip 協(xié)議來傳播節(jié)點(diǎn)元數(shù)據(jù)
Hyperledger Fabric?區(qū)塊鏈?zhǔn)褂?Gossip 協(xié)議進(jìn)行組成員資格和分類賬元數(shù)據(jù)傳輸
Riak?利用 Gossip 協(xié)議來傳輸一致性哈希環(huán)狀態(tài)和群集節(jié)點(diǎn)元數(shù)據(jù)
Amazon S3?使用 Gossip 協(xié)議在系統(tǒng)中傳播服務(wù)器狀態(tài)
Amazon Dynamo?使用 Gossip 協(xié)議進(jìn)行故障檢測和跟蹤節(jié)點(diǎn)成員資格
Redis?集群使用 Gossip 協(xié)議傳播節(jié)點(diǎn)元數(shù)據(jù)
比特幣使用 Gossip 協(xié)議在挖礦節(jié)點(diǎn)間傳播隨機(jī)數(shù)值
Gossip 協(xié)議的優(yōu)點(diǎn)
Gossip 協(xié)議的優(yōu)點(diǎn)包括以下幾點(diǎn)[8]，[2]，[7]，[4]，[5]：
可擴(kuò)展性
容錯(cuò)性
健壯性
最終一致性
去中心化
簡單性
集成和互操作性
有界負(fù)載
可擴(kuò)展性
可擴(kuò)展性是系統(tǒng)處理不斷增加的負(fù)載而無需降低性能的能力[2]。Gossip 協(xié)議的周期要求對數(shù)時(shí)間達(dá)到收斂。此外，每個(gè)節(jié)點(diǎn)僅與固定數(shù)量的節(jié)點(diǎn)進(jìn)行交互，并且獨(dú)立于系統(tǒng)中節(jié)點(diǎn)數(shù)量，只發(fā)送固定數(shù)量的消息。節(jié)點(diǎn)不需要等待確認(rèn)以提高延遲[8]，[4]，[5]。
容錯(cuò)性
容錯(cuò)性是系統(tǒng)在發(fā)生故障（如節(jié)點(diǎn)崩潰、網(wǎng)絡(luò)分區(qū)或消息丟失）時(shí)保持功能的能力。采用 Gossip 協(xié)議的分布式系統(tǒng)由于對不可靠網(wǎng)絡(luò)的容忍而具有容錯(cuò)性。Gossip 協(xié)議提供的冗余性、并行性和隨機(jī)性增強(qiáng)了系統(tǒng)的容錯(cuò)性[2]。
此外，節(jié)點(diǎn)參與 Gossip 協(xié)議的對稱和去中心化特性增強(qiáng)了 Gossip 協(xié)議的容錯(cuò)性[5]。通常會(huì)將相同的消息多次傳輸?shù)蕉鄠€(gè)節(jié)點(diǎn)。換句話說，源和目標(biāo)之間的消息流有許多路徑。因此，通過其他節(jié)點(diǎn)的消息傳輸可以克服節(jié)點(diǎn)故障[8]，[4]。
健壯性
節(jié)點(diǎn)參與 Gossip 協(xié)議的對稱特性提高了系統(tǒng)的健壯性[5]，[4]。節(jié)點(diǎn)故障不會(huì)破壞系統(tǒng)的質(zhì)量。然而， Gossip 協(xié)議對于臨時(shí)網(wǎng)絡(luò)分區(qū)并不具備健壯性。然而，除非數(shù)據(jù)經(jīng)過自驗(yàn)證，否則 Gossip 協(xié)議對于存在故障節(jié)點(diǎn)或惡意 Gossip 消息的情況并不具備健壯性[8]，[7]。
通過基于分?jǐn)?shù)的聲譽(yù)系統(tǒng)可以防止惡意節(jié)點(diǎn)損壞 Gossip 系統(tǒng)。必須實(shí)施適當(dāng)?shù)臋C(jī)制和策略（如加密、身份驗(yàn)證和授權(quán)），以確保 Gossip 系統(tǒng)的隱私和安全性[2]。
最終一致性
一致性是確保系統(tǒng)中的每個(gè)節(jié)點(diǎn)具有相同的狀態(tài)視圖的技術(shù)。不同的一致性級別（如強(qiáng)一致性、最終一致性、因果一致性和概率一致性）對系統(tǒng)的性能、可用性和正確性有不同的影響[2]。Gossip 協(xié)議通過數(shù)據(jù)的指數(shù)傳播在對數(shù)時(shí)間復(fù)雜度下收斂到一致狀態(tài)[8]，[5]。
去中心化
Gossip 協(xié)議通過點(diǎn)對點(diǎn)通信提供了一種極度去中心化的信息發(fā)現(xiàn)模型[8]，[4]，[5]。
簡單性
大多數(shù) Gossip 協(xié)議的變體都可以使用很少的代碼和低復(fù)雜性來實(shí)現(xiàn)[8]，[5]。節(jié)點(diǎn)的對稱性使得執(zhí)行Gossip協(xié)議變得非常簡單[7]。
集成和互操作性
Gossip 協(xié)議可以與數(shù)據(jù)庫、緩存和隊(duì)列等分布式系統(tǒng)組件進(jìn)行集成和互操作。必須定義通用接口、數(shù)據(jù)格式和協(xié)議，以在不同的分布式系統(tǒng)組件上實(shí)現(xiàn) Gossip 協(xié)議[2]。
有界負(fù)載
傳統(tǒng)的分布式系統(tǒng)協(xié)議通常會(huì)產(chǎn)生高峰負(fù)載，可能會(huì)使單個(gè)分布式系統(tǒng)組件超負(fù)荷。Gossip 協(xié)議只會(huì)對單個(gè)分布式系統(tǒng)組件產(chǎn)生嚴(yán)格有界的最壞負(fù)載，以避免服務(wù)質(zhì)量的中斷。Gossip 協(xié)議中的對等節(jié)點(diǎn)選擇可以調(diào)整以減少網(wǎng)絡(luò)鏈接的負(fù)載。在實(shí)踐中，Gossip 協(xié)議產(chǎn)生的負(fù)載不僅是有界的，而且與可用帶寬相比也是可忽略的[7]。
Gossip 協(xié)議的缺點(diǎn)
Gossip 協(xié)議的缺點(diǎn)包括以下幾點(diǎn)[1]，[5]，[8]，[2]，[7]：
最終一致性
不知道網(wǎng)絡(luò)分區(qū)
相對較高的帶寬消耗
增加的延遲
調(diào)試和測試?yán)щy
成員資格協(xié)議不可擴(kuò)展
容易出現(xiàn)計(jì)算錯(cuò)誤
最終一致性
Gossip 協(xié)議本質(zhì)上是最終一致性的[1]。與組播相比，Gossip 協(xié)議相對較慢。Gossip 消息存在開銷，并且 Gossip 行為取決于網(wǎng)絡(luò)拓?fù)浜凸?jié)點(diǎn)異構(gòu)性[2]。因此，群集對于識(shí)別新節(jié)點(diǎn)或節(jié)點(diǎn)故障可能會(huì)有一些延遲[12]。
不知道網(wǎng)絡(luò)分區(qū)
當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)時(shí)，子分區(qū)中的節(jié)點(diǎn)仍會(huì)相互傳播 Gossip 。因此，Gossip 協(xié)議對于網(wǎng)絡(luò)分區(qū)沒有意識(shí)，可能會(huì)嚴(yán)重延遲消息傳播[1]，[7]。
帶寬
Gossip 協(xié)議并不以效率著稱，因?yàn)橄嗤南⒖赡軙?huì)被多次重傳給同一個(gè)節(jié)點(diǎn)，從而消耗不必要的帶寬[5]，[8]。盡管由于有界消息大小和周期性消息交換，Gossip 協(xié)議的帶寬使用是有限的，但當(dāng)節(jié)點(diǎn)應(yīng)該傳播的信息量超過有界消息大小時(shí)，通過 Gossip 交換實(shí)際上有效的 fanout 可能會(huì)降低[7]。
Gossip 協(xié)議的飽和點(diǎn)取決于不同的參數(shù)，例如消息生成速率、消息大小、 fanout 和 Gossip 協(xié)議類型[7]，[8]。
延遲
使用 Gossip 協(xié)議會(huì)導(dǎo)致增加的延遲，因?yàn)楣?jié)點(diǎn)必須等待下一個(gè) Gossip 周期（間隔）才能傳輸消息[5]。消息并不會(huì)觸發(fā) Gossip 交換，而是由 Gossip 協(xié)議的間隔計(jì)時(shí)器觸發(fā)。在系統(tǒng)中傳播消息所需的時(shí)間復(fù)雜度是對數(shù)級別的[8]，[4]。
調(diào)試和測試
調(diào)試是識(shí)別并修復(fù)導(dǎo)致 Gossip 協(xié)議偏離預(yù)期行為的故障的過程。測試是驗(yàn)證 Gossip 協(xié)議是否滿足性能、可靠性和安全性等功能和非功能要求的能力[2]。
Gossip 協(xié)議的固有非確定性和分布式特性使得調(diào)試和重現(xiàn)故障變得困難[8]，[5]，[2]?？梢允褂媚M、仿真、日志記錄、跟蹤、監(jiān)視和可視化等工具和技術(shù)來測試和調(diào)試 Gossip 系統(tǒng)[2]。
可擴(kuò)展性
大多數(shù) Gossip 協(xié)議的變體依賴于不可擴(kuò)展的成員資格協(xié)議[5]。
計(jì)算錯(cuò)誤
Gossip 協(xié)議易于受到惡意節(jié)點(diǎn)的計(jì)算錯(cuò)誤影響。節(jié)點(diǎn)應(yīng)該實(shí)現(xiàn)自校正機(jī)制，因?yàn)?Gossip 協(xié)議的健壯性僅限于某些類別的故障[7]。盡管如此，Gossip 協(xié)議非?？煽?，概率為1的結(jié)果是典型的[8]。
總結(jié)
在分布式系統(tǒng)中進(jìn)行 Gossip 是一種福音，而在現(xiàn)實(shí)世界中進(jìn)行閑言碎語則是一種詛咒。Gossip 協(xié)議被用于 Amazon Dynamo 和分布式計(jì)數(shù)器等分布式系統(tǒng)中。
進(jìn)一步的系統(tǒng)設(shè)計(jì)學(xué)習(xí)資源
訂閱系統(tǒng)設(shè)計(jì)通訊，再也不會(huì)錯(cuò)過新的博客文章。您還將在訂閱時(shí)收到關(guān)于如何應(yīng)對系統(tǒng)設(shè)計(jì)面試的終極指南。
參考
[1]: Prateek Gupta, Gossip Protocol in distributed systems (2022), medium.com
[2]: How do you integrate a gossip system with other distributed components and services?, Distributed Systems (LinkedIn.com)
[3]: Martin Kleppmann, Distributed Systems 4.3: Broadcast algorithms (2021), YouTube.com
[4]: Bhumika Dutta, A Gentle Introduction to Gossip Protocol (2022), analyticssteps.com
[5]: Gabriel Acuna, Parallel & Distributed Computing?—?Gossip Protocol (2020), YouTube.com
[6]: Architecture Gossip, Cassandra
[7]: Ken Birman, The Promise, and Limitations, of Gossip Protocols (2007), cornell.edu
[8]: Felix Lopez, Introduction to Gossip (2016), managementfromscratch.wordpress.com
[9]: Kumar Chandrakant, Fundamentals of Distributed Systems (2023), baeldung.com
[10]: Alan Demers et al., Epidemic Algorithms for Replicated Database Maintainance (1987), berkeley.edu
[11]: Todd Hoff, Using Gossip Protocols For Failure Detection, Monitoring, Messaging And Other Good Things (2011), highscalability.com
[12]: Unmesh Joshi, Gossip Dissemination (2021), martinfowler.com
