CAP、2PC和3PC

[luoxn28]

CAP定理

一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这3个基本需求，最多只能同时满足其中2项。

• 一致性 C：数据在多个副本之间保持一致的特性。
• 可用性 A：指系统提供的服务始终处于可用的状态，也就是能在有限的时间内返回结果。
• 分区容错性：出现网络分区情况下，系统仍能对外提供服务。（简单理解就是客户端在已经连上出现网络分析的服务器时，仍能通过它获取服务）

CAP不能同时满足，简单证明如下：在两台出现网络故障的机器A和B（二者之间无法正常通信），若该系统同时满足CAP定理，其中在A机器更新了数据data，此时从机器B上获取数据data，则获取的还是老数据，这样也就是无法满足CAP了，侧面说明了CAP不能同时满足。

2PC

2PC，2阶段提交协议，是为了使基于分布式架构下的所有节点在进行事务处理过程中能够保持原子性和一致性的一种算法。2PC中有2种角色，协调者和参与者。

2PC分为2个阶段：

• 准备阶段：协调者发起事务请求，参与者收到请求时进行事务操作（此时不进行commit），成功执行后返回YES，否则返回NO。
• 提交阶段：在收到所有参与者返回的YES后，协调者通知参与者进行commit，否则通知rollback。

2PC协议原理简单，实现方便，但是缺点是同步阻塞，单点问题，过于保守等。

• 同步阻塞：2PC执行过程中，所有参与者都处于阻塞状态，等待其他节点返回消息过程中，参与者无法处理其他事务操作。
• 单点问题：如果协调者挂了，则2PC就进行不下去了。
• 数据不一致：提交阶段时，如果有的参与者因为网络原因未收到commit，则在超时后进行rollback，此时会出现数据不一致。
• 过于保守：协调者因为网络原因无法获取所有参与者响应的话，只能依靠自身超时机制来中断事务请求。

3PC

3PC，就是将2PC中的阶段一再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。在第一阶段，只是询问所有参与者是否可可以执行事务操作，并不在本阶段执行事务操作。当协调者收到所有的参与者都返回YES时，在第二阶段才执行事务操作，然后在第三阶段在执行commit或者rollback。

3PC相对于2PC，大大降低了阻塞范围，并能在单点故障后达成一致，但是3PC也有问题，那就是如果参与者收到preCommit后出现网络故障，无法通信，如果协调者发出rollback，则出现网络故障的参与者最终会进行commit，此时出现了数据不一致问题。