18c分布式事务 oracle_Oracle分布式事务和两阶段提交(2PC)

分布式事务是指发生在多台数据库之间的事务，Oracle中通过dblink方式进行事务处理，分布式事务比单机事务要复杂的多。大部分的关系型数据库通过两阶段提交(2 Phase Commit 2PC)算法来完成分布式事务，下面重点介绍下2PC算法。

1、分布式事务的组成

在分布式事务中，主要有以下几个组成部分：

Client：调用其它数据库信息的节点

Database：接受来自其它节点请求的节点

Global Coordinator (GC)：发起分布式事务的节点

Local Coordinator (LC)：处理本地事务，并和其它节点通信的节点

Commit Point Site (CPS)：被Global Coordinator指定首先提交或回滚事务的节点

在分布式事务中，Commit Point Site非常重要，它不需要进入2PC的Prepared 状态，因为它通常操作最关键数据，所以它不会出现in-doubt状态。Commit Point Site总是优先于其它数据库节点先提交，目的在于保护最关键的数据，它决定整个分布式事务是提交还是回滚。分布式事务中其它数据库节点在GC的指挥下进行后续的提交(或回滚)。

那么在Oracle中如何选取Commit Point Site呢？它是根据参数commi_ point_strength 最大的数据库作为Commit Point Site。

2、两阶段提交(2PC)

两阶段提交协议可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者，并决定提交或取消(回滚)的分布式算法。同时也是解决一致性问题的算法。该算法能够解决很多的临时性系统故障(包括进程、网络节点、通信等故障)，被广泛地使用。但是，它并不能够通过配置来解决所有的故障，在某些情况下它还需要人为的参与才能解决问题。

顾名思义，两阶段提交分为以下两个阶段：

1)Prepare Phase (准备节点)

2)Commit Phase (提交阶段)

1)Prepare Phase

在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意(事务参与者本地作业执行成功)或取消(本地作业执行故障)。

为了完成准准备阶段，除了commit point site外，其它的数据库节点按照以下步骤执行：

每个节点检查自己是否被其它节点所引用，如果有，就通知这些节点准备提交(进入 Prepare阶段)。

每个节点检查自己运行的事务，如果发现本地运行的事务没有修改数据的操作(只读)，则跳过后面的步骤，直接返回一个read only给全局协调器。

如果事务需要修改数据，则为事务分配相应的资源用于保证修改的正常进行。

当上面的工作都成功后，给全局协调器返回准备就绪的信息，反之，则返回失败的信息。

2) Commit Phase

在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。

提交阶段按下面的步骤进行：

全局协调器通知 commit point site 进行提交。

commit point site 提交，完成后通知全局协调器。

全局协调器通知其它节点进行提交。

其它节点各自提交本地事务，完成后释放锁和资源。

其它节点通知全局协调器提交完成。

3)结束阶段

全局协调器通知commit point site说所有节点提交完成。

commit point site数据库释放和事务相关的所有资源，然后通知全局协调器。

全局协调器释放自己持有的资源。

分布式事务结束

一般情况下，两阶段提交机制都能较好的运行，当在事务进行过程中，有参与者宕机时，重启以后，可以通过询问其他参与者或者协调者，从而知道这个事务到底提交了没有。当然，这一切的前提都是各个参与者在进行每一步操作时，都会事先写入日志。

唯一一个两阶段提交不能解决的困境是：当协调者在发出commit 消息后宕机，而唯一收到这条命令的一个参与者也宕机了，这个时候这个事务就处于一个未知的状态，没有人知道这个事务到底是提交了还是未提交，从而需要数据库管理员的介入，防止数据库进入一个不一致的状态。当然，如果有一个前提是：所有节点或者网络的异常最终都会恢复，那么这个问题就不存在了，协调者和参与者最终会重启，其他节点也最终会收到commit 的信息。这也符合CAP理论。