按某特定流程控制副本数据的读写行为，使副本满足一定的可用性及一致性的分布式协议。
中心化副本控制协议：
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，不转为主从控制。