分散式系統之中心化複製集管理

文章首發於公眾號 松花皮蛋的黑板報

為了避免分散式系統單點異常引發的系統可靠性和高可用問題，可行的辦法就是數據冗餘，也稱為複製集，那麼複製集是怎麼管理的呢？

實際上管理方式可以有去中心化副本集和中心化副本集兩種。

去中心化副本集的特點是，無中心節點，所有節點地位平等，都可以接受讀寫請求，通過協商達到數據的一致。這種方式可用性比較強，只要大多數節點存活就可以對外提供服務，缺點也很明顯，它的協議流程複雜。

中心化副本集的特點是，節點之間有主從邏輯關係，主節點負責所有請求的寫操作，從節點複製主節點的數據，從節點集的作用是當主節點異常時從中選舉出一個新的主節點。這種方式將複雜問題轉換成一個有成熟解決方案的問題，將分散式的併發操作轉換成單點併發，雖然邏輯變得簡單了，但是主節點異常後，即使有主節點切換機制，也會出現短暫的不可用。

目前來看，數據的分散式存儲普遍採用中心化副本集管理方式，那麼接下來我將介紹這種方式的三個關鍵點，如下：

(1)、主節點和從節點之間的數據同步如何實現？方式是同步還是非同步？
(2)、從節點能否提供數據讀取數據，如果允許，如何保證客戶端不會讀取到重覆或者過時的數據？
(3)、主節點的選舉機制是怎麼樣的？

首先來說說主從節點數據更新流程。

如果採用同步的方式進行同步數據的話，意味著對於客戶端請求，主節點一直阻塞該請求，直到將數據成功複製到所有的從節點，才能向客戶端返回。顯然，同步模式下，可靠性非常好，但是更新可用性非常差，只要有一個節點異常，就無法完成更新。而且，響應延遲比較大，取決於副本集中網路延遲最大、處理速度最慢的節點。

如果採用非同步的方式進行同步數據的話，它只需要保證客戶端寫請求在一個節點上完成就立即響應返回，這裡說的節點，通常是主節點，不過當寫請求完成而複製操作還沒開始時主節點異常，這將導致更新失效，關鍵在於客戶端以為已經成功了，它永遠不會重試剛剛的寫操作。另外，需要註意的是，非同步模式下的同步是弱一致性的，客戶端有可能讀取不到最新的數據。

在數據同步的時候不管選擇同步模式和非同步模式都有各自的優劣，那麼在技術方案評估時，選擇哪種方案，取決於系統對一致性、可用性、響應延遲的要求。

在主從節點數據同步的流程中，還有一個關鍵點需要交待清楚，數據同步路徑問題，這樣描述可能讓人摸不著頭腦，你可以理解為數據具體是怎麼流動的。通常有兩種方式，分別為鏈式和主從模式。

鏈式的意思是數據從一個節點推送到相鄰最近的節點，最近節點可以用節點間心跳TTL來衡量，TTL表示IP數據包在電腦網路中可以轉發的最大跳數。這種方式的數據能夠充分利用網路資源，各個節點的壓力都非常均衡，但是需要經過多個節點，寫入延遲大，所以一般不採用這種方式，更多選用下麵要說的主從模式。

主從模式是指數據從主節點同步到從節點，但是這個數據一般是操作事件數據，這樣通知到從節點後，從節點會從主節點根據事件描述拉取相應的數據，優點是寫入延遲小，缺點是主節點的壓力比較大。

前面有說到，在主從節點數據同步流程中，有可能部分節點會寫入失敗，那這種情況應該怎麼處理呢？

分散式存儲中的數據複製服務大多數是一種儘力而為的服務模型，不保證一定成功，針對同步失敗，依賴於具體系統的處理方案。比如可以約束向客戶端返回寫入成功的前提條件，包括數據是否寫入主節點、數據是否寫入一定數量的節點等等，然後採取相應的補償事務，最終保證數據的一致性。

前面花了很大的篇幅來闡述數據同步問題，接下來談談第二個關鍵點，也就是從節點是否也可以提供讀取數據的服務。個人覺得，從節點如果能提供對外服務的話可以很好發揮出數據的局部性，位置相近的請求來源的延遲可以更低，當然可能會出現同步不及時的數據不一致情形，如果系統不太關心及時性的話那就無傷大雅。

最後再來說說主節點選舉機制，新的主節點可以是上級指定也可以是民主選舉方式選出來的。

鍵值對存儲資料庫Redis採取的就是上級指定方式，Redis集群中有一個哨兵節點，它與主從節點保持固定心跳，在超時時間內聯繫不到主節點，則判定主節點為異常狀態，然後將主節點中的一個從節點提升為新的主節點。另外一種民主選舉的方式使用的是共識演算法，就是多個節點對某個節點是否成為新節點這個事情達到一致的看法，不管是主節點是真的異常，還是網路問題導致誤以為主節點異常了。顯然，民主選舉需要保證在一個選舉周期內不會出現多個主節點，比如消息引擎Kafka約定序列號最大的那個才是真正的主節點。

好，今天分享瞭如何理解分散式系統中的數據複製問題，希望能幫助到你，歡迎分享給你的朋友們。

文章來源：www.liangsonghua.me

作者介紹：京東資深工程師-梁松華，在穩定性保障、敏捷開發、JAVA高級、微服務架構方面有深入的理解