按某特定流程控制副本數據的讀寫行爲，使副本滿足一定的可用性及一致性的分佈式協議。
中心化副本控制協議：
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，不轉爲主從控制。
