分佈式系統設計(2)

3 副本

3.1 概念

副本（replica/copy）指在分佈式系統中爲數據或服務提供的冗餘。對於數據副本指在不一樣的節點上持久化同一份數據，當出現某一個節點的存儲的數據丟失時，能夠從副本上讀到數據。數據副本是分佈式系統解決數據丟失異常的惟一手段。另外一類副本是服務副本，指數個節點提供某種相同的服務，這種服務通常並不依賴於節點的本地存儲，其所需數據通常來自其餘節點。

3.2  基本副本協議

3.2.1  中心化副本控制協議

中心化副本控制協議的基本思路是由一箇中心節點協調副本數據的更新、維護副本之間的一致性。圖  2-7 給出了中心化副本協議的通用架構。中心化副本控制協議的優勢是協議相對較爲簡單，全部的副本相關的控制交由中心節點完成。併發控制將由中心節點完成，從而使得一個分佈式併發控制問題，簡化爲一個單機併發控制問題。所謂併發控制，即多個節點同時須要修改副本數據時，須要解決「寫寫」、「讀寫」等併發衝突。單機系統上經常使用加鎖等方式進行併發控制。對於分佈式併發控制，加鎖也是一個經常使用的方法，但若是沒有中心節點統一進行鎖管理，就須要徹底分佈式化的鎖系統，會使得協議很是複雜。中心化副本控制協議的缺點是系統的可用性依賴於中心化節點，當中心節點異常或與中心節點通訊中斷時，系統將失去某些服務（一般至少失去更新服務），因此中心化副本控制協議的缺點正是存在必定的停服務時間。

 

3.2.2  primary-secondary 協議

在 primary-secondary 類型的協議中，副本被分爲兩大類，其中有且僅有一個副本做爲 primary 副本，除 primary 之外的副本都做爲 secondary 副本。維護 primary 副本的節點做爲中心節點，中心節點負責維護數據的更新、併發控制、協調副本的一致性。

Primary-secondary 類型的協議通常要解決四大類問題：數據更新流程、數據讀取方式、Primary副本的肯定和切換、數據同步（reconcile）。

數據更新基本流程

Primary-secondary 協議的數據更新流程

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

2.  外部節點將更新操做發給 primary 節點

3.  primary 節點進行併發控制即肯定併發更新操做的前後順序

4.  primary 節點將更新操做發送給 secondary 節點

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

其中第 4 步 primary 節點將更新操做發送到 secondary 節點時，每每發送的也是更新的數據。在工程實踐中，若是由 primary 直接同時發送給其餘 N 個副本發送數據，則每一個secondary 的更新吞吐受限於 primary 總的出口網絡帶寬，最大爲 primary 網絡出口帶寬的 1/N。爲了解決這個問題，有些系統（例如，GFS），使用接力的方式同步數據，即 primary 將更新發送給第一個 secondary 副本，第一個 secondary 副本發送給第二 secondary 副本，依次類推。因爲異常，第 4步可能在有些副本上成功，有些副本上失敗，在有些副本上超時。不一樣的副本控制協議對於第 4 步異常的處理都不同。

數據讀取方式

數據讀取方式是 primary-secondary 類協議須要解決的第二個問題。與數據更新流程相似，讀取方式也與一致性高度相關。若是隻須要最終一致性，則讀取任何副本均可以知足需求。若是須要會話一致性，則能夠爲副本設置版本號，每次更新後遞增版本號，用戶讀取副本時驗證版本號，從而保證用戶讀到的數據在會話範圍內單調遞增。使用 primary-secondary 比較困難的是實現強一致性。

這裏簡單討論 primary-secondary 實現強一致性的幾種思路。

第1、因爲數據的更新流程都是由 primary 控制的，primary 副本上的數據必定是最新的，因此若是始終只讀 primary 副本的數據，可以實現強一致性。

第2、由 primary 控制節點 secondary 節點的可用性。當 primary 更新某個 secondary 副本不成功時，primary 將該 secondary 副本標記爲不可用，從而用戶再也不讀取該不可用的副本。不可用的secondary 副本能夠繼續嘗試與 primary 同步數據，當與 primary 完成數據同步後，primary 能夠副本標記爲可用。這種方式使得全部的可用的副本，不管是 primary 仍是 secondary 都是可讀的，且在一個肯定的時間內，某 secondary 副本要麼更新到與 primary 一致的最新狀態，要麼被標記爲不可用，從而符合較高的一致性要求。這種方式依賴於一箇中心元數據管理系統，用於記錄哪些副本可用，哪些副本不可用。某種意義上，該方式經過下降系統的可用性來提升系統的一致性。

