分布式事务的几种模式

分布式事务的几种模式

码动青春 483 2021-03-29

XA模式:

XA协议包括两阶段提交(2PC)和三阶段提交(3PC)两种实现。

2PC:

两阶段提交又称2PC(two-phase commit protocol),是一个非常经典的强一致、中心化的原子提交协议。
这里所说的中心化是指协议中有两类节点:一个是中心化协调者节点(coordinator)和N个参与者节点(partcipant)。

第一阶段:请求/表决阶段

第二阶段:提交/执行阶段
两种情况:正常流程、异常流程

性能问题:
执行期间节点阻塞,各个节点都占用着数据资源。
单点故障问题:事务协调者是整个XA模型的核心,一旦挂掉...
第二阶段,如果发生局部网络问题,会导致数据不一致问题

XA模式是分布式强一致性的解决方案,但性能低而使用较少。

3PC

三阶段提交又称3PC,其在两阶段提交的基础上增加了 CanCommit阶段,并引入了 超时机制。
一旦事务参与者迟迟没有收到协调者的Commit请求,就会自动进行本地commit,这样相对有效地解决了协调者单点故障的问题。

第一阶段:CanCommit阶段
第二阶段:PreCommit阶段
第三阶段:DoCommit阶段

对于协调者(Coordinator)和参与者(Partcipant)都设置了超时时间,而2PC只有协调者才拥有超时机制。
这解决了一个什么问题呢?这个优化点,主要是避免了参与者在长时间无法与协调者节点通讯(协调者挂掉了)的情况下,无法释放资源的问题

但是3PC依然没有完全解决数据不一致的问题,假如在 DoCommit 过程,参与者A无法接收协调者的通信,
那么参与者A会自动提交,但是提交失败了,其他参与者成功了,此时数据就会不一致。

AT 模式:

是一种无侵入的分布式事务解决方案,阿里seata框架,实现了该模式。
两阶段提交协议的演变:

一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源。
在一阶段,Seata 会拦截“业务 SQL”,首先解析 SQL 语义,找到“业务 SQL”要更新的业务数据,
在业务数据被更新前,将其保存成“before image”,然后执行“业务 SQL”更新业务数据,在业务数据更新之后,
再将其保存成“after image”,最后生成行锁。
以上操作全部在一个数据库事务内完成,这样保证了一阶段操作的原子性。

二阶段:
二阶段如果是提交的话,因为“业务 SQL”在一阶段已经提交至数据库, 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉,完成数据清理即可。
二阶段如果是回滚的话,Seata 就需要回滚一阶段已经执行的“业务 SQL”,还原业务数据。
回滚方式便是用“before image”还原业务数据;但在还原前要首先要校验脏写,对比“数据库当前业务数据”和 “after image”,
如果两份数据完全一致就说明没有脏写,可以还原业务数据,
如果不一致就说明有脏写,出现脏写就需要转人工处理。

提交异步化,非常快速地完成。
回滚通过一阶段的回滚日志进行反向补偿。

TCC 模式:

TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作;事务发起方在一阶段执行 Try 方式,
在二阶段提交执行 Confirm 方法,二阶段回滚执行 Cancel 方法。

saga模式

Saga 是一种补偿协议,在 Saga 模式下,分布式事务内有多个参与者,每一个参与者都是一个冲正补偿服务,
需要用户根据业务场景实现其正向操作和逆向回滚操作。

总结:

  • AT 模式是无侵入的分布式事务解决方案,适用于不希望对业务进行改造的场景,几乎0学习成本。
  • TCC 模式是高性能分布式事务解决方案,适用于核心系统等对性能有很高要求的场景。
  • Saga 模式是长事务解决方案,适用于业务流程长且需要保证事务最终一致性的业务系统,Saga 模式一阶段就会提交本地事务,无锁,长流程情况下可以保证性能,多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务,无法进行改造和提供 TCC 要求的接口,也可以使用 Saga 模式。
  • XA模式是分布式强一致性的解决方案,但性能低而使用较少。