这篇文章主要介绍“数据库分布式事务的两段式和三段式有哪些区别”，在日常操作中，相信很多人在数据库分布式事务的两段式和三段式有哪些区别问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”数据库分布式事务的两段式和三段式有哪些区别”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
CAP
C代表一致性（Consistency），A代表可用性（Availability），P代表分区容错性（Partition Tolerance）。
一致性：对某个指定的客户端来说，读操作保证能返回最新的写操作结果。
可用性：非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。（只有非故障节点才能满足业务正常；只有在合理的时间内，用户才能接受；只有返回合理的响应，用户才能接受）。
分区容错性：当出现网络分区后，系统能够继续“履行职责”。（定义中的网络分区出现的情况有很多，比如丢包、连接中断、拥塞。
定义中的履行职责代表系统能够返回合理的响应。）
一、两段式
1、请求阶段（commit-request phase，或称表决阶段，voting phase）
事务询问。协调者向所有参与者发送事务内容，询问是否可以进行事务提交操作，然后就开始等待参与者的响应。
执行事务。各参与者节点执行事务操作（本地事务），并将Undo和Redo信息记入事务日志中。
各参与者向协调者反馈事务询问的响应。同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
2、提交阶段（commit phase）
在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。
当且仅当所有的参与者同意提交，事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者回滚事务。
两段式的缺点
1、同步阻塞问题。
执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2、单点故障
当协调者出错，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。
3、
第二阶段当协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了，那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
4、数据不一致
在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求，而在这部分参与者接到commit请求之后就会执行commit操作，但是其他部分未接到commit请求的机器则无法执行事务提交，于是整个分布式系统便出现了数据局部不一致性的现象。
二、三段式
1、CanCommit
事务询问。
各参与者向协调这反馈事务询问的响应。
2、PreCommit
假设协调者从所有的参与者获得的都是Yes响应，那么将执行事务预提交。执行事务操作，将Undo和Redo信息记录到事务日志中。
假设任何一个参与者向协调者反馈了No反应，或者在等待超时之后，协调者无法获得所有参与者的响应，那么将执行事务的中断。
3、doCommit
该阶段将进行事务提交，或者事务回滚。
三段式和两段式的区别
对于协调者(Coordinator)和参与者(Cohort)都设置了超时机制；
降低了参与者的阻塞范围，两段式在第一阶段就阻塞，而三段式在第二阶段阻塞；
解决了单点阻塞问题，因为一旦参与者无法及时收到来自协调者的信息之后，他会由于超时而默认执行commit。但如果协调者发送的是abort，而其中一个参与者因为网络问题没有收到，最终执行了commit，就会导致这个参与者与其他执行了abort的参与者数据不一致。
（使得原先在两阶段提交中，参与者在投票之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。也就是说，即使当协调者发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了，仍可以知道目前至少是处于准备通过提案阶段，表示第一阶段大家都已经决定要通过了，此时便可以直接通过。（也就是第一阶段的预通知起到了保障的作用））
