本文主要對Consul中的幾個(gè)概念進(jìn)行了歸納和梳理，為方便后續(xù)使用。

1. RPC（遠(yuǎn)程過程調(diào)用）

RPC是「服務(wù)器A」調(diào)用在「服務(wù)器B」上的服務(wù)這么一個(gè)操作。

2. Datacenter（數(shù)據(jù)中心）

Datacenter是一個(gè)私有、低延遲和高帶寬的網(wǎng)絡(luò)環(huán)境。

下文簡稱DC。

3. Agent（代理）

Agent是一直運(yùn)行在節(jié)點(diǎn)上的守護(hù)進(jìn)程。

3.1 Type（類型）：

Agent按照類型區(qū)分，可劃分為Server和Client。

3.1.1 Server（服務(wù)端）：

• 功能：負(fù)責(zé)領(lǐng)袖選舉（見7），維護(hù)集群狀態(tài)，響應(yīng)RPC查詢，與其他DC交互WAN gossip轉(zhuǎn)發(fā)查詢給Leader節(jié)點(diǎn)或者遠(yuǎn)程DC等。
• 數(shù)目：每個(gè)DC中至少有一個(gè)Server。
• 注意：Server不直接接收RPC請求。

3.1.2 Client（客戶端）：

• 功能：負(fù)責(zé)注冊服務(wù)，運(yùn)行健康檢查，轉(zhuǎn)發(fā)RPC請求到Server。
• 數(shù)目：每個(gè)DC中建議有3-5個(gè)Client。

Client是相對無狀態(tài)的，Client唯一執(zhí)行的后臺活動(dòng)是加入LAN gossip池。這里有一個(gè)最低的資源開銷，并且消耗少量的網(wǎng)絡(luò)帶寬。

4. Node (節(jié)點(diǎn))

Node是DC中的一個(gè)成員（服務(wù)器）。

每個(gè)Node都必須運(yùn)行Agent，可以粗略地將Node和Agent劃等號。

4.1 Identity（身份）：

正常情況下節(jié)點(diǎn)按身份分，可劃分為Leader和Follower；
但當(dāng)Leader掛掉以后，consul會啟動(dòng)選舉機(jī)制，產(chǎn)生一個(gè)新的Leader，此時(shí)走完一個(gè)監(jiān)聽流程的節(jié)點(diǎn)成為Candidate，并為自己拉票。

工作流程：首先選舉出第一任Leader，全權(quán)負(fù)責(zé)管理日志復(fù)制。Leader從客戶端接收log entries，將它們復(fù)制給同一DC中的其他Follower，然后告訴Follower什么時(shí)候?qū)⑷罩緫?yīng)用于它們的狀態(tài)機(jī)。

• Leader可以不過問Follower的情況下，決定把新entries放在哪個(gè)位置。
• 數(shù)據(jù)永遠(yuǎn)是從Leader流向Follower。
• Leader可以Fail或者與其他機(jī)器失去連接，這種情形下會有新的Leader被選舉出來。

4.1.1 Leader（領(lǐng)袖）：

• 功能：Leader節(jié)點(diǎn)會將數(shù)據(jù)同步到Follower節(jié)點(diǎn)；
• 限制：一個(gè)DC中有且只有一個(gè)Leader
• 補(bǔ)充：Consul默認(rèn)只有領(lǐng)袖對請求進(jìn)行響應(yīng)，所有對追隨者的請求將被轉(zhuǎn)發(fā)給領(lǐng)袖。在有大量請求的大型集群中,這顯得不夠有擴(kuò)展性（可以通過max_stale修改）。

4.1.2 Follower（跟隨者）：

默認(rèn)情況下Follower不會主動(dòng)發(fā)起RPC消息。

4.1.3 Candidate（候選者）：

等待推舉為Leader的狀態(tài)。

4.2 Status（狀態(tài)）：

Node的狀態(tài)有兩種，分別是Healthy和Unhealthy。

