mysql两阶段提交

1二阶段提交协议

一般分为协调器C和若干事务执行者Si两种角色：

当执行某一事务T的所有站点Si都通知C事务执行完成，C即启动二阶段提交协议。

1.首先C向所有Si发<prepare>消息（C先将<prepare>消息写到本机日志），Si收到<prepare>消息后，根据本机T的执行情况，如果成功返回<readyT>，不成功返回<abortT>。（返回前都应把要返回的消息写到日志里）

2.C收集完所有Si的返回消息后（或经过一个超时周期后），如果都返回的是<readyT>，则事务成功，发送给所有站点<commitT>，否则事务失败发送<abortT>。发送前还是应把消息写到日志里。站点Si接收到C的<commitT>或<abortT>后先把消息写到日志里，然后再根据消息提交或回滚。

注：C或Si把发送或接收到的消息先写到日志里，主要是为了故障后恢复用。如某一Si从故障中恢复后，先检查本机的日志，如果已收到<commitT>，则提交，如果<abortT>则回滚。如果是<readyT>，则再向C询问一下，确定下一步。如果什么都没有，则很可能在<prepare>阶段Si就崩溃了，因此需要回滚。

二阶段提交的缺陷在于如果C崩溃，所有Si可能都需要等待C，从而产生阻塞。

2二阶段提交过程

第一阶段：

首先，协调者在自身节点的日志中写入一条的日志记录，然后所有参与者发送消息prepareT，询问这些参与者（包括自身），是否能够提交这个事务；

参与者在接受到这个prepareT消息以后，会根据自身的情况，进行事务的预处理，如果参与者能够提交该事务，则会将日志写入磁盘，并返回给协调者一个readyT信息，同时自身进入预提交状态状态；如果不能提交该事务，则记录日志，并返回一个notcommitT信息给协调者，同时撤销在自身上所做的数据库改；

参与者能够推迟发送响应的时间，但最终还是需要发送的。

第二阶段：

协调者会收集所有参与者的意见，如果收到参与者发来的notcommitT信息，则标识着该事务不能提交，协调者会将AbortT记录到日志中，并向所有参与者发送一个AbortT信息，让所有参与者撤销在自身上所有的预操作；

如果协调者收到所有参与者发来prepareT信息，那么协调者会将CommitT日志写入磁盘，并向所有参与者发送一个CommitT信息，提交该事务。若协调者迟迟未收到某个参与者发来的信息，则认为该参与者发送了一个VOTE_ABORT信息，从而取消该事务的执行。

参与者接收到协调者发来的AbortT信息以后，参与者会终止提交，并将AbortT记录到日志中；如果参与者收到的是CommitT信息，则会将事务进行提交，并写入记录。

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