分布式事务

分布式事务

2pc

二阶段提交 协调者参与者 准备阶段 提交阶段 协调者引入超时机制

协调者向参与者发送准备命令，参与者接受者个命令会向协调者发送准备成功的命令，随即协调者发送提交的命令。

如果第一阶段有参与者发送失败的命令，那么协调者回向参与者发送回滚事务的请求，即分布式视为提交失败。

假如说第二阶段提交失败的情况，

如果第二阶段发送回滚的请求，不断重试，直到所有的参与者都进行了回滚

如果第二阶段发送的是提交的请求，不断重试，因为有一些参与者的事务已经提交成功，所以进行不断重试，直到所有事务提交成功，直到最后，进行人工介入。

协调者作为一个单点，会发生单点故障

如果说协调者在发送准备请求前挂掉，事务等于还是没有开始，不影响

如果说协调者在发送准备请求之后挂掉，有些参与者已经执行了处于资源被锁定的状态，这样事务不仅不能执行下去还因为资源被锁定而阻塞系统其他操作

如果说协调者在发送回滚命令前挂了，第一阶段的所有参与者阻塞者

如果说协调者在发送提交请求之前挂掉，所有的资源阻塞

如果说协调者在发送回滚命令之后挂掉，命令发送出去，有很大的概率被参与者接受

如果说协调者在发送提交请求之后挂掉，命令发送出去

协调者挂了，会通过选举出一个新的协调者如果处于第二阶段，假设参与者都没有挂，新的协调者会向所有的参与者来确认他们自身的情况来判断下一步的操作，但是假说说个别参与者挂了，比如协调者发送回滚命令，此时第一个参与者收到了并执行了，但是该参与者和协调者挂掉了，此时其他的参与者都没有收到命令，选举出来新的协调者询问其他参与者都OK，但是他不知道这个挂了的参与者到底什么情况，因为每个参与者的状态，只有他自身和协调者知道，但是新的协调披着不能根据在场的参与 者的状态推断出挂了的参与者是什么情况。

对于这种情况，我们可以让协调者将自己发过请求的地方记录以下，也就是日志记录的形式，这样新来的协调者就知道自己该怎么办

3pc

三阶段提交 在参与者也引入了超时机制 准备阶段 预提交阶段 提交阶段

首先准备阶段不会直接执行事务锁定资源，而是询问参与者是否有条件接受这个事务。

新增加的预提交阶段是为所有的参与者统一状态的作用，相当于一个屏障，如果一个参与者处于预提交状态，他便会知道所有的参与者都进入该状态。

参与者引入超时机制，参与者就不会 傻等了，如果是提交阶段超时，参与者就进行提交，如果是预提交阶段超时，参与者就该干什么干什么，反正本来也没有干什么。

但是超时机制会带来数据不一致的问题，如果说在等待提交阶段超时，参与者默认执行的是提交的事务的操作，但是有可能要执行的是回滚的操作。

TCC

2pc和3pc都是数据库层面的，而tcc是业务层面的分布式

三阶段操作：预留 确认 撤销

其实思想和2pc很相似，先试探执行的如果可以就进行确认不可以就撤销。

比如说对一个事务要执行ABC三个操作，先对ABC进行一个预留的操作，如果都成功就执行确认操作，如果有一个失败，那就执行撤销的操作。

TCC模型还有个事务管理者的角色，用来记录TCC全局事务状态并提交或者回滚事务。

确认和撤销的操作可能需要重试，因此还需要保证操作的幂等。

TCC可以跨数据库，跨不同的业务系统来实现事务。