4.2.1 Healthy（健康）：

可用

4.2.2 Unhealthy（非健康）：

不可用

5. Consensus（一致性）

Consensus就是邏輯上對于被選舉出的leader以及事物的順序的認(rèn)同

6. Gossip

Gossip協(xié)議是讓所有的通信節(jié)點(diǎn)最終達(dá)成一致的協(xié)議。

6.1 概念：

Gossip算法又被稱為反熵（Anti-Entropy），熵是物理學(xué)上的一個(gè)概念，代表雜亂無章，而反熵就是在雜亂無章中尋求一致。

在一個(gè)有界網(wǎng)絡(luò)中，每個(gè)節(jié)點(diǎn)都隨機(jī)地與其他節(jié)點(diǎn)通信，經(jīng)過一番雜亂無章的通信，最終所有節(jié)點(diǎn)的狀態(tài)都會達(dá)成一致。要注意到的一點(diǎn)是，即使有的節(jié)點(diǎn)因宕機(jī)而重啟，有新節(jié)點(diǎn)加入，但經(jīng)過一段時(shí)間后，這些節(jié)點(diǎn)的狀態(tài)也會與其他節(jié)點(diǎn)達(dá)成一致，也就是說，Gossip天然具有分布式容錯(cuò)的優(yōu)點(diǎn)。

Gossip是一個(gè)帶冗余的容錯(cuò)算法，更進(jìn)一步，Gossip是一個(gè)最終一致性算法。

6.2 特性：

• Gossip使用基于UDP的隨機(jī)的點(diǎn)到點(diǎn)通信。

• Consul建立在Serf的基礎(chǔ)之上，它提供了一個(gè)用于多播目的的完整的gossip協(xié)議。Serf提供成員關(guān)系，故障檢測和事件廣播。

• 同一個(gè)DC的所有節(jié)點(diǎn)都必須加入gossip協(xié)議。這意味著Gossip協(xié)議包含一個(gè)給定數(shù)據(jù)中心的所有節(jié)點(diǎn)。這服務(wù)于幾個(gè)目的：

  a. 不需要在client上配置server地址。發(fā)現(xiàn)都是自動(dòng)完成的。
  b. 檢測節(jié)點(diǎn)故障的工作不是放在server上，而是分布式的。這使得故障檢測相比心跳機(jī)制有更高的可擴(kuò)展性。
  c. 它用來作為一個(gè)消息層來通知事件，比如leader選舉發(fā)生時(shí)。

6.3 實(shí)現(xiàn)

Consul使用兩個(gè)不同的gossip池。我們分別稱為WAN池和LAN池。

6.3.1 WAN gossip

• 目的：WAN池提供的成員關(guān)系允許Server執(zhí)行跨數(shù)據(jù)中心請求。集成的故障檢測允許Consul優(yōu)雅的處理整個(gè)數(shù)據(jù)中心失聯(lián)。
• 數(shù)目：全局唯一。
• 包含：WAN池包含且只包含整個(gè)Consul集群內(nèi)的所有Server節(jié)點(diǎn)。

6.3.2 LAN gossip

• 目的：成員關(guān)系使得Client自動(dòng)發(fā)現(xiàn)Server，減少配置量；分布式的故障檢測允許故障檢測的工作由整個(gè)集群承擔(dān)，而不是集中在少數(shù)Server上；gossip池允許可靠和快速的事件廣播，比如Leader選舉。
• 數(shù)目：每個(gè)DC都有一個(gè)LAN gossip池。
• 包含：LAN池包含它所在DC內(nèi)的所有Client和Server。

7. Raft

一句話：Raft是一種算法，能實(shí)現(xiàn)分布式的意見一致性，參考《一則動(dòng)畫了解Raft》。

