最近在學習分佈式，將學習筆記，總結精華分享出來，歡迎大家一起學習一起討論！
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
前言：Lease 機制最重要的應用：判定節點狀態。
基於 lease 的分佈式 cache 系統
一、
1、原理：中心服務器向各節點發送數據的同時頒發一個lease,每個lease具有一個有效期（確保中心服務器與各節點的時鐘時同步的），在lease的有效期內，中心服務器保證不會修改數據的值，節點收到數據和lease後，將數據加入本地cache，一旦對應的lease過期，將刪除本地的cache數據。
2、基本流程：
客戶端節點讀取元數據：
①判斷元數據是否處於本地的cache中且lease處於有效期內，是就直接返回元數據信息
②不滿足條件1的話，向中心服務器節點請求讀取元數據信息。
③服務器收到讀請求後返回數據同時頒發一個對應的lease
④客戶端收到服務器返回的數據記錄到本地cache，如果失敗或超時，讀取失敗退出流程。
客戶端節點修改元數據流程
①節點向服務器發起請求修改元數據
②服務器收到請求，阻塞所有新的讀請求，接收請求，但是不返回數據
③服務器等待所有與該元數據相關的lease超時
④服務器修改元數據並向客戶端節點返回修改成功
二、lease 機制可以容錯的關鍵是：服務器一旦發出數據及 lease，無論客戶端是否收到，也無論後續客戶端是否宕機，也無論後續網絡是否正常，服務器只要等待 lease 超時，就可以保證對應的客戶端節點不會再繼續 cache 數據，從而可以放心的修改數據而不會破壞 cache 的一致性。
三、性能及可用性的優化：
1、服務端在修改元數據時會阻塞所有的讀請求，造成沒有讀服務。這種情況可以優化爲繼續返回元數據，但是不頒發lease，也就是說用戶可以讀到元數據但是不能緩存元數據。
2、服務器在修改元數據時要等待所有持有lease的節點過期才進行修改，造成延時較大。對於這種情況，可以在元數據修改之前服務端主動通知各個節點放棄lease並清除cache中的數據,如果接收到客戶端確認放棄則進行修改，否則等待過期進行修改。
四、lease機制與多副本機制的區別：對於 cache 的數據，可以隨時刪除丟棄，並命中cache 的後果僅僅是需要訪問數據源讀取數據；然而副本機制卻不一樣，副本是不能隨意丟棄的，每失去一個副本，服務質量都在下降，一旦副本數下降到一定程度，則往往服務將不再可用。
lease 機制的分析
1、lease的定義：Lease是由頒發者授予的在某一有效期內的承諾。
注：這種承諾的內容非常寬泛，可以是數據的正確性，也可以是某種權限，也可以是某種身份。如在 primary-secondary架構中，給節點頒發lease，只有持有 lease 的節點才具有 primary 身份。
2、lease機制有很高的容錯能力：
①lease機制的有效期可以較好的容錯網絡異常。
頒發者可以不斷重複的向接收者發放相同的lease,一旦lease被接受，那麼在有效期內就不依賴於網絡通信（即使網絡完全中斷也不會有影響）。
②Lease機制能較好的容錯節點宕機。
如果頒發者宕機，不會影響lease的正確性，頒發者恢復後可以繼續遵守lease的承諾，如果頒發者不能恢復，那麼只需等待lease超時即可，並不會破壞lease機制。
③lease機制不依賴於存儲，頒發者可以持久化頒發過的lease信息，使得宕機恢復後的lease繼續生效
3、lease機制依賴於有效期，所以要求頒發者和接收者的始終必須要同步。對於這種時鐘不同步，實踐中的通常做法是將頒發者的有效期設置得比接收者的略大，只需大過時鐘誤差就可以避免對lease的有效性的影響。
基於 lease 機制確定節點狀態
背景：在primary-secondary 架構的系統中，有三個節點 A、B、C 互爲副本，假設最開始時節點 A爲 primary，B、C 爲 secondary。節點 Q 如何判斷節點 A、B、C 的狀態是否正常？
1、節點 A、B、C 週期性的發送 heart beat 報告自身狀態，節點 Q 收到 heart beat後發送一個lease，表示節點 Q 確認了節點 A、B、C 的狀態，並允許節點在 lease 有效期內正常工作。
2、節點Q給primary節點A一個特殊的 lease，表示A節點可以作爲primary工作。一旦節點Q希望切換新的primary B，則只需等前一個 primary A的lease過期，就可以安全的頒發新的lease給新的primary B節點，並不會出現“雙主”問題。
注：一箇中心節點發送lease風險很大，實際的系統中使用多箇中心節點互爲副本，成爲一個小的集羣對外提供頒發 lease 的功能。zookeeper就是基於這樣的設計。
lease 的有效期時間選擇
使用 lease 確定節點狀態時，若 lease 時間過短，有可能造成網絡瞬斷時節點收不到lease從而引起服務不穩定，若lease時間過長，則一旦某節點宕機異常，需要較大的時間等待lease過期才能發現節點異常。工程中，常選擇的 lease 時長是 10 秒級別，這是一個經過驗證的經驗值，實踐中可以作爲參考並綜合選擇合適的時長。
工程實例
Zookeeper的primary節點也會向client頒發lease，lease 的時間正是 zookeeper 中的 session 時間。在Zookeeper中，臨時節點是與session的生命期綁定的，當一個 client 的 session 超時，那麼這個 client 創建的臨時節點會被 zookeeper 自動刪除。通過監控臨時節點的狀態，也可以很容易的實現對節點狀態的監控。
參考資料：《分佈式系統原理介紹》作者：劉傑
如有錯誤歡迎指正！