第3、基於 Quorum 機制，後面詳細說quorum機制。

primary 副本的肯定與切換

在 primary-secondary 類型的協議中，另外一個核心的問題是如何肯定 primary 副本，尤爲是在原primary 副本所在機器出現宕機等異常時，須要有某種機制切換 primary 副本，使得某個 secondary副本成爲新的 primary 副本。

這邊提出兩個問題：

第1、如何肯定節點的狀態以發現原 primary 節點異常

第2、切換 primary後，不能影響副本的一致性。尤爲是提供較強一致性服務的系統，切換 primary 的影響更是須要控制。要達到這個目的，一種直觀的方式是切換的新 primary 的副本數據必須與原 primary 的副本一致。然而在原 primary 已經發送宕機等異常時，如何肯定一個 secondary 副本使得該副本上的數據與原primary 一致又成爲新的問題。

數據同步

Primary-secondary 型協議通常都會遇到 secondary 副本與 primary 不一致的問題。此時，不一致的 secondary 副本須要與 primary 進行同步（reconcile）。

一般不一致的形式有三種：1、因爲網絡分化等異常，secondary 上的數據落後於 primary 上的數據。2、在某些協議下，secondary 上的數據有多是髒數據，須要被丟棄。所謂髒數據是因爲primary 副本沒有進行某一更新操做，而 secondary 副本上反而進行的多餘的修改操做，從而形成secondary 副本數據錯誤。3、secondary 是一個新增長的副本，徹底沒有數據，須要從其餘副本上拷貝數據。

對於第一種 secondary 數據落後的狀況，常見的同步方式是回放 primary 上的操做日誌（一般是redo 日誌），從而追上 primary 的更新進度。對於髒數據的狀況，較好的作法是設計的分佈式協議不產生髒數據。若是協議必定有產生髒數據的可能，則也應該使得產生髒數據的機率降到很是低得狀況，從而一旦發生髒數據的狀況能夠簡單的直接丟棄有髒數據的

副本，這樣至關於副本沒有數據。另外，也能夠設計一些基於 undo 日誌的方式從而能夠刪除髒數據。若是 secondary 副本徹底沒有數據，則常見的作法是直接拷貝 primary 副本的數據，這種方法每每比回放日誌追更新進度的方法快不少。但拷貝數據時 primary 副本須要可以繼續提供更新服務，這就要求 primary 副本支持快照(snapshot)功能。即對某一刻的副本數據造成快照，而後拷貝快照，拷貝完成後使用回放日誌的方式追快照造成後的更新操做。

3.2.3 去中心化副本控制協議

去中心化副本控制是另外一類較爲複雜的副本控制協議。與中心化副本系統協議最大的不一樣是，去中心化副本控制協議沒有中心節點，協議中全部的節點都是徹底對等的，節點之間經過平等協商達到一致。從而去中心化協議沒有由於中心化節點異常而帶來的停服務等問題。

然而，沒有什麼事情是完美的，去中心化協議的最大的缺點是協議過程一般比較複雜。尤爲當去中心化協議須要實現強一致性時，協議流程變得複雜且不容易理解。因爲流程的複雜，去中心化協議的效率或者性能通常也較中心化協議低。一個不恰當的比方就是，中心化副本控制協議相似專制制度，系統效率高但高度依賴於中心節點，一旦中心節點異常，系統受到的影響較大；去中心化副本控制協議相似民主制度，節點集體協商，效率低下，但個別節點的異常不會對系統整體形成太大影響。

3.3 工程中的應用

GFS

GFS 系統的副本控制協議是典型的 Primary-Secondary 型協議，Primary 副本由 Master 指定，Primary 副本決定併發更新操做的順序。雖然在 GFS 中，更新操做的數據由客戶端提交，並在各個副本之間流式的傳輸，及由上一個副本傳遞到下一個副本，每一個副本都即接受其餘副本的更新，也向下更新另外一個副本，可是數據的更新過程徹底是由 primary 控制的，因此也能夠認爲數據是由primary 副本同步到 secondary 副本的

Chubby/Zookeeper

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