租約的作用：分散式環境中維持快取的一致性的一種協議

傳統的解決方案：

輪詢：即每次讀取資料時都先詢問伺服器資料是否是最新的，如果不是就從伺服器傳輸新資料，這種方法需要每次讀取資料時都與伺服器通訊。

問題：每讀取資料都需要與伺服器確認，伺服器負載大

回撥或稱為無效化：由伺服器記住有哪些客戶端讀取了資料，對資料做修改時首先通知所有這些客戶端資料已經失效。

問題：需要伺服器記住所有讀取過資料的客戶端，這是很大的負擔，更嚴重的是，一旦有客戶端聯絡不上或者丟失了客戶端的資訊，修改操作將無法進行。

分散式應用環境中，租約是一個使用物理時鐘處理主機和通訊失敗的一致性協議。

租約是一種協議，該協議賦予持有該協議者在某個屬性性特定的有限時間的權利。在快取中，即伺服器給予客戶端在一定期限內可以控制修改操作的 權力，比如在資料被寫入之前，伺服器必須獲取租約持有者的批准。客戶端從伺服器讀取資料時往往就同時獲取租約

因 為租約是基於時鐘的，因此其有效性需要系統時間來保證

很多情況下，系統中已經有一個保證一致性的中心服務，如某個單一伺服器或者是實現了Paxos協議的一組伺服器，但如果所有的功能都需要通過這個中心服務，很容易造成效能瓶頸。為了提高效率和擴充套件性，可以通過租約把一致性擴充套件到更多服務上。事實上用租約來維護快取一致性也是相當於把伺服器上的資料一致性擴充套件到了客戶端。

客戶端寫資料：伺服器必須推遲該請求直到每一個擁有租約的客戶端同意或者該客戶端上的對應的租約過期。

租約時間為零就相當於輪詢，此時修改操作隨時可以進行，而 讀取資料總是要聯絡伺服器，租約時間無限長就相當於回撥。

租約與帶期限的鎖非常相似，但更加靈活，因為租約還提供了“尋求同意”的機制（我覺得可以稱為“帶期限可妥協的鎖”）。伺服器還可以實現多種租約，比如“寫租約”和“讀租約”，並保證一個時間段內只有一個寫租約或者多個讀租約，這就相當於是單寫者多讀者的鎖協議。

一般租約的週期都比較短，太長容易引起假共享問題。

 對於一個期限為Ts的租約，對於該快取的真正有效期Tc實際上是：

Tc=max(0,Ts-(Mprop+2Mproc)-e)

到底租約是什麼？

在很多時候，租約的定義似乎很模糊，有的時候租約類似心跳，有的時候又類似於鎖。到底租約的本質是什麼呢？

回到租約最原始的定義：租約就是在一定期限內給予持有者特定權力的 協議。我覺得這裡的期限就是租約的根本特性，正是這一特性使得租約可以容忍機器失效和網路分割。在期限之內，租約其實就是伺服器和客戶端之間的協議，而這 個協議的內容可以五花八門。如果協議內容是伺服器確認客戶端還存活，那麼這個租約的功能就相當於心跳；如果協議內容是伺服器保證內容不會被修改，那麼這個 租約就相當於讀鎖；如果協議內容是伺服器保證內容只能被這個客戶端修改，那麼這個租約就相當於寫鎖。租約這種靈活性和容錯性，使其成為了維護分散式系統一致性的有效工具。

租約適用與什麼情況：租約適合用於“單點”伺服器的場景，例如GFS系統master使用租約管理chunkServer）。

租約的擴充套件：

 事實上租約不止能用於保持快取的一致性，我們要了解到租約的本質，本質上來講，租約至少在租約有效期內，讓租約擁有者決定某件事。在快取一致性中，在租約有效期內，租約持有者（也就是從伺服器中讀取資料的客戶端）擁有該租約所在物件（伺服器物件的資料）的決定權，在伺服器修改資料時，必須通知租約持有者讓其同意，從而才能修改。

在GFS檔案系統中：Master節點為Chunk的一個副本建立一個租約，我們把這個副本叫做主Chunk。主 Chunk對Chunk的所有更改操作進行序列化。所有的副本都遵從這個序列進行修改操作。因此，修改操作全域性的順序首先由Master節點選擇的租約的 順序決定，然後由租約中主Chunk分配的序列號決定。GFS檔案系統中為了保持高可用，必須擁有資料副本，而為了提高客戶端響應速度，客戶端不需要寫多份資料，僅需要寫一份資料到主chunk資料即可。在這裡租約的作用是什麼？要解決這個問題我們可以反過來想，假設在寫的過程中有這幾種情況，

              在租約有效期內： master聯絡不到主chunk，客戶端可以聯絡到主chunk。對於修改操作順序都一致,並沒有影響，

              在租約有效期內：master聯絡不到主chunk,客戶端不可以聯絡到主chunk。對於修改操作所有的操作全都失敗，但並不會影響資料的一致性（因為沒有資料寫入，全部返回失敗）

              當租約失效：master重新選擇主chunk,不論客戶端聯不聯絡到主chunk,操作都不會受影響（假設聯絡到原先的chunk,客戶端會被告知，其租約已失效，重新到master中獲取新的主chunk資訊，若在過期前一直聯絡不到主chunk,到過期後（客戶端快取過期時間）會從新從主master拉取資訊）。

         從上面我們可以看出，這種租約機制保證了寫順序性，同時由於租約，假設master與chunk所在的chunkServer伺服器失去了聯絡，該租約也會有效，也減輕了master的負擔(客戶端不用每次寫入都請求master，在租約有效期內，client只需訪問一次master,因為master修改chunk資料，必須要進過chunkServer同意，所以如果chunkServer改變客戶端再次訪問時，會被yuanchunkServer)

     對GFS檔案中的租約機制做一個簡要的總結:GFS檔案系統中使用租約機制來確保寫入的順序性，並有效的減輕了master的負擔（如果沒有租約，每次寫入都必須詢問master寫入到哪個chunk中）。

參考：The Google System File