松花皮蛋的黑板報
  • 分享在京東工作的技術感悟,還有JAVA技術和業內最佳實踐,大部分都是務實的、能看懂的、可復現的

掃一掃
關注公眾號

分布式系統之中心化復制集管理

博客首頁文章列表 松花皮蛋me 2019-08-25 14:19

為了避免分布式系統單點異常引發的系統可靠性和高可用問題,可行的辦法就是數據冗余,也稱為復制集,那么復制集是怎么管理的呢?

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

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

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

目前來看,數據的分布式存儲普遍采用中心化副本集管理方式,那么接下來我將介紹這種方式的三個關鍵點,如下:

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

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

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

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

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

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

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

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

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

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

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

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

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

好,今天分享了如何理解分布式系統中的數據復制問題,希望能幫助到你,歡迎分享給你的朋友們。

黑龙江6+1开奖结果查询