谈谈对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命令并执行回滚的参与者之间存在数据不一致的情况。