数据引擎-Paxos分布式一致协议

分布式文件系统采用多分副本保证高可用性，举个例子：三副本，在更新的时候，确保二个副本持续化存储更新后，认为更新事物提交完成。那么如何确保多个副本的更新操作序列，在全部副本中依次顺序执行呢？

Paxos协议设计用来对数据副本的更新序列达成一致。Google的Chubby粗粒度锁服务是业界第一个对Paxos协议的完整实现，阿里云的盘古分布文件系统也采用Paxos协议，大名鼎鼎的Zookeeper采用Paxos的变种Zab协议。Paxos问题的描述：在系统内部有多个Acceptor负责存储和管理var变量；在系统外部有多个Proposer任意并发向系统提交不同的var取值，var取值一旦确定不可修改。

单Acceptor的互斥锁设计

单个Acceptor的设计，通过互斥访问权限来管理并发的Proposer运行。Proposer先向Acceptor申请访问权，没有得到访问权的返回Error，获取访问权的得到f的值，如果f的值空也就是还没赋值，就提交自己的值给Accept(var, V)，如果发现f已经赋值了直接释放访问权Release()。这个设计的问题是如果Proposer在释放访问权前发生故障，容易导致死锁。

单Acceptor的强占锁设计

引入强占式的访问权限，Proposer申请Acceptor访问权的时候指定编号epoch。epoch的编号越大越新。Acceptor采用喜新厌旧的策略，一旦收到更大的epoch编号，就放弃小的访问权，不接受他们提交的值。同时用后者认同前者的策略来保证一致性，如果小的epoch没有更新值，大的epoch可以提交自己的值，但是小的epoch已经提交了值，大的epoch选择认同。这个设计存在单点Acceptor的故障问题。

多Acceptor的强占锁设计

引入多个Acceptor，采用少数服从多数的策略，当epoch的取值被半数以上acceptor接收，才认可更新值，否则不更改。Proposer的epoch获取半数以上的Acceptor的访问权和取值，用后者认同前者的策略，获得var取值，如果var是空，向epoch对于的所有Acceptor提交更新值，如果收到半数以上成功，返回OK否则返回Error。