一，租約機制介紹
在分布式系統中，往往會有一個中心服務器節點。該節點負責存儲、維護系統中的元數據。如果系統中的各種操作都依賴于中心服務器上的元數據，那么中心服務器很容易成為性能瓶頸及存在單點故障。而通過租約機制，可以將中心服務器的“權力”下放給其他機器，就可以減輕中心服務器的壓力。當然，租約機制還有許多其他的用途：比如，確定集群中結點的狀態，還可以實現分布式下的讀寫鎖……
如下圖，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確定的，不是協商確定的，這種“中心化”的機制容易保證順序的一致性。
四，參考資料
《分布式系統原理介紹》--劉杰
分布式系統概念--第一篇 一致性協議、一致性模型、拜占庭問題、租約、副本協議
原文：http://www.cnblogs.com/hapjin/p/5620542.html
文章列表
留言列表
