分布式一致性算法

1. 什么是分布式一致性？

• 集群一致性：客户端在节点A上面更新数据，节点A需要更新节点B，更新完毕之后节点A再通知客户端已经更新完毕，使得数据保持一致。
• 事务一致性：客户端需要同时更新节点A和节点B的数据，例如下订单的时候要求同时减去库存，此时数据库分属于不同的节点，需要两边都更新，才能使得数据保持一致。可能的原因有节点出现故障，出现网络分区等。

2. 什么是2PC？

答：两阶段提交2PC，将操作划分为预操作，提交/回滚两个阶段。其中需要记录undo日志和redo日志。普通的数据库操作也是两阶段提交。两阶段提交的不足是第一阶段造成阻塞，可能是参与者的问题，也可能是协调者挂了，导致第一阶段锁着的参与者无法释放资源。此时需要人工干预。两阶段提交的另一个不足是第二阶段也会造成不一致，在回滚状态的参与者突然挂了，此时就会出现数据不一致的情况，此时需要人工干预。

第一阶段
第一阶段
第一阶段
第一阶段
第二阶段
第二阶段
第二阶段
信息流

3. 什么是3PC？

答：是对2PC的改进。参与者添加了等待时长，如果时间超过等待预期，则认为协调者挂了，自动回滚。3PC会出现数据不一致的情况在第二阶段，如果部分参与者回复preCommit失败，但是此时协调者挂了，则在超时之后其他回复preCommit成功的会自动commit，造成数据不一致。3PC的缺点在于设置超时时长，因为很难确认超时时长，所以市面上很少有使用3PC的应用。

信息流

4. 什么是Paxos？

答：可以不用人工干预，真正做到分布式一致性。背景是因为一个集群中的多个节点都可以接受写操作，然后扩散写操作的时候因为网络延迟问题，会造成某些节点更新快，某些节点更新满，这时候同时写入的两个写操作会造成集群最终不一致。Paxos的思路是为了减少leader选举所用的时间，只需要其中一部分节点进行参与投票的环节即可。

• Paxos写流程：当对于同一个有冲突的值进行更新，则只更新前面一个，丢弃后一个。所以Paxos算法严格保证了更新的顺序，必须前一个值更新完毕之后，才能更新后一个值。
• Paxos读流程：获取集群中大多数节点的值，以其值作为当前值。如果集群有100个，只有10个参与决策，则只需要获取这10个节点的值，其中大多数都同意为同一个值即可。
• Paxos难点：没有中心节点，所以提案号的生成是一个很大的问题。

• 请寻找Paxos算法的实现作为研究。

  
  可以使用leader的方式来解决
  Paxos
  Paxos
  Paxos写流程
  Paxos读流程

5. 其他基于Paxos的算法有哪些？

• ZAB，Zid由两部分组成，第一部分是朝代号，第二部分是事务号，朝代号是每一代的leader，如果重新选了一个leader，事务号从零开始递增。

  
  ZAB
  ZAB流程

• RAFT
  请参看官网