分布式系統(tǒng)原理

Lease機制

Lease 機制是最重要的分布式協(xié)議，廣泛應(yīng)用于各種實際的分布式系統(tǒng)中。即使在某些系統(tǒng)中相似的設(shè)計不被稱為 lease，但我們可以分析發(fā)現(xiàn)其本質(zhì)就是一種 lease 的實現(xiàn)。

本節(jié)從一個分布式cache 系統(tǒng)出發(fā)介紹最初的 lease 機制，接著加以引申，探討 lease 機制的本質(zhì)。最后介紹了 lease 機制最重要的應(yīng)用：判定節(jié)點狀態(tài)。

1. 基于 lease 的分布式 cache 系統(tǒng)

本節(jié)先通過討論一種分布式 cache 系統(tǒng)的實例來介紹 lease 機制。Lease 機制最初也是被運用于這種系統(tǒng)。

基本的問題背景如下：在一個分布式系統(tǒng)中，有一個中心服務(wù)器節(jié)點，中心服務(wù)器存儲、維護(hù)著一些數(shù)據(jù)，這些數(shù)據(jù)是系統(tǒng)的元數(shù)據(jù)。系統(tǒng)中其他的節(jié)點通過訪問中心服務(wù)器節(jié)點讀取、修改其上的元數(shù)據(jù)。由于系統(tǒng)中各種操作都依賴于元數(shù)據(jù)，如果每次讀取元數(shù)據(jù)的操作都訪問中心服務(wù)器節(jié)點，那么中心服務(wù)器節(jié)點的性能成為系統(tǒng)的瓶頸。為此，設(shè)計一種元數(shù)據(jù) cache，在各個節(jié)點上cache 元數(shù)據(jù)信息，從而減少對中心服務(wù)器節(jié)點的訪問，提高性能。另一方面，系統(tǒng)的正確運行嚴(yán)格依賴于元數(shù)據(jù)的正確，這就要求各個節(jié)點上 cache 的數(shù)據(jù)始終與中心服務(wù)器上的數(shù)據(jù)一致，cache中的數(shù)據(jù)不能是舊的臟數(shù)據(jù)。最后，設(shè)計的 cache 系統(tǒng)要能最大可能的處理節(jié)點宕機、網(wǎng)絡(luò)中斷等異常，最大程度的提高系統(tǒng)的可用性。

為此，利用 lease 機制設(shè)計一套 cache 系統(tǒng)，其基本原理為如下。中心服務(wù)器在向各節(jié)點發(fā)送數(shù)據(jù)時同時向節(jié)點頒發(fā)一個 lease。每個 lease 具有一個有效期，和信用卡上的有效期類似，lease 上的有效期通常是一個明確的時間點，例如 12:00:10，一旦真實時間超過這個時間點，則 lease 過期失效。這樣 lease 的有效期與節(jié)點收到 lease 的時間無關(guān)，節(jié)點可能收到 lease 時該 lease 就已經(jīng)過期失效。這里首先假設(shè)中心服務(wù)器與各節(jié)點的時鐘是同步的，下節(jié)中討論時鐘不同步對 lease 的影響。中心服務(wù)器發(fā)出的 lease 的含義為：在 lease 的有效期內(nèi)，中心服務(wù)器保證不會修改對應(yīng)數(shù)據(jù)的值。因此，節(jié)點收到數(shù)據(jù)和 lease 后，將數(shù)據(jù)加入本地 Cache，一旦對應(yīng)的 lease 超時，節(jié)點將對應(yīng)的本地 cache數(shù)據(jù)刪除。中心服務(wù)器在修改數(shù)據(jù)時，首先阻塞所有新的讀請求，并等待之前為該數(shù)據(jù)發(fā)出的所有l(wèi)ease 超時過期，然后修改數(shù)據(jù)的值。

具體的服務(wù)器與客戶端節(jié)點一個基本流程如下：

