按某特定流程控制副本數據的讀寫行為，使副本滿足一定的可用性及一致性的分布式協議。 中心化副本控制協議： primary-secondary協議 只有一個副本作為主副本，其余都是從副本。主副本作為中心節點負責數據更新、控制協調一致性。 四大問題： 1. 寫 > 寫由主完成 > 外部寫請求發給主 > 主進行并發控制，即確定并發請求的先后順序 > 更新操作發給從節點 GFS采用接力方式傳遞數據，以控制出口帶寬。如果是最終一致性的系統，主從是可以不一致的，只需要后續慢慢同步到一致狀態。 Quorum:只需要完成W個副本的更新。 > 根據從節點完成情況，決定怎么返回給外部 2. 讀 最終一致：那隨便讀哪個副本 會話一致：在寫/更新時，設置副本版本號，讀時驗證版本號即可保證在會話內單調遞增 強一致性實現思路： 只讀主副本。這在副本以數據段為單位時，并不會浪費機器資源，因為各副本的主也是分散在各機器上的。 主節點控制：主節點在更新從節點的數據時，如果失敗標記其為不可用。使用一個中心元數據管理系統來記錄哪些不可用。外部查中心元數據確定哪個可用。 Quorum機制：除了只讀主，還可以按quorum中提及的，讀R個，取最高版本號，直到讀到W個副本。 3. 主副本確定及切換 切換要解決的無非兩個問題： a. 如何確定主節點異常？ lease機制。 b. 異常后應該切到哪個從節點？ 異常后強一致性的服務要求是目標從節點必須與原主節點的數據一致。這其實與強一致性下讀從節點是同一問題。可用Quorum機制，讀R個，取最高版本號，再同步至W個節點，造成最高版本號的數據已經寫了W份的結果，滿足quorum機制寫成功的要求。 primary-secondary協議的缺點就是主從切換時，會由于探測主節點異常存在時間窗口，而導致服務暫時不可用。 4. 數據同步 不一致的情況下，需要同步。不一致的情況主要有3種： 1. 網絡分化等導致從節點上數據落后于主節點數據； 回放主上日志 2. 從節點上是臟數據； 設計分布式協議以不產生從節點上臟數據 3. 從節點是新增節點。 設置快照，拷貝快照；再回放快照后的部分 例：GFS，PNUTS，Niobe， 去中心化副本控制協議： 沒有中心副本，各節點通過協商達到某種一致狀態，因此避免了primary-secondary協議中主從切換時帶來的停服務問題。 但流程復雜。paxos。 例：Dynamo/Cassandra一致性hash，一致性模型有問題，使應用使用復雜度上升。 Chubby/Zookeeper：基于類paxos，選中primary，隨后轉為primary-secondary控制協議。 Megastore：完全paxos，不轉為主從控制。

轉載于:https://www.cnblogs.com/qqmomery/p/5358271.html

總結

以上是生活随笔為你收集整理的分布式入门之3：副本控制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。