2PC两阶段提交协议
参考文章:https://blog.csdn.net/xj15010735572/article/details/86233456
背景:
在项目中开启了分布式事务,底层代码通过Dblink跨库连接,出现报错ORA-01591:lock heid bu in-dounbt distrbuted transaction 3.23.3578716;
通过了解是因为Oracle是使用2pc二阶段提交,只要是分布式事务就有可能出现这个报错,可以通过减少使用Dblink来减少这个问题的出现
这种问题理论上出现的概率是非常少的，由于分布式事务彼此不知道对方状态（相当于集群中的脑裂,所以当出现这个问题的时候必须要人工介入
一、先来认识分布式系统和分布式一致性问题
分布式系统，即运行在多台不同的网络计算机上的软硬件系统，并且仅通过消息传递来进行通信和协调。
分布式一致性问题，即相互独立的节点之间如何就一项决议达成一致的问题。
二、再来学习什么是2PC提交协议
2PC(Two-Phase Commit 二阶段提交）二阶段提交，是指将事务提交分成两个部分：准备阶段和提交阶段。事务的发起者称之为协调者，事务的执行者称为参与者。
阶段一：准备阶段
由协调者发起并传递带有事务信息的请求给各个参与者，询问是否可以提交事务，并等待返回结果。
个参与者执行事务操作，将Undo和Redo放入事务日志中（但是不提交）
如果参与者执行成功就返回YES（可以提交事务），失败NO(不能提交事务)
阶段二：提交阶段
此阶段分两种情况：所有参与者均返回YES，有任何一个参与者返回NO
所有参与者均反馈YES时，即提交事务。
任何一个参与者反馈NO时，即中断事务。
提交事务：（所有参与者均反馈YES）
1、协调者向所有参与者发出正式提交事务的请求（即Commit请求）。
2、参与者执行Commit请求，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。
中断事务：（任何一个参与者反馈NO）
1、协调者向所有参与者发出回滚请求（即Rollback请求）。
2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。
2PC的缺陷
1、同步阻塞：最大的问题即同步阻塞，即：所有参与事务的逻辑均处于阻塞状态。
2、单点：协调者存在单点问题，如果协调者出现故障，参与者将一直处于锁定状态。
3、脑裂：在阶段2中，如果只有部分参与者接收并执行了Commit请求，会导致节点数据不一致。
由于2PC存在如上同步阻塞、单点、脑裂问题，因此又出现了2PC的改进方案，即3PC。参考的文章中也做了3PC的介绍