分佈式系統理論之租約機制學習

一，租約機制介紹

在分佈式系統中，每每會有一箇中心服務器節點。該節點負責存儲、維護系統中的元數據。若是系統中的各類操做都依賴於中心服務器上的元數據，那麼中心服務器很容易成爲性能瓶頸及存在單點故障。而經過租約機制，能夠將中心服務器的「權力」下放給其餘機器，就能夠減輕中心服務器的壓力。固然，租約機制還有許多其餘的用途：好比，肯定集羣中結點的狀態，還能夠實現分佈式下的讀寫鎖……

以下圖，GFS master頒發租約給某個chunk server，讓它成爲Primary 副本，當有多個client併發更新數據塊時，由Primary副本肯定併發更新該數據塊的順序。GFS master 將權力下放給 chunk server，緩解了必定的壓力。

 

固然，也能夠將中心服務器（元數據服務器）設計成集羣的形式。這樣，也避免了中心服務器成爲瓶頸問題。好比，消息服務器：RocketMQ。其中生產者和消費者都須要NameServer來肯定訂閱關係，將NameServer作成無狀態的集羣，這裏就不須要租約機制了。

 

對於租約而言，就有發佈租約方 和 接收租約方。租約規定的內容能夠多種多樣（這也是租約具備各類應用場景的緣由）。發佈租約方通常爲上面提到的中心服務器，中心服務器保證在租約的有效期內承諾租約規定的內容的保持不變。

好比，分佈式緩存系統，元數據服務器(中心服務器)給各個Client發佈租約，承諾在租約有效期內不會更改元數據。這樣，各個Client只要檢查它的租約未過時，就能夠直接從本地讀取緩存的元數據，而不是每次都訪問元數據服務器得到元數據。

 

二，租約機制分析

①租約機制保證緩存的一致性

 服務器發出Lease後，會保證在Lease的有效期內不改變數據。這樣，收到Lease的Client在有效期內能夠放心地使用數據。在這個有效期內，Client 緩存的數據和 服務器上的數據是一致的。

存在的問題：

1)服務器修改元數據時，須要 阻塞全部的讀請求，此時服務器不能發出新的Lease。以防止新發出的Lease保證的數據與服務器剛纔修改的數據不一致。

解決方法：讀請求到來時，直接返回數據，不頒發Lease

 

2)服務器須要等待直至全部的Client的Lease都過時後，再才頒發新「修改」後的Lease。所以，此時服務器上的數據修改了，生成了一個新的Lease版本，須要等到Client上全部的老Lease過時後，該新Lease版本才能頒佈給Client。

解決方法：服務器主動通知持久Lease的Client放棄當前的Lease，並請求新Lease

 

另外一種緩存一致性的保證方法相似於「租約機制」，當Client請求Server的數據時，Server爲Client提供一個「回調承諾」，用於保證當其餘Client修改此數據時通知該Client。回調承諾 和 請求的數據都保存在Client端，回調承諾有兩種狀態：有效和取消。

當Server執行了一個更新數據請求時，它會通知它發送了回調承諾的全部Client，即給Client的端的進程發一個回調（server到client的一個遠程過程調用）

，當Client進程收到回調時，它將相關數據的回調承諾標識設置爲「取消」。

 

②租約機制可以很好地容納網絡錯誤異常

 1）Lease頒發過程只依賴於單向的網絡通訊

服務器頒發Lease後，即便Client沒有收到（Client宕機、網絡異常），服務器只要等到Lease超時，就能夠保證Client再也不cache數據，從而能夠放心地修改數據而不會破壞cache的一致性。

2）一旦Lease被Client接收，後續Lease機制再也不依賴於網絡通訊。

3）對宕機節點有很好的容錯性

頒發Lease的節點宕機了，宕機的頒發者改變不了已經頒發出的Lease的約定，不會影響Lease的正確性。

擁有Lease的節點宕機了，頒發者也不須要作容錯處理，只須要等待Lease到期了，就能夠收回承諾進行下一步處理。

 

③租約機制肯定節點的狀態

 在網絡中，如何肯定某個節點的狀態呢？因爲網絡故障(網絡分化)的存在，採用「心跳」機制肯定節點的狀態會有一些不足。

