副本更新策略

分佈式理論系列

• 從ACID到CAP到BASE

• 2PC到3PC到Paxos到Raft到ISR

• 複製、分片和路由

• 副本更新策略

• 負載均衡算法及手段

• RWN及Quorum與強一致性

序

本文主要摘要了一些主要的副本更新策略。

一、同時更新

• 類型A：沒有任何協議，可能出現多個節點執行順序交叉致使數據不一致狀況。

• 類型B：經過一致性協議惟一肯定不一樣更新操做的執行順序，從而保證數據一致性

二、主從式更新

多個副本之間存在一個主副本（Master Replica），其餘副本爲從副本，這種稱爲主從更新策略。全部對數據的更新首先提交到主副本，再由主副本通知從副本進行數據更新。若是同時產生多個數據更新操做，由主副本決定不一樣更新操做的順序。

類型A：同步方式

主副本等待全部從副本更新完成以後才確認更新操做完成，這樣確保數據的強一致性，可是會存在較大的請求延時，尤爲是在多副本跨數據中心的情形下，由於請求延時取決於最慢的那個副本的更新速度。

類型B：異步方式

主副本在通知從副本更新以前便可確認更新操做。假設主副本尚未通知任何其餘從副本就發生崩潰，那麼數據一致性可能會出現問題，通常首先在另外的可靠存儲位置將此次更新操做記錄下來，以防這種狀況發生。

• 1）全部讀請求都經過主副原本響應，任意一個副本接收到讀請求後轉發爲主副本，能夠保證強一致，可是原本能夠由距離近的副本響應的操做又得轉發給距離較遠的主副本，增長了請求延時，Google的Chubby採用這種方式。

• 2）任意一個副本均可以響應讀請求，請求延時大大下降，可是可能致使讀不一致，由於有些副本可能還存在舊版本的數據，Zookeeper就是採用這種方法得到低延時，但犧牲了一致性。

類型C：混合方式

同步混合異步，主副本首先同步更新部分從副本，而後確認更新操做完成，其餘副本通關異步方式得到更新，Kafka就是採用這種混合方式來維護數據副本的不一致性。

• 1）讀操做至少要從一個同步更新的節點讀出，相似RWN協議的R+W>N，可保證強一致性，可是請求延時加大

• 2）讀操做不要求必定從至少一個同步更新節點讀出，那麼會出現類型B的第2種不一致性情形。

三、任意節點更新

不區分主從副本，任意節點均可以接收請求，而後又它去通知其餘副本進行更新。

類型A：同步通知其餘副本

存在和主從更新的類型A的狀況，除此以外，爲了識別出是否存在不一樣客戶端向不一樣副本發送對同一數據的更新操做，還須要額外付出更多的請求延時

類型B：異步通知其餘副本

存在主從更新的B方式問題。

Dynamo/Cassandra/Riak同時採起了主從式更新的類型C（同步+異步），以及任意節點更新的策略。

參考

• 大數據技術系列----副本更新策略