|
|
|
两阶段提交协议（Two Phase Commitment Protocol，2PC）既简单又精巧，它把本地原子性提交行为的效果扩展到分布式事务，保证了分布式事务提交的原子性，并在不损坏日志的情况下，实现快速故障恢复，提高分布式数据库系统的可靠性。
|
|
|
|
在两阶段提交协议中，把分布式事务的某一个代理指定为协调者（Coordinator），所有其他代理称为参与者（Participant）。这里的代理是指完成各个子事务的进程。只有协调者才拥有提交或撤销事务的决定权，而其他参与者各自负责在其本地数据库中执行写操作，并向协调者提出撤销或提交事务的意向。一般一个站点唯一地对应一个子事务，如果某一参与者与协调者在同一站点，虽然它们不需要使用网络来通信，但仍逻辑地认为它与协调者不在同一站点。下图描述了协调者和参与者的关系。
|
|
|
|
|
|
|
|
2PC保证分布式事务提交的原子性，这是通过在分布式事务的结果生效以前，所有参与执行分布式事务的站点都同意提交而做到这一点的。这种同步的必要性有很多理由，如果某个事务正在读一项由另一个还未提交的事务更新的数据项的值时，相应的参与者就不会同意马上提交该事务。另一种参与者不同意提交的可能的原因是发生了死锁，这要求某一个参与者撤销事务。注意，参与者不需要任何其他进程来通知就可以撤销一个事务，这种能力相当重要，我们称之为单方面撤销。
|
|
|
|
2PC把事务的提交过程分为两个阶段：第一阶段是表决阶段，目的是形成一个共同的决定。开始时，协调者在它的日志中写入一条开始提交的记录，再给所有参与者发送“准备提交”消息，并进入等待状态。当参与者收到“准备提交”消息后，它检查是否能提交本地事务。如果能提交，参与者在日志中写入一条就绪记录，并给协调者发送“建议提交”消息，然后进入就绪状态：否则，参与者写入撤销记录，并给协调者发送“建议撤销”消息。如果某个站点做出“建议撤销”提议，由于撤销决定具有否决权（即单方面撤销），发出“建议撤销”的站点就可以直接忽略这个事务。协调者收到所有参与者的回答后，它就做出是否提交事务的决定。只要有一个参与者建议撤销，协调者就必须从整体上撤销整个分布式事务，因此它写入一条撤销记录，并给所有参与者发送“全局撤销”消息，然后进入撤销状态；否则，它写入提交记录，给所有的参与者发送“全局提交”消息，然后进入提交状态。
|
|
|
|
第二阶段是执行阶段，目的是实现这个协调者的决定。根据协调者的指令，参与者或者提交事务，或者撤销事务，并给协调者发送确认消息。此时，协调者在日志中写入一条事务结束记录并终止事务。上图描述了两阶段提交协议的参与者和协调者的交互。
|
|
|
|
请注意协调者做出事务的全局终止决定的方式，该决定受两条规则的支配，这两条规则称为全局提交规则：
|
|
|
|
（1）只要有一个参与者撤销事务，协调者就必须做出全局撤销决定。
|
|
|
|
（2）只有所有参与者都同意提交事务，协调者才能做出全局提交决定。
|
|
|
|
从下图中可以看出以下关于两阶段提交协议的一些重要之处：
|
|
|
|
|
|
|
|
（1）两阶段提交协议允许参与者可以单方面撤销事务。
|
|
|
|
（2）一旦参与者确定了提交或撤销提议，就不能再更改它的提议。
|
|
|
|
（3）当参与者处于就绪状态时，根据协调者发出的消息的种类参与者可以转换为提交状态或撤销状态。
|
|
|
|
|
|
（5）注意协调者和参与者可能进入某些相互等待对方发送消息的状态。为了确保它们能够从这些状态中退出并终止，要使用定时器。每个代理进程进入一个状态时都要设置超时器。如果所期待的消息在定时器超时之前没有到来，定时器向代理进程报警，进程根据超时协议执行相应动作。
|
|
|
