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

文章首發於公衆號：松花皮蛋的黑板報
做者就任於京東,在穩定性保障、敏捷開發、高級JAVA、微服務架構有深刻的理解

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

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

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

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

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

(1)、主節點和從節點之間的數據同步如何實現？方式是同步仍是異步？
(2)、從節點可否提供數據讀取數據，若是容許，如何保證客戶端不會讀取到重複或者過期的數據？
(3)、主節點的選舉機制是怎麼樣的？

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

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

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

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

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

鏈式的意思是數據從一個節點推送到相鄰最近的節點，最近節點能夠用節點間心跳TTL來衡量，TTL表示IP數據包在計算機網絡中能夠轉發的最大跳數。這種方式的數據可以充分利用網絡資源，各個節點的壓力都很是均衡，可是須要通過多個節點，寫入延遲大，因此通常不採用這種方式，更多選用下面要說的主從模式。

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

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

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

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

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

鍵值對存儲數據庫Redis採起的就是上級指定方式，Redis集羣中有一個哨兵節點，它與主從節點保持固定心跳，在超時時間內聯繫不到主節點，則斷定主節點爲異常狀態，而後將主節點中的一個從節點提高爲新的主節點。另一種民主選舉的方式使用的是共識算法，就是多個節點對某個節點是否成爲新節點這個事情達到一致的見解，不論是主節點是真的異常，仍是網絡問題致使誤覺得主節點異常了。顯然，民主選舉須要保證在一個選舉週期內不會出現多個主節點，好比消息引擎Kafka約定序列號最大的那個纔是真正的主節點。

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

文章來源：www.liangsonghua.me

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