Consul使用Raft算法來保證一致性。
Consul中只有以Server模式運(yùn)行的節(jié)點(diǎn)，才會被認(rèn)為是Raft節(jié)點(diǎn)集的一部分。
下文僅做簡略介紹，屆時(shí)另開一文詳細(xì)解釋Raft算法。

1. 所有的成員內(nèi)部有一個(gè)計(jì)時(shí)器，如果在計(jì)時(shí)器歸零前沒有收到來自Leader的通訊，則會認(rèn)為Leader已經(jīng)掛了，他會自薦為Leader，并向同網(wǎng)絡(luò)內(nèi)其他成員拉票，獲得高票者成為新的Leader，其他所有低票或無票的成為Follower。
2. Leader會周期性的向Follower通訊，將最新的情報(bào)發(fā)送給它們，F(xiàn)ollower也會響應(yīng)本次請求（類似心跳監(jiān)測）。
3. 如果Leader有數(shù)據(jù)修改，Leader會先將修改日志（log entry）寫在本地，然后將這次操作寫入通訊，發(fā)送給Follower；Follower將修改日志同步到本機(jī)，并回應(yīng)Leader。收到響應(yīng)的Leader完成最終提交，否則回滾。

7.1 兩種身份：

1. Leader（領(lǐng)袖）
2. Follower（跟隨者）

7.2 三個(gè)階段：

1. Leader Election（領(lǐng)袖選舉）
2. Log Replication（日志拷貝）
3. Commit(提交修改)

7.3 三種一致性模式：

7.3.1 Default（基于Leader約期）

• 概括：犧牲強(qiáng)一致性，保障了讀的效率。
• 解析：Raft算法默認(rèn)使用了Leader約期的概念：在一個(gè)時(shí)間窗口中，Leader認(rèn)為自己的角色是穩(wěn)定的。
• 極端情況：如果Leader節(jié)點(diǎn)與別的節(jié)點(diǎn)被分隔（參考動(dòng)畫中Log Replication中add partition環(huán)節(jié)），即發(fā)生所謂“腦裂”現(xiàn)象，那么會有一個(gè)新的Leader節(jié)點(diǎn)被選舉出來（此時(shí)同一個(gè)網(wǎng)絡(luò)中存在兩個(gè)Leader）。此時(shí)原Leader節(jié)點(diǎn)將不能提交任何新的log entry（因?yàn)樗鼰o法獲得絕大多數(shù)成員的響應(yīng)）；如果它提供了對數(shù)據(jù)的讀取，那么Client讀可能讀到過期值。

思考：動(dòng)畫例子中提供的是「1臺Leader+1臺Follower」和「1臺Leader+2臺Follower」的例子，集群會默認(rèn)接收2臺Follower的為有效Leader。如果是同等數(shù)量的兩個(gè)部分，會是怎樣？

7.3.2 Consistent（一致性）

• 概括： 犧牲讀的速度，保障了強(qiáng)一致性。
• 解釋：這種模式是強(qiáng)一致性模式。這種模式要求Leader節(jié)點(diǎn)，每次做讀和寫操作時(shí)都要與法定個(gè)數(shù)的節(jié)點(diǎn)去確認(rèn)自己仍然是Leader。

7.3.3 Stale（臟讀）

• 概括： 犧牲一致性，保證了最高速的讀效率。
• 解析：這種模式允許任何Consul Server向外部提供讀取操作，無論它是不是Leader節(jié)點(diǎn)。 這種模式特別快，但是讀到過期數(shù)據(jù)的可能性非常大。這種模式允許在沒有Leader節(jié)點(diǎn)的情況下對讀請求做出相應(yīng)，盡管實(shí)際上這時(shí)候Raft集群已經(jīng)是處于不可用狀態(tài)了。

參考資料

1. Consul官方網(wǎng)址
2. Gossip協(xié)議
3. 《Consul實(shí)現(xiàn)原理系列文章1:用Raft來實(shí)現(xiàn)分布式一致性》
4. 《分布式一致性之Raft算法》