谈谈对2pc和3pc一致性算法的理解

自我总结，表达的不太清楚。若是须要了解的朋友请直接阅读参考http://www.hollischuang.com/archives/681#rd?sukey=3997c0719f1515205acb269da14295ad50b0186483fbd0a402a566f45b33525978b375ccc44dba3e85c4d645a320ba47

单机事务

---

何为事务？是指做为单个逻辑工做单元执行的一系列操做，要么彻底地执行，要么彻底地不执行。一个事务须要知足ACID即原子性、一致性、隔离性、持久性。

分布式事务

---

在单机状况下事务很容易知足，若是一个逻辑工做单元执行的一系列操做跨越了多台机器如何处理，多台机器相互之间又怎么知道对方成功了仍是失败了。解决分布式事务的关键就是必须有一种方法可以知道事务在任何地方所作的任何动做，提交或者回滚的决定必须产生统一的结果。

XA规范

---

Open Group定义了一套DTP分布式模型，主要含有AP（应用程序）,TM（事务管理器）,RM（资源管理器）,CRM（通信资源管理器）四部分。常规下RM通常指的就是数据库，CRM主要有各类各样的消息中间件来实现。

XA则是DTP模型定义TM和RM以前通信的接口规范。XA接口函数由数据库厂商提供。TM交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。

二阶段提交和三阶段提交就是根据这种思想衍生而来。

2pc & 3pc

---

2pc

主要分两两个阶段

第一阶段：协调者询问参与者是否能够提交事务。若是参与者事务操做执行成功则回复yes,反之no

第二阶段：参与者都回复yes,协调者发出提交请求，则参与者收到后开始提交事务并释放相关资源。反之参与者则事务回滚并释放资源

可能出现的问题

第二阶段的时候，假如其中一个参与者收到了do commit命令而后它提交了事务，可是另一个参与者可能由于网络问题或者协调者挂掉了，致使一直苦苦等待一直占用资源，另外致使数据不一致

另外假如协调者是集群，若是协调者在发出一个commit指令的时候宕机了，而后恰好一个接受到该命令的参与者也宕机了，等选举出新的协调者的时候，没法知道如今事务的状态

3pc

主要分三个阶段

第一阶段协调者询问参与者是否能够执行事务，参与者就分析自身是否可以成功执行事务操做，能够则返回yes,不然no

第二阶段参与者收到后则开始执行事务操做，执行成功后反馈yes给协调者反之no

第三阶段协调者根据参与者的反馈选择发起abort或者commit命令

改进点

增长了超时机制

第二阶段，若是协调者超时没有接受到参与者的反馈，则自动认为失败，发送abort命令

第三阶段，若是参与者超时没有接受到协调者的反馈，则自动认为成功开始提交事务（基于几率）

2PC与3PC的区别

相对于2PC，3PC主要解决的单点故障问题，并减小阻塞，由于一旦参与者没法及时收到来自协调者的信息以后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。可是这种机制也会致使数据一致性问题，由于，因为网络缘由，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时以后执行了commit操做。这样就和其余接到abort命令并执行回滚的参与者之间存在数据不一致的状况。