流程 2.3.1：基于 lease 的 cache，客戶端節(jié)點讀取元數(shù)據(jù)： 1. 判斷元數(shù)據(jù)是否已經(jīng)處于本地 cache 且 lease 處于有效期內(nèi) 1.1 是：直接返回 cache 中的元數(shù)據(jù) 1.2 否：向中心服務(wù)器節(jié)點請求讀取元數(shù)據(jù)信息1.2.1 服務(wù)器收到讀取請求后，返回元數(shù)據(jù)及一個對應(yīng)的 lease1.2.2 客戶端是否成功收到服務(wù)器返回的數(shù)據(jù)1.2.2.1 失敗或超時：退出流程，讀取失敗，可重試1.2.2.2 成功：將元數(shù)據(jù)與該元數(shù)據(jù)的 lease 記錄到內(nèi)存中，返回元數(shù)據(jù) 流程 2.3.2：基于 lease 的 cache，客戶端節(jié)點修改元數(shù)據(jù)流程 1. 節(jié)點向服務(wù)器發(fā)起修改元數(shù)據(jù)請求。 2. 服務(wù)器收到修改請求后，阻塞所有新的讀數(shù)據(jù)請求，即接收讀請求，但不返回數(shù)據(jù)。 3. 服務(wù)器等待所有與該元數(shù)據(jù)相關(guān)的 lease 超時。 4. 服務(wù)器修改元數(shù)據(jù)并向客戶端節(jié)點返回修改成功

• 上述機制可以保證各個節(jié)點上的 cache 與中心服務(wù)器上的中心始終一致。這是因為中心服務(wù)器節(jié)點在發(fā)送數(shù)據(jù)的同時授予了節(jié)點對應(yīng)的 lease，在 lease 有效期內(nèi)，服務(wù)器不會修改數(shù)據(jù)，從而客戶端節(jié)點可以放心的在 lease 有效期內(nèi) cache 數(shù)據(jù)。

• 述基礎(chǔ)流程有一些性能和可用性上的問題，但可以很容易就優(yōu)化改性。優(yōu)化點一：服務(wù)器在修改元數(shù)據(jù)時首先要阻塞所有新的讀請求，造成沒有讀服務(wù)。進(jìn)一步的優(yōu)化是，當(dāng)進(jìn)入修改流程，服務(wù)器頒發(fā)的lease 有效期限選擇為已發(fā)出的 lease 的最大有效期限。實際使用中，第一層優(yōu)化就足夠了。優(yōu)化點二：服務(wù)器在修改元數(shù)據(jù)時需要等待所有的 lease 過期超時，從而造成修改元數(shù)據(jù)的操作時延大大增大。優(yōu)化的方法是，在等待所有的 lease 過期的過程中，服務(wù)器主動通知各個持有l(wèi)ease的節(jié)點放棄lease并清除cache中的數(shù)據(jù)，如果服務(wù)器收到客戶端返回的確認(rèn)放棄lease的消息，則服務(wù)器不需要在等待該 lease 超時。

2. lease 機制的分析

首先給出本文對 lease 的定義：Lease 是由頒發(fā)者授予的在某一有效期內(nèi)的承諾。

• 頒發(fā)者一旦發(fā)出 lease，則無論接受方是否收到，也無論后續(xù)接收方處于何種狀態(tài)，只要 lease 不過期，頒發(fā)者一定嚴(yán)守承諾；另一方面，接收方在 lease的有效期內(nèi)可以使用頒發(fā)者的承諾，但一旦 lease 過期，接收方一定不能繼續(xù)使用頒發(fā)者的承諾。

• Lease 機制具有很高的容錯能力。首先，通過引入有效期，Lease 機制能否非常好的容錯網(wǎng)絡(luò)異常。再者，Lease 機制能較好的容錯節(jié)點宕機。最后，lease 機制不依賴于存儲。

• Lease 機制依賴于有效期，這就要求頒發(fā)者和接收者的時鐘是同步的。對于這種時鐘不同步，實踐中的通常做法是將頒發(fā)者的有效期設(shè)置得比接收者的略大，只需大過時鐘誤差就可以避免對 lease 的有效性的影響。

3. 基于 lease 機制確定節(jié)點狀態(tài)

