Lease 中文叫租約，是一種廣泛應用於分佈式系統領域的協議，它是一種維護分佈式系統一致性的有效工具。
Lease 通常定義爲：頒發者在一定期限內給予持有者一定權利的協議。
Lease 表達了頒發者在一定期限內的承諾，只要未過期頒發者必須嚴格遵守 lease 約定的承諾。
Lease 的持有者在期限內使用頒發者的承諾，但 lease 一旦過期必須放棄使用或者重新和頒發者續約。
下面看看 lease 機制的幾個具體應用。
1. 動態密鑰管理
中心密鑰服務器維護着全局的密鑰生成和發放，所有需要使用密鑰的外圍系統向密鑰服務器申請密鑰用於本系統的加解密工作。出於性能和可用性考慮，不能每個請求都向中心服務器去申請，因此密鑰通常被緩存在本地系統中。那麼當需要修改中心繫統的密鑰時（出於安全性考慮的定期修改），如何保證所有使用該密鑰的本地系統都立刻丟棄過期的密鑰，而立刻向中心密鑰服務器重新申請最新的密鑰，並保持所有系統中密鑰的一致性？（不一致可能導致系統不可用）。
這種場景非常適合使用 lease 機制來解決，中心服務器發放密鑰的時候，同時發放一個 lease 承諾在一定時間內不修改該密鑰。本地系統獲取密鑰時，同時根據 lease 的約定只在其有效期內使用密鑰，lease 一旦過期立刻重新申請密鑰。當變更密鑰時，在所有已頒發的 lease 全部過期前修改不能生效，並且在變更密鑰生效期間不能頒發新的 lease，避免形成活鎖（永遠等不到所有 lease 失效）。
這個機制大體如上述，但還有一些細節點需要考慮，lease 機制依賴於分佈式環境下的服務器時鐘同步，如果出現時鐘不同步的情況，在這個應用場景下會帶來什麼影響？如何規避或解決？
中心服務器時鐘比客戶端系統快：這種情況下，中心服務器將 lease 過期時，客戶端服務器還在使用。在這個時間差範圍內如果中心服務器變更了密鑰，會導致客戶端服務器的密鑰錯誤造成服務不可用。這種情況可以設置 lease 頒發者（中心服務器）的有效期設置的比接收者（客戶端）更大，大過時鐘誤差。
中心服務器時鐘比客戶端系統慢：這種情況下，客戶端將 lease 過期時中心服務器還未過期，客戶端只需重新發起新的 lease 申請即可，如果此時遇到中心服務器正在進行密鑰更新鎖定不能頒發 lease，則可只返回當前的密鑰數據，而不頒發 lease。客戶端將在這個時間窗口中退化爲每請求一次性的使用該密鑰數據。
客戶端接入時的校時驗證：考慮到 lease 依賴時鐘的精確同步（誤差最好不要太大），那麼可以考慮客戶端向中心請求時攜帶自身的時間戳，以便中心服務器可以對其進行校時誤差，當誤差超過允許範圍（例如：5秒）時，可以考慮拒絕接入或報警通知。
設計合理的 lease 有效期：考慮在密鑰系統這個業務場景下，雖然變更發生的情況比較少。但如果出現安全事件需要緊急變更時需要 lease 快速失效時，最及時的辦法是設計客戶端的回調接口由中心去通知客戶端立刻放棄 lease，這樣會增加實現的複雜度。另一種折中的辦法是採用較短的失效時間（例如：2分鐘），這樣可以保證密鑰變更會在最長不超過 2分鐘 + 時鐘誤差的範圍內完成全局的更新，具體策略的採用可以根據實際需求去權衡。
2. 分佈式文件系統
以GFS爲例，每個文件塊都有多個副本分佈在多個chunckserver上，在 並行追加時必須有一個全局統一的追加順序。
當然這個順序全部由中心 master 來決定，那 master 將承擔過大的負荷。
GFS採用了 lease 機制，就是對每個文件塊 master 向 chunkserver 頒發 lease，在 lease 有效期內由它決定並行文件追加的順序。在 lease 有效期內，chunkserver 可以一直續約，如果出現機器宕機或網絡斷鏈時，master 可在 lease 過期後重新選擇另一個 chunkserver，只要保證對同一個文件塊的並行追加在集羣中只有一個 chunkserver 決定其追加順序即可。
3. 狀態檢測
在通常的集羣系統中，我們採用心跳來檢測節點狀態。但普通的心跳機制是無協議和承諾約定的，所以它的檢測結果可能不可靠。很多監控系統採用心跳檢測集羣中節點的存活性，這種機制存在誤報警的可能。
普通心跳通常是在規定的時限內定期向檢測節點發送存活性報告，若超出一段時間未能收到心跳報告，那麼檢測節點則判斷節點可能失效，並採取一系列措施（報警、通知節點的使用者）。這種機制存在的問題是，檢測節點單方面判定節點失效，在某些業務集羣系統中可能存在風險。節點自身並未認識自己已被認定失效，還在繼續提供正常的服務。若該節點在集羣中承擔唯一 primary 節點的職責，而檢測節點的失效判定發起了重新選擇新的主節點，會引發“雙主”問題。
採用 lease 機制的心跳實現，則徹底避免了此類問題。由於網絡分割的原因，其實沒有任何技術可以可靠的判定節點狀態，但採用 lease 機制的狀態檢測，可以避免出現誤判時引入新的問題。
從以上幾個簡單的 lease 機制應用，我們可以看出 lease 作爲一種協議承諾，其承諾的範圍十分寬泛。
如果協議內容是確認客戶端存活，那麼這個租約就相當於心跳。
如果協議內容是保證內容不會被修改，那麼這個租約就相當於讀鎖。
如果協議內容是保證只能被某個客戶端修改，那麼這個租約就相當於寫鎖。
