本篇内容介绍了“数据库的2PC与3PC是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
站在用户的角度思考问题，与客户深入沟通，找到伽师网站设计与伽师网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：成都网站制作、成都做网站、企业官网、英文网站、手机端网站、网站推广、域名申请、虚拟主机、企业邮箱。业务覆盖伽师地区。
数据库事务有ACID四大特性，分布式事务从实质看也要满足事务的基本特性（ACID）,只是分布式事务相对于本地事务而言其表现形式有很大不同。
2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。用于解决分布式事务一致性的问题。
常用的Oracle及MySQL就支持2PC协议，2PC协议的二个阶段如下：
准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。 （Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数据文件）
提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。
准备阶段：
事务管理器进行事务询问。事务管理器（协调者）向数据库参与者发送事务内容，询问是否可以执行事务提交操作，并等待参与者响应。
参与者执行事务。（写本地的Undo、Redo日志）
参与者反馈询问的响应
提交阶段：
事务管理器发送提交（commit）请求。
参与者正式提交事务，并释放整个事务执行期间占用的事务资源。
参与者反馈事务提交结果，发送ACK消息。
事务管理器收到所有参与者反馈的ACK消息后，完成事务
准备阶段与成功执行的步骤一样：
事务管理器进行事务询问，事务管理器（协调者）向数据库参与者发送事务内容，询问是否可以执行事务提交操作，并等待参与者响应。
参与者执行事务。（写本地的Undo、Redo日志）
参与者反馈询问的响应
提交阶段：
事务管理器发送回滚（Rollback）请求，当收到参与者执行失败或超时消息时。
参与者接收到Rollback请求后，利用准备阶段记录的Undo日志进行事务回滚操作，并释放整个事务执行期间占用的事务资源。
参与者反馈事务提交结果。参与者在完成事务回滚之后，向协调者发送 Ack 信息。
协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。
优点：原理简单，便于实现。
缺点：
同步阻塞
在2PC协议的执行（commit）过程中，所有参与该事务操作的数据库参与者都处于阻塞状态，即各个参与者在等待其他参与者响应的过程中，无法进行其他操作。
单点问题
事务管理器在提交（commit）阶段中非常重要，如果此时宕机，所有数据库参与者处于一直锁定数据库资源的过程中。
数据不一致 事务管理器在提交（commit）阶段向部分数据库参与者发送了commit命令，部分参与者没有发送，此时又宕机了，便只有部分数据库参与者更新了数据，出现数据不一致的情况。
过于保守 务管理器在提交（commit）阶段没有设计较为完善的容错机制，任意一个节点失败都会导致整个事务的失败。
3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求Prepare” 过程一分为二（CanCommit、PreCommit），共形成了由 CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。
1） 协调者进行事务询问
协调者向所有的参与者发送一个包含事务内容的CanCommit请求，询问是否可以执行事务提交操作，并开始等待 各参与者的响应。
2） 参与者向协调者反馈事务询问
参与者在接收到来自协调者的包含了事务内容的CanCommit请求后，正常情况下，如果自身认为可以顺利执行事 务，则反馈Yes响应，并进入预备状态，否则反馈No响应。
协调者在得到所有参与者的响应之后，参与者在CanCommit反馈的是Yes，执行事务预提交：
1）协调者发送预提交请求（发出preCommit请求，并进入prepared阶段）
2）参与者进行事务预提交（参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。）
3）各参与者向协调者反馈事务执行的结果（若参与者成功执行了事务操作，那么反馈Ack）
协调者在得到所有参与者的响应之后，参与者在CanCommit反馈的是No，中断事务：
1）协调者发送中断请求：（协调者向所有参与者发出abort请求。）
2）中断事务（无论是收到来自协调者的abort请求或者等待协调者请求过程中超时，参与者都会中断事务）
DoCommit阶段完成真正的事务提交或者完成事务回滚。
在第二阶段PreCommit阶段收到ACK确认消息，则完成事务提交：
1）协调者发送提交DoCommit请求（协调者将从预提交状态转化为提交状态，并向所有的参与者发送doCommit请求）
2）参与者进行事务提交（参与者接收到DoCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事务资源。）
3）各参与者向协调者反馈事务提交的结果（若参与者成功完成事务提交，那么反馈Ack响应）
4）完成事务（协调者接收到所有参与者反馈的Ack消息后，完成事务。）
在第二阶段PreCommit阶段超时中断没有收到ACK确认消息，则完成事务中断：
1）协调者发送中断请求（协调者向所有的参与者节点发送abort请求）
2）参与者进行事务回滚（根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整个事务执行期间占用的资源）
3）各参与者向协调者反馈事务回滚的结果（参与者在完成事务回滚后，向协调者发送Ack消息。）
4）中断事务（协调者接收到所有参与者反馈的Ack消息后，中断事务。）
注意：在DoCommit阶段可能出现协调者宕机、协调者与参与者出现网络故障；导致参与者接收不到协调者的DoCommit请求或Abort请求，参与者会在请求超时后，继续进行事务提交。
2PC中只有协调者有超时机制（在一定时间内没有收到参与者的消息则默认失败）；3PC中协调者及参与都设置了超时机制（参与者自身拥有超时机制，在超时后会自动进行本地commit从而进行释放资源，防止2PC出现的同步阻塞问题）
3PC相对于2PC多设置了一个缓冲阶段（PreCommit），保证在最后一个阶段DoCommit前，各个参与者节点状态是一致的
“数据库的2PC与3PC是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！