在分布式系統(tǒng)中確定一個節(jié)點是否處于正常工作狀態(tài)是一個困難的問題。由于可能存在網(wǎng)絡(luò)分化，節(jié)點的狀態(tài)是無法通過網(wǎng)絡(luò)通信來確定的。下面舉一個較為具體的例子來討論這個問題。

例 2.3.1：在一個 primary-secondary 架構(gòu)的系統(tǒng)中，有三個節(jié)點 A、B、C 互為副本，其中有一
個節(jié)點為 primary，且同一時刻只能有一個 primary 節(jié)點。另有一個節(jié)點 Q 負(fù)責(zé)判斷節(jié)點 A、B、C
的狀態(tài)，一旦 Q 發(fā)現(xiàn) primary 異常，節(jié)點 Q 將選擇另一個節(jié)點作為 primary。假設(shè)最開始時節(jié)點 A
為 primary，B、C 為 secondary。節(jié)點 Q 需要判斷節(jié)點 A、B、C 的狀態(tài)是否正常。

首先需要說明的是基于“心跳”(Heartbeat)的方法無法很好的解決這個問題。節(jié)點 A、B、C 可以周期性的向 Q 發(fā)送心跳信息，如果節(jié)點 Q 超過一段時間收不到某個節(jié)點的心跳則認(rèn)為這個節(jié)點異常。

上述問題的出現(xiàn)的原因在于雖然節(jié)點 Q 認(rèn)為節(jié)點 A 異常，但節(jié)點 A 自己不認(rèn)為自己異常，依舊作為 primary 工作。其問題的本質(zhì)是由于網(wǎng)絡(luò)分化造成的系統(tǒng)對于“節(jié)點狀態(tài)”認(rèn)知的不一致。

上面的例子中的分布式協(xié)議依賴于對節(jié)點狀態(tài)認(rèn)知的全局一致性，即一旦節(jié)點 Q 認(rèn)為某個節(jié)點A 異常，則節(jié)點 A 也必須認(rèn)為自己異常，從而節(jié)點 A 停止作為 primary，避免“雙主”問題的出現(xiàn)。解決這種問題有兩種思路，第一、設(shè)計的分布式協(xié)議可以容忍“雙主”錯誤，即不依賴于對節(jié)點狀態(tài)的全局一致性認(rèn)識，或者全局一致性狀態(tài)是全體協(xié)商后的結(jié)果；第二、利用 lease 機制。

由中心節(jié)點向其他節(jié)點發(fā)送 lease，若某個節(jié)點持有有效的 lease，則認(rèn)為該節(jié)點正常可以提供服務(wù)。用于例 2.3.1 中，節(jié)點 A、B、C 依然周期性的發(fā)送 heart beat 報告自身狀態(tài)，節(jié)點 Q 收到 heart beat后發(fā)送一個 lease，表示節(jié)點 Q 確認(rèn)了節(jié)點 A、B、C 的狀態(tài)，并允許節(jié)點在 lease 有效期內(nèi)正常工作。節(jié)點 Q 可以給 primary 節(jié)點一個特殊的 lease，表示節(jié)點可以作為 primary 工作。一旦節(jié)點 Q 希望切換新的 primary，則只需等前一個 primary 的 lease 過期，則就可以安全的頒發(fā)新的 lease 給新的primary 節(jié)點，而不會出現(xiàn)“雙主”問題。

4. lease 的有效期時間選擇

Lease 的有效期雖然是一個確定的時間點，當(dāng)頒發(fā)者在發(fā)布 lease 時通常都是 將當(dāng)前時間加上一個固定的時長從而計算出 lease 的有效期。