好比，A、B、C三個節點互爲副本，A爲primary，Q負責判斷A、 B 、C的狀態。若是A正常工做，可是A 、Q之間的網絡異常，Q也會認爲A出現了問題了，因而 Q 從新選擇B做爲primary，這裏會致使「雙主」問題。

這裏的本質是：Q認爲A異常了，可是A本身不認爲本身異常。即，因爲網絡分化形成系統對於「節點狀態」認知的不一致。

 解決方法有兩個：1）可使用全體協商肯定誰爲primary(Paxos算法) ，這是一種去中心化協議

 2）採用Lease機制

 Q收到 A 、B 、C 的heart beat後，給它們頒發一個Lease，表示已經知道了它們的狀態，這樣 A 、B 、C 能夠在有效期內正常工做。同時，Q 能夠給 A一個特殊的Lease，表示A能夠做爲primary工做。當須要切換primary時，只須要等到A的Lease過時，Q給另外節點頒發表示 primary的Lease便可。

 

三，租約機制在 GFS 的寫操做中的做用

We designed the system to minimize the master’s involvement in all operations.
....
A mutation is an operation that changes the contents or metadata of a chunksuch as a write or an append operation.
 Each mutation is performed at all the chunk’s replicas.
We use leases to maintain a consistent mutation order across replicas. 
The master grants a chunk lease to one of the replicas, which we call the primary. The primary picks a serial
order for all mutations to the chunk. All replicas follow this order when applying mutations.

爲了減少 master 的負載，master 給某個chunk server 頒發lease，使之成爲primary，而後由primary肯定 mutation order。

The master may sometimes try to revoke a lease before it expires (e.g., when the master wants to disable mutations on a file that is being renamed). 
Even if the master loses communication with a primary, it can safely grant a new lease to another replica after the old lease expires.

這裏也採用 「租約機制分析」中講到的：①master能夠在租約還未過時以前 try to revoke a lease。②也能夠等到租約過時後，向其餘chunk server頒發primary租約(更換primary)。

 

The lease mechanism is designed to minimize management overhead at the master. A lease has an initial timeout of 60 seconds.

這句話代表，租約減小了master的負載，租約的有效期限是60s

寫操做的步驟以下：

1）The client asks the master which chunkserver holds the current lease for the chunk and the locations of the other replicas.

Client向master 請求primary地址和其餘chunk server地址

2)The master replies with the identity of the primary and the locations of the other (secondary) replicas.

 master返回primary地址及其餘chunk server地址。Client可在Lease的有效期內緩存這些信息。

 3）The client pushes the data to all the replicas

Client把待修改的數據發給各個chunk server(replicas)，這裏實現了控制流與數據流的分離（Client在第二步時得到了控制信息）。

 4）Once all the replicas have acknowledged receiving the data, the client sends a write request to the primary.

Client先把待寫入的數據發給各個 chunk server，等到全部的chunk server都收到這些數據後，向 primary 發起寫請求。

5)The primary forwards the write request to all secondary replicas.

由primary制定寫請求的順序。全部的replicas都按照這個順序寫數據。看，採用「中心化」的方式制定寫請求的順序，這樣很容易保證順序的惟一性。

6）The secondaries all reply to the primary indicating that they have completed the operation

全部的replicas（secondaries）都按照相同的順序寫入數據後，向primary發送完成報告。

7）The primary replies to the client.

由primary向Client報告這次寫操做的結果。

從上面的整個流程看，上面的操做不多涉及到master。大部分由master 頒發給Lease的primary來完成。

其實，我的感受對於 mutation operation，這裏的核心是兩個：❶下降master的負載   ❷保證修改順序的一致性。而經過Lease機制，解決了這兩個問題。

master給某臺chunk server頒發Lease，使之成爲Primary。由Primary接收Client的寫請求，由Primary負責其餘replicas的寫操做是否完成……這都有效地下降了master的負載；其次，由primary制定寫操做的序列號，順序的肯定是由primary肯定的，不是協商肯定的，這種「中心化」的機制容易保證順序的一致性。

 

四，參考資料

《分佈式系統原理介紹》--劉傑

租約機制簡介

租約機制簡單介紹

 Lease 機制在分佈式系統中的應用

 分佈式系統概念--第一篇 一致性協議、一致性模型、拜占庭問題、租約、副本協議

 

原文：http://www.cnblogs.com/hapjin/p/5620542.html