PacificA中的租約與失效檢測解讀

PacificA是微軟的在基於log的分佈式存儲系統中的複製技術。

因爲配置管理器維護着當前配置的真實狀況，所以主節點沒必要保持不變。

這是由於配置的本地視圖在不一樣服務器上是沒必要同步的。

特別是，咱們必須避免這樣的狀況，一個老主節點和一個新主節點都在同一時間處理查詢-老主節點可能沒有意識到一個重配置信息已經被新主節點建立，而且已將它從配置中移除。因爲新主節點能夠處理新的更新，老主節點可能還在處理過時狀態的查詢，所以這樣就違反了強一致性。 

咱們的方案是使用租約。經過週期性發送標燈的方式，主節點從每個從節點那裏請求一個租約，在發送標燈後等待確認。

若是從最後一個確認標燈發送的時間開始，一個指定的租約期限已過，主節點就認爲租約過時。

當從節點上的任何租約過時時，主節點再也不認爲本身是一個主節點，而且中止全部查詢或更新處理。

這種狀況下，主節點會聯繫配置管理器從當前配置中移除從節點。只要發送者仍然保留主節點在當前配置中，從節點就認爲標燈有效。

若是從主節點收到最後一個標燈開始的寬限週期已過，從節點認爲對主節點的租約已過時，並將聯繫配置管理器去移除當前主節點，並把本身變成一個新主節點。

假設沒有時鐘誤差，只要寬限週期相同於或者大於租約週期，那麼主節點上的租約會在從節點上處理以前被裁定爲過時。

從節點會先假設配置發生改變，若是僅且若是它的租約對老主節點過時時，從節點會嘗試扮演主節點的角色。

所以在新主節點被肯定前，老主節點就已經被從新分配，因而主節點依舊保持不變。 

咱們使用租約機制做爲失效檢測機制。 相似的失敗檢測機制被用於其餘系統當中，如GFS，Boxwood和Bigtable/Chubby。

這裏的關鍵的不一樣點是在這些系統當中租約是從中心實體獲取的。 而在咱們的情景裏，用於失效檢測的監控老是處於兩個服務器之間，因爲數據處理在彼此之間已經存在：當處理更新的時候主節點與從節點們通信；標燈與確認消息一樣也是介於主節點與從節點之間。 以這種方式，失效檢測可以準確的捕獲用於複製的通訊通道的狀態。

當通訊通道繁忙的時候，數據處理消息也能夠自行處理就像標燈與確認消息同樣。 只有在通訊通道空閒的時候， 實際的標燈與確認消息纔會被髮送，從而能夠最小化失敗檢測的開銷。 進一步來說，在中心化的實現當中要考慮負載消除與對中心實體的依賴。負載是很明顯的，由於標燈與確認消息老是按期的在系統中的中心實體和每個服務器間交換；交換的時間間隔必須至關小，才能保證快速的失效檢測。 在中心化方案中，中心實體的不可用（如因爲網絡分區）會致使整個系統的不可用，由於當中心實體丟失租約信息時，全部的主節點不得不進行從新分配。