如何選擇 Lease 的時長在工程實踐中是一個值得討論的問題。如果 lease 的時長太短，例如 1s，一旦出現(xiàn)網(wǎng)絡(luò)抖動 lease 很容易丟失，從而造成節(jié)點失去 lease，使得依賴 lease 的服務(wù)停止；如果 lease 的時長太大，例如 1 分鐘，則一旦接受者異常，頒發(fā)者需要過長的時間收回 lease 承諾。例如，使用 lease 確定節(jié)點狀態(tài)時，若 lease 時間過短，有可能造成網(wǎng)絡(luò)瞬斷時節(jié)點收不到 lease 從而引起服務(wù)不穩(wěn)定，若 lease 時間過長，則一旦某節(jié)點宕機異常，需要較大的時間等待 lease 過期才能發(fā)現(xiàn)節(jié)點異常。

工程中，常選擇的 lease 時長是 10 秒級別，這是一個經(jīng)過驗證的經(jīng)驗值，實踐中可以作為參考并綜合選擇合適的時長。

5. 工程投影

• GFS 中的 Lease。GFS 中使用 Lease 確定 Chuck 的 Primary 副本。Lease 由 Master 節(jié)點頒發(fā)給 primary 副本，持有Lease 的副本成為 primary 副本。

• Niobe 中的 Lease。Niobe 中雖然沒有明確說明使用了 Lease 機制，但是通過分析可以發(fā)現(xiàn)，這是一個 Lease 機制。Niobe 協(xié)議中，也是通過 Lease 機制維持 Primary 副本的選擇，不同的是 Niobe 中的 Lease 是由 Secondary 節(jié)點向 Primary 節(jié)點發(fā)送。在 Niobe 協(xié)議中，每個 Secondary 副本都會給 Primary 副本發(fā)送 Lease，這個 Lease 的含義是： 在 Lease 時間內(nèi)，本副本承認(rèn)你是 Primary 節(jié)點。從這里我們可以看到，niobe 中的 lease 含義也可以理解為：“我承諾在接下來 lease 時間內(nèi)，我不會 kill 你”。

• Chubby 與 Zookeeper 中的 Lease。我們知道 chubby 通過 paxos 協(xié)議實現(xiàn)去中心化的選擇 primary 節(jié)點（見 2.8.6 ）。一旦某個節(jié)點獲得了超過半數(shù)的節(jié)點認(rèn)可，該節(jié)點成為 primary 節(jié)點，其余節(jié)點成為 secondary 節(jié)點。Secondary節(jié)點向 primary節(jié)點發(fā)送 lease，該 lease 的含義是： “承諾在 lease 時間內(nèi)，不選舉其他節(jié)點成為 primary節(jié)點”。除了 secondary 與 primary 之間的 lease，在 chubby 中，primary 節(jié)點也會向每個 client 節(jié)點頒發(fā)lease。該 lease 的含義是用來判斷 client 的死活狀態(tài)，一個 client 節(jié)點只有只有合法的 lease，才能與 chubby 中的 primary 進(jìn)行讀寫操作。與 Chubby 不同，Zookeeper 中的 secondary 節(jié)點（在 zookeeper 中稱之為 follower）并不向 primary節(jié)點（在 zookeeper 中稱之為 leader）發(fā)送 lease，zookeeper 中的 secondary 節(jié)點如果發(fā)現(xiàn)沒有 primary節(jié)點則發(fā)起新的 paxos 選舉，只要 primary 與 secondary 工作正常，新發(fā)起的選舉由于缺乏多數(shù)secondary的參與而不會成功。

• 間接使用 Lease。筆者很難想象，如何在工程上既不使用 Lease 而又實現(xiàn)一個一致性較高的系統(tǒng)。直接實現(xiàn) lease機制的確會對增加系統(tǒng)設(shè)計的復(fù)雜度。然而，由于有類似 Zookeeper 這樣的開源的高可用系統(tǒng)，在工程中完全可以間接使用 Lease。借助 zookeeper，我們可以簡單的實現(xiàn)高效的、無單點選主、狀態(tài)監(jiān)控、分布式鎖、分布式消息隊列等功能，而實際上，這些功能的實現(xiàn)都是依賴于背后 zookeeper與 client 之間的 Lease 的。

參考：《分布式系統(tǒng)原理介紹》 - 劉杰

總結(jié)

以上是生活随笔為你收集整理的分布式系统原理 之3 Lease机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。