尋找 Leader

串行化和線性化

當(dāng) follower 服務(wù)器處理讀取請(qǐng)求時(shí),由于 leader 的最新提交尚未到達(dá)跟隨者,客戶端可能會(huì)獲得陳舊數(shù)據(jù)�？蛻舳私邮崭�新的順序仍保持不變,但是更新可能不是最新的。與線性化相對(duì),這是串行化保證。線性化可確保每個(gè)客戶端都獲得最新更新�？蛻舳藘H需要讀取元數(shù)據(jù)并且可以暫時(shí)容納過(guò)時(shí)的元數(shù)據(jù)時(shí),便可以使用串行化保證。對(duì)于諸如 Lease 之類的操作,需要嚴(yán)格線性化。

如果將 leader 從集群中分割出去,則客戶端可以從 leader 獲得陳舊的值,Raft描述了一種提供線性化讀取的機(jī)制。參見(jiàn)例子etcd 的readIndex實(shí)現(xiàn)。

分割的 follower 可能會(huì)發(fā)生類似的情況。follower 可能已分割,可能未將最新值返回給客戶端。為確保 follower 未分割且與 leader 保持最新,他們需要查詢 leader 以了解最新更新,并等到收到最新更新后再對(duì)客戶端進(jìn)行響應(yīng),請(qǐng)參閱proposed kafka design例子。

所有操作都必須在 leader 上執(zhí)行,這很重要,因此客戶端庫(kù)需要首先找到leader 服務(wù)器。有兩種方法可以滿足此要求。

consistent core中的follower服務(wù)器知道當(dāng)前的 leader,因此,如果客戶端連接到 follower,則它可以返回leader 的地址。然后,客戶端可以直接連接在響應(yīng)中標(biāo)識(shí)的 leader。應(yīng)當(dāng)注意,當(dāng)客戶端嘗試連接時(shí),服務(wù)器可能處于leader選舉狀態(tài)。在這種情況下,服務(wù)器無(wú)法返回leader地址,客戶端需要等待并嘗試另一臺(tái)服務(wù)器。

服務(wù)器可以實(shí)現(xiàn)轉(zhuǎn)發(fā)機(jī)制,并將所有客戶端請(qǐng)求轉(zhuǎn)發(fā)給 leader。這允許客戶端連接到任何服務(wù)器。同樣,如果服務(wù)器處于leader 選舉中,則客戶端需要重試,直到leader選舉成功并建立了合法的 leader 為止。

Zookeeper 和 etcd 之類的產(chǎn)品之所以采用這種方法,是因?yàn)樗鼈冊(cè)试Sfollower 服務(wù)器處理一些只讀請(qǐng)求。當(dāng)大量客戶端是只讀客戶端時(shí),這避免了leader 的瓶頸。這樣可以讓客戶端根據(jù)請(qǐng)求類型減少連接到leader 或follower 的復(fù)雜性。

找到leader的一種簡(jiǎn)單機(jī)制是嘗試連接到每個(gè)服務(wù)器并嘗試發(fā)送請(qǐng)求,如果服務(wù)器不是leader,則服務(wù)器會(huì)重定向響應(yīng)。

private void establishConnectionToLeader(List

僅建立TCP連接是不夠的,我們需要知道服務(wù)器是否可以處理我們的請(qǐng)求。因此,客戶端向服務(wù)器發(fā)送一個(gè)特殊的連接請(qǐng)求,以確認(rèn)服務(wù)器是否可以處理請(qǐng)求或重定向到 leader 服務(wù)器。

private RequestOrResponse sendConnectRequest(SingleSocketChannel socketChannel) throws IOException {
   RequestOrResponse request
           = new RequestOrResponse(RequestId．ConnectRequest．getId(), "CONNECT", 0);
   try {
       return socketChannel．blockingSend(request);
   } catch (IOException e) {
       resetConnectionToLeader();
       throw e;
   }
}

如果現(xiàn)有的leader失敗,同樣的技術(shù)被用來(lái)從集群中識(shí)別新當(dāng)選的 leader。

連接后,客戶端將維護(hù)到leader 服務(wù)器的Single Socket Channel。

處理重復(fù)請(qǐng)求

在失敗的情況下,客戶端可以嘗試連接到新的leader,重新發(fā)送請(qǐng)求。但是,如果那些請(qǐng)求在失敗之前已經(jīng)由失敗的leader 處理過(guò),則可能會(huì)導(dǎo)致重復(fù)。因此,在服務(wù)器上具有一種機(jī)制可以忽略重復(fù)的請(qǐng)求,這一點(diǎn)很重要。Idempotent Receiver 模式用于實(shí)現(xiàn)重復(fù)檢測(cè)。

使用 Lease 可以完成一組服務(wù)器之間的協(xié)調(diào)任務(wù)�？梢允褂孟嗤�的方法來(lái)實(shí)現(xiàn)組成員身份和故障檢測(cè)機(jī)制。

State Watch 用于獲取有關(guān)元數(shù)據(jù)或時(shí)間限制租約更改的通知。

例子

眾所周知,谷歌使用[chubby]鎖服務(wù)進(jìn)行協(xié)調(diào)和元數(shù)據(jù)管理。

[kafka]使用[zookeeper]來(lái)管理元數(shù)據(jù),并為集群主服務(wù)器做出決策,例如選擇 leader。kafka 提議的體系結(jié)構(gòu)更改將用其自己的基于[raft]的控制器集群代替Zookeeper。

[bookkeeper]使用 Zookeeper 管理集群元數(shù)據(jù)。

[kubernetes]使用[etcd]進(jìn)行協(xié)調(diào),管理集群元數(shù)據(jù)和組成員信息。

[hdfs],[spark],[flink]等所有大數(shù)據(jù)存儲(chǔ)和處理系統(tǒng)都使用[zookeeper]來(lái)實(shí)現(xiàn)高可用性和集群協(xié)調(diào)。

說(shuō)明

注1:因?yàn)檎麄�(gè)集群都依賴于 Consistent Core,所以了解所使用的一致性算法的細(xì)節(jié)至關(guān)重要。在某些棘手的網(wǎng)絡(luò)分區(qū)情況下,一致性實(shí)現(xiàn)可能會(huì)遇到活躍性問(wèn)題。例如,除非特別注意,否則Raft集群可能會(huì)被分割的服務(wù)器破壞,分割的服務(wù)器會(huì)不斷觸發(fā)leader選舉。最近在 Cloudflare 發(fā)生的事件是一個(gè)值得學(xué)習(xí)的好例子。