分佈式系統設計(4)

先說一下前面三節介紹的內容，若是須要請參考，

第一節介紹數據分佈方式：http://www.cnblogs.com/jacksu-tencent/p/3405680.html

第二節介紹副本控制協議：http://www.cnblogs.com/jacksu-tencent/p/3407712.html

第三節介紹基於Lease的分佈式cache系統：http://www.cnblogs.com/jacksu-tencent/p/3409646.html

經過第三節的介紹，你們應該對Lease機制有必定的瞭解了，本節主要介紹Lease的本質，以及經過lease機制，如何來判斷節點的狀態，最後介紹在hdfs、chuby和zookeeper中如何應用lease機制。

Lease機制本質

Lease 是由頒發者授予的在某一有效期內的承諾。主要有兩方面的承諾

一方面頒發者一旦發出 lease，則不管接受方是否收到，也不管後續接收方處於何種狀態，只要 lease 不過時，頒發者必定嚴守承諾；

另外一方面，接收方在 lease 的有效期內可使用頒發者的承諾，但一旦 lease 過時，接收方必定不能繼續使用頒發者的承諾。

就是隻要lease不過時，頒發者必定嚴守承諾；一旦lease過時，接收方必定不能繼續使用頒發者的承諾。

Lease機制容錯能力

首先，經過引入有效期，Lease 機制有很是好的容錯網絡異常。 Lease 頒發過程只依賴於網絡能夠單向通訊，即便接收方沒法向頒發者發送消息，也不影響 lease的頒發。因爲 lease 的有效期是一個肯定的時間點，lease 的語義與發送 lease 的具體時間無關，因此同一個 lease 能夠被頒發者不斷重複向接受方發送。即便頒發者偶爾發送 lease 失敗，頒發者也能夠簡單的經過重發的辦法解決。一旦 lease 被接收方成功接受，後續 lease 機制再也不依賴於網絡通訊，即便網絡徹底中斷 lease 機制也不受影響。

再者，Lease 機制能較好的容錯節點宕機。若是頒發者宕機，則宕機的頒發者一般沒法改變以前的承諾，不會影響 lease 的正確性。在頒發者機恢復後，若是頒發者恢復出了以前的 lease 信息，頒發者能夠繼續遵照 lease 的承諾。若是頒發者沒法恢復 lease信息，則只需等待一個最大的 lease 超時時間就可使得全部的 lease 都失效，從而不破壞 lease 機制。例如上節中的 cache 系統的例子中，一旦服務器宕機，確定不會修改元數據，從新恢復後，只需等待一個最大的 lease 超時時間，全部節點上的緩存信息都將被清空。對於接受方宕機的狀況，頒發者不須要作更多的容錯處理，只需等待 lease 過時失效，就能夠收回承諾，實踐中也就是收回以前賦予的權限、身份等。

最後，lease 機制不依賴於存儲。頒發者能夠持久化頒發過的 lease 信息，從而在宕機恢復後可使得在有效期的 lease 繼續有效。但這對於 lease 機制只是一個優化，如以前的分析，即便頒發者沒有持久化 lease 信息，也能夠經過等待一個最大的 lease 時間的方式使得以前全部頒發的 lease 失效，從而保證機制繼續有效。

頒發方和接收方時間不一樣步該如何處理呢？？？

分爲兩種狀況：

若是頒發者的時鐘比接收者的時鐘慢，則當接收者認爲 lease 已通過期的時候，頒發者依舊認爲 lease 有效。接收者能夠用在 lease 到期前申請新的 lease 的方式解決這個問題。

若是頒發者的時鐘比接收者的時鐘快，則當頒發者認爲 lease 已通過期的時候，接收者依舊認爲 lease 有效，頒發者可能將 lease頒發給其餘節點，形成承諾失效，影響系統的正確性。對於這種時鐘不一樣步，實踐中的一般作法是將頒發者的有效期設置得比接收者的略大，只需大過期鍾偏差就能夠避免對 lease 的有效性的影響。

基於lease機制如何肯定節點狀態

經過一個例子來討論這個問題：

在一個 primary-secondary 架構的系統中，有三個節點 A、B、C 互爲副本，其中有一個節點爲 primary，且同一時刻只能有一個 primary 節點。另有一個節點 Q 負責判斷節點 A、B、C的狀態，一旦 Q 發現 primary 異常，節點 Q 將選擇另外一個節點做爲 primary。假設最開始時節點 A爲 primary，B、C 爲 secondary。節點 Q 須要判斷節點 A、B、C 的狀態是否正常。

經過心跳沒法很好判斷節點狀態

節點 A、B、C 能夠週期性的向 Q 發送心跳信息，若是節點 Q 超過一段時間收不到某個節點的心跳則認爲這個節點異常。這種方法的問題是假如節點 Q 收不到節點 A 的心跳，除了節點 A 自己的異常外，也有多是由於節點 Q 與節點 A 之間的網絡中斷致使的。在工程實踐中，更大的可能性不是網絡中斷，而是節點 Q 與節點 A 之間的網絡擁塞形成的所謂「瞬斷」，「瞬斷」每每很快能夠恢復。另外一種緣由甚至是節點 Q 的機器異常，以致於處理節點 A 的心跳被延遲了，以致於節點 Q 認爲節點 A 沒有發送心跳。假設節點 A 自己工做正常，但 Q 與節點 A 之間的網絡暫時中斷，節點 A 與節點 B、C 之間的網絡正常。此時節點 Q 認爲節點 A 異常，從新選擇節點 B 做爲新的 primary，並通知節點 A、B、C 新的 primary 是節點 B。因爲節點 Q 的通知消息到達節點 A、B、C 的順序沒法肯定，假如先到達 B，則在這一時刻，系統中同時存在兩個工做中的 primary，一個是 A、另外一個是 B。假如此時 A、B 都接收外部請求並與 C 同步數據，會產生嚴重的數據錯誤。上述即所謂「雙主」問題。

雙主問題的解決

由中心節點向其餘節點發送 lease，若某個節點持有有效的 lease，則認爲該節點正常能夠提供服務。如節點 A、 B、 C 依然週期性的發送 heart beat 報告自身狀態，節點 Q 收到 heart beat後發送一個 lease，表示節點 Q 確認了節點 A、B、C 的狀態，並容許節點在 lease 有效期內正常工做。節點 Q 能夠給 primary 節點一個特殊的 lease，表示節點能夠做爲 primary 工做。一旦節點 Q 但願切換新的 primary，則只需等前一個 primary 的 lease 過時，則就能夠安全的頒發新的 lease 給新的primary 節點，而不會出現「雙主」問題。

一箇中心節點風險解決

藉助chubby 和 zookeeper

lease 的有效期時間選擇

常選擇的 lease 時長是 10 秒級別，這是一個通過驗證的經驗值，實踐中能夠做爲參考並綜合選擇合適的時長。

GFS 中的 Lease

GFS 中使用 Lease 肯定 Chuck 的 Primary 副本。 Lease 由 Master 節點頒發給 primary 副本，持有Lease 的副本成爲 primary 副本。Primary 副本控制該 chuck 的數據更新流量，肯定併發更新操做在chuck 上的執行順序。GFS 中的 Lease 信息由 Master 在響應各個節點的 HeartBeat 時附帶傳遞（piggyback）。對於每個 chuck，其上的併發更新操做的順序在各個副本上是一致的，首先 master選擇 primary 的順序，即頒發 Lease 的順序，在每一任的 primary 任期內，每一個 primary 決定併發更新的順序，從而更新操做的順序最終全局一致。當 GFS 的 master 失去某個節點的 HeartBeat 時，只需待該節點上的 primary chuck 的 Lease 超時，就能夠爲這些 chuck 從新選擇 primary 副本並頒發 lease。

Chubby 與 Zookeeper 中的 Lease

Chubby 中有兩處使用到 Lease 機制。

咱們知道 chubby 經過 paxos 協議實現去中心化的選擇 primary 節點。一旦某個節點得到了超過半數的節點承認，該節點成爲 primary 節點，其他節點成爲 secondary 節點。Secondary節點向 primary 節點發送 lease，該 lease 的含義是：「承諾在 lease 時間內，不選舉其餘節點成爲 primary節點」。只要 primary 節點持有超過半數節點的 lease，那麼剩餘的節點就不能選舉出新的 primary。一旦 primary 宕機，剩餘的 secondary 節點因爲不能向 primary 節點發送 lease，將發起新的一輪 paxos選舉，選舉出新的 primary 節點。

除了 secondary 與 primary 之間的 lease，在 chubby 中，primary 節點也會向每一個 client 節點頒發

lease。該 lease 的含義是用來判斷 client 的死活狀態，一個 client 節點只有只有合法的 lease，才能與chubby 中的 primary 進行讀寫操做。一個 client 若是佔有 chubby 中的一個節點鎖後 lease 超時，那麼這個 client 佔有的 chubby 鎖會被自動釋放，從而實現了利用 chubby 對節點狀態進行監控的功能。另外， chubby 中 client 中保存有數據的 cache，故此 chubby 的 primary 爲 cache 的數據頒發 cache lease，該過程與 前一節介紹的基於 lease 的 cahce 機制徹底相似。雖然相關文獻上沒有直接說明，但筆者認爲，chubby 的 cache  lease 與 primary 用於判斷 client 死活狀態的 lease 是能夠合併爲同一個 lease的，從而能夠簡化系統的邏輯。

與 Chubby 不一樣， Zookeeper 中的 secondary 節點（在 zookeeper 中稱之爲 follower）並不向 primary節點（在 zookeeper 中稱之爲 leader）發送 lease， zookeeper 中的 secondary 節點若是發現沒有 primary節點則發起新的 paxos 選舉，只要 primary 與 secondary 工做正常，新發起的選舉因爲缺少多數secondary 的參與而不會成功。與 Chubby 相似的是， Zookeeper 的 primary 節點也會向 client 頒發 lease，lease 的時間正是 zookeeper 中的 session 時間。在 Zookeeper 中，臨時節點是與 session 的生命期綁定的， 當一個 client 的 session 超時，那麼這個 client 建立的臨時節點會被 zookeeper 自動刪除。經過監控臨時節點的狀態，也能夠很容易的實現對節點狀態的監控。在這一點上，zookeeper 和 chubby 徹底是殊途同歸。

下一節簡單有效的副本管理機制quorum