分佈式系統基本副本協議

一、中心化副本控制協議

中心化副本控制協議的基本思路是由一箇中心節點協調副本數據的更新、維護副本之間的一致性。

優點:協議相對較爲簡單,所有的副本相關的控制交由中心節點完成。併發控制也由中心節點完成。

缺點:系統的可用性依賴於中心化節點,當中心節點異常時存在一定的停服務時間。

primary-secondary協議

primary-secondary協議(也稱 primary-backup)是中心化副本控制協議的非常常用的一種。在 primary-secondary 類型的協議中,副本被分爲兩大類,其中有且僅有一個副本作爲 primary 副本,除 primary 以外的副本都作爲 secondary 副本。

維護 primary 副本的節點作爲中心節點,中心節點負責維護數據的更新、併發控制、協調副本的一致性。

Primary-secondary 類型的協議一般要解決四大類問題:數據更新流程、數據讀取方式、Primary副本的確定和切換、數據同步(reconcile)。

1、數據更新的基本流程

①數據更新都由 primary 節點協調完成。

②外部節點將更新操作發給 primary 節點

③primary 節點進行併發控制即確定併發更新操作的先後順序

④primary 節點將更新操作發送給 secondary 節點

⑤primary 根據 secondary 節點的完成情況決定更新是否成功並將結果返回外部節點

 

其中第4步,如果由primary節點同時將更新數據發送給其他secondary副本,則其他secondary副本的的更新受primary網絡帶寬的影響,最大爲1/N.爲了解決這個問題,有些系統(GFS)使用接力的方式同步數據。

2、數據讀取方式

①如果只需要最終一致性,則讀取任何副本都可以滿足需求。

②如果需要會話一致性,則可以爲副本設置版本號,每次更新後遞增版本號,用戶讀取副本時驗證版本號,從而保證用戶讀到的數據在會話範圍內單調遞增。

primary-secondary 比較困難的是實現強一致性,以下是2中思路:

①如果始終只讀 primary 副本的數據,可以實現強一致性,但是secondary將不提供讀服務。實踐中,如果副本不與機器綁定,以數據段爲副本的基本單位,將副本分散到集羣中個,假設primary 也是隨機的確定的,那麼每臺機器上都有一些數據的 primary 副本,也有另一些數據段的 secondary 副本,從而每臺服務器實際都提供讀寫服務。

②由 primary 控制節點 secondary 節點的可用性。當 primary 更新某個 secondary 副本不成功時,primary 將該 secondary 副本標記爲不可用,不可用的secondary 副本可以繼續嘗試與 primary 同步數據直到同步成功,primary將副本標記爲可用。這種方式依賴於一箇中心元數據管理系統,用於記錄哪些副本可用,哪些副本不可用。

3、primary副本的確定和切換

確定副本:在 primary-secondary 類型的分佈式系統中,哪個副本是 primary 這一信息都屬於元信息,由專門的元數據服務器維護。

切換副本的難點:

①如何發現primary節點異常,Lease 機制(後面介紹)

②切換primary後如何做到不影響副本的一致性。如何確定一個 secondary 副本使得該副本上的數據與原primary一致?

由於分佈式系統中可靠的發現節點異常是需要一定的探測時間的,這樣的探測時間通常是 10秒級別,在這 10 秒時間內,由於沒有 primary,系統不能提供更新服務,甚至不能提供讀服務。因此,primary-backup 類副本協議的最大缺點就是primary切換帶來的一定的停服務時間。

4、數據同步

通常不一致的形式有三種:

①由於網絡分化等異常,secondary 上的數據落後於 primary 上的數據。回放 primary 上的操作日誌。

②在某些協議下,secondary 上的數據有可能是髒數據,需要被丟棄。髒數據是由於primary 副本沒有進行某一更新操作,而 secondary 副本上反而進行的多餘的修改操作,從而造成secondary 副本數據錯誤。可以設計一些基於 undo 日誌的方式(後期分享)從而可以刪除髒數據。

③secondary 是一個新增加的副本,完全沒有數據,需要從其他副本上拷貝數據。直接拷貝 primary 副本的數據,但拷貝數據時 primary 副本需要能夠繼續提供更新服務,這就要求 primary 副本支持快照(snapshot)功能。即對某一刻的副本數據形成快照,然後拷貝快照,拷貝完成後使用回放日誌的方式追快照形成後的更新操作。

二、去中心化副本控制協議

去中心化副本控制協議沒有中心節點,協議中所有的節點都是完全對等的,節點之間通過平等協商達到一致。從而去中心化協議沒有因爲中心化節點異常而帶來的停服務等問題。

缺點:協議過程通常比較複雜、效率低
Paxos 是唯一在工程中得到應用的強一致性去中心化副本控制協議。

 

實例:

①GFS 系統的副本控制協議是典型的 Primary-Secondary 型協議,Primary 副本由 Master 指定,Primary 副本決定併發更新操作的順序。雖然在 GFS 中,更新操作的數據由客戶端提交,並在各個副本之間流式的傳輸,及由上一個副本傳遞到下一個副本,每個副本都即接受其他副本的更新,也向下更新另一個副本,但是數據的更新過程完全是由 primary 控制的,所以也可以認爲數據是由primary 副本同步到 secondary 副本的。

②Zookeeper 使用了基於 Paxos 的去中心化協議(後期分享)選出 primary 節點,但完成 primary節點的選舉後,這兩個系統都轉爲中心化的副本控制協議,即由 primary 節點負責同步更新操作到secondary 節點。

 

參考資料:《分佈式系統原理介紹》作者:劉傑

如有錯誤歡迎指正!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章