分布式事务详解

摘要

分布式事务主要包括2pc、3pc、消息事务。

• 2pc指两阶段提交：
  • 第一阶段是准备阶段：所有事务参与者检查执行能力并锁定对应资源，准备完成后将状态告知协调者。
  • 第二集段是提交状态：事务参与者全部准备好后，协调者发起提交请求，通知参与者提交事物。若存在参与者准备失败，则回滚。

•   2pc的具体实现有AT、XA、TCC、Sata。
  

• 3pc指事物分为3个阶段：
  • 第一阶段为尝试阶段：所有参与者检查自己是否有执行事物的能力，并将状态告知给协调者。
  • 第二阶段为准备阶段：协调者确认所有参与者均有执行事物的能力后，再发起请求，锁定资源；
  • 第三阶段为提交阶段：所有参与者锁定成功后，协调者发起提交请求，提交事物。

•   3pc解决了2pc一阶段资源无效锁定的问题。
  

• 消息事务是使用消息队列作为中间件实现的分布式事务。也分为两个阶段：
  • 第一阶段为半事务消息阶段：此时发起方发送半事务消息给消息队列。
  • 第二阶段为确认阶段：发起方执行本地事务完成后，确认半事务消息，此时下游消费者就可消费事物消息，并执行对应的事务了。

•   消息事务是最终一致性方案。总之，分布式事务没有最好的方案，需要根据场景选择最合适的方案。
  

一、2PC（两阶段提交）

成员类型包括事务参与者和事务协调者，分为准备-提交/撤销两个阶段。

1. 准备阶段：参与者锁定事务所需要执行的资源，并将成功或者失败状态返回给事务协调器；
2. 提交/撤销阶段：事务协调器收到全部参与者的响应后，发起事务提交命令，然后，所有参会者提交事务；若存在参与者准备阶段失败，则发起撤销命令，所有参与者回滚。

缺点：

1. 事务存在同步阻塞的问题；因为事务协调器需要等待全部参与者均返回响应后，才执行提交/回滚操作；
2. 第一阶段锁定资源，可能会造成资源浪费；因为有些事务在大部分参与者上能执行，但在某个参与者上无法执行，会导致大部分参与者锁定资源，导致浪费。

1.1、XA

2PC的具体实现，利用数据库实现事务的提交和回滚。

1. 准备阶段：参与者执行事务，但不提交；
2. 提交/撤销阶段：协调者根据参与者执行状态，决定提交或者回滚。

缺点：拥有2PC的全部缺点。

1.2、AT

2PC的具体实现，准备阶段直接会提交事务，利用日志记录待操作的原始数据记录的镜像，利用镜像去执行撤销操作，相较于XA同步阻塞的时间更短了。

1. 准备阶段：获取操作数据的全局锁，然后，参与者直接执行事务并提交，并将原数据记录已经执行后的结果存入日志；
2. 确认/撤销阶段：如果存在参与者执行失败，就利用日志撤销其它参与者的执行结果。

1.3、TCC

2PC的具体实现，由业务代码实现资源锁定和事务的提交、回滚操作，分为Try-Confirm/Cancel。

1. Try阶段：确认参与者执行能力，锁定资源；
2. Confirm/Cancel阶段：当所有参与者第一阶段try成功，则执行confirm提交事务；若存在参与者try失败，就执行cancel回滚。

缺点：

1. 在第二阶段会存在部分参与者confirm/cancel失败的情况，需要参与机制确保其至少执行一次。例如使用轮询加幂等性的方法。
2. 空回滚问题：例如在第一阶段try时，由于网络问题参与者a未收到try请求，协调器会发生cancel命令，此时参与者a在未收到try时，就已经收到cancel了，造成空回滚。

1.4、saga

2pc具体实现，长事务的解决方案，和AT有点像，区别在于saga是通过执行补偿业务去完成回滚。

1. 一阶段：执行事务并直接提交；
2. 二阶段：当存在参与者执行失败，就通过对应的补偿业务，回滚所有执行过了的操作。

缺点：

1. 存在脏写；
2. 事务完成执行的时间不确定。

二、3PC（三阶段提交）

成员类型包括事务参与者和事务协调者，分为询问-准备-提交/撤销三个阶段；解决了2PC资源浪费的问题。

1. 询问阶段（canCommit）：不锁定资源，只检查参与者是否有执行事务的能力；
2. 准备阶段：确认全部参与者均拥有事务执行能力，就锁定资源；
3. 提交/撤销阶段：确认参与者全部就绪，就提交事务；若其中存在未就绪的，就回滚。

还是存在事务同步阻塞的问题。

三、消息队列式分布式事务

用消息队列去实现分布式事务。

1. 一阶段：生产者发送半事务消息给消息队列；
2. 二阶段：生产者执行本地事务，执行成功则发送半事务消息的”确认“，以使得半事务消息变为终态，下游消费者能够更加事务消息去执行对应的事务；若执行失败，则取消半事务消息。

缺点：

1. 下游消费者的事务若无法执行，没办法回滚上游生产者的事务，从而导致数据状态不一致；