SpringCloud进阶(5)–Seata分布式事务
在分布式环境下,很多时候我们也需要事务的使用,如购入下单,我们可能需要经过库存服务、订单服务、用户账户服务多个步骤,如果没有事务加持,很有可能会出错。因此我们需要使用分布式事务组件–Seata
我们去实现一个图书管理系统要求:
- 每个用户最多只能同时借阅两本不同的书
- 图书馆中所有书都有3本
- 用户结束流程 先调用图书服务书籍-1 -> 添加借阅记录 -> 调用用户服务用户可借阅数量-1
我们正常去实现这个操作,当用户去借阅第三本书时,会报错(借阅上限),但此时因为先调用了数据服务,图书数量已经-1,我们希望中途出现异常后,之前的操作全部回滚
而这里由于是在另一个服务中进行的数据库操作,所以传统的@Transactional
注解无效,这时就得借助Seata提供分布式事务了。
分布式事务解决方案
1. XA分布式事务协议 – 2PC(两阶段提交实现)
这里的PC指的是Prepare和Commit,也就是说它分为两个阶段,一个准备一个提交。整个过程中的参与者一共有两个角色,一个是事务的执行者,一个是事务的协调者,整个事务的运作都需要依靠协调者来维持。
在准备和提交阶段,会进行:
- 准备阶段:
一个分布式事务是由协调者开启的,首先协调者会向所有事务执行者发送事务内容,等待所有事务执行者答复。
各个事务执行者开始执行事务操作,但是不进行提交,并将undo和redo信息记录到事务日志
如果事务执行者执行事务成功,那么告诉协调者成功,否则告诉协调者失败,不能提交事务。 - 提交阶段:
当所有执行者都反馈完成后,协调者会检查各个执行者的反馈内容,如果所有的执行者都返回成功,那么就会告诉所有的执行者可以提交事务了,最后在释放锁资源。
如果至少有一个执行者返回失败或者超时,那么所有的执行者都会回滚,分布式事务执行失败。
这个方式比较简单,但也存在几个问题:
- 事务协调者是非常核心的角色,一旦出现问题,将导致分布式事务不能正常运行。
- 如果提交阶段发送网络问题,导致某些事务执行者没有收到协调者的执行命令,将导致某些执行者提交,某些执行者没提交。
2.XA分布式事务协议-3PC(三阶段提交实现)
三阶段提交是在二阶段提交的基础上进行改进,主要是加入了超时机制,同时在协调者和执行者中都加入了超时机制。
三个阶段分别是:
- CanCommit阶段
协调者向执行者发送CanCommit请求,询问是否可以执行事务提交操作,然后开始等待执行者的响应。
执行者接受到请求后,正常情况下,如果器自身认为可以顺利执行事务,则返回Yes响应,并进入预备状态,否则返回No - PreCommit阶段
协调者根据执行者的反应情况来决定是否可以进入第二阶段事务。
如果所有执行者都返回Yes,则协调者向所有执行者发送PreCommit请求,并进入Prepared阶段,执行者收到请求后,会执行事务操作,并将undo和redo信息记录到事务日志中,如果成功执行则返回成功响应。
如果所有的执行者至少有一个返回NO,则协调者向所有执行者发送abort请求,所有执行者在收到请求或是超过一段时间没有收到任何请求时,会中断事务。 - DoCommit阶段
该阶段进行真正的的事务提交。
协调者接收到所有执行者发送的成功响应,那么他将从PreCommit状态进入到DoCommit状态,并向所有执行者发送doCommit请求,执行者接收到doCommit请求之后,开始执行事务提交,并在完成事务提交之后释放所有事务资源,并最后向协调者发送确认响应,协调者接收到所有执行者的确认响应之后,完成事务(如果因为网络问题导致执行者没有收到doCommit请求,执行者会在超时之后直接提交事务,虽然执行者只是猜测协调者返回的是doCommit请求,但是因为前面的两个流程都正常执行,所以能够在一定程度上认为本次事务是成功的,因此会直接提交)
协调者没有接收至少一个执行者发送的成功响应(也可能是响应超时),那么就会执行中断事务,协调者会向所有执行者发送abort请求,执行者接收到abort请求之后,利用其在PreCommit阶段记录的undo信息来执行事务的回滚操作,并在完成回滚之后释放所有的事务资源,执行者完成事务回滚之后,向协调者发送确认消息, 协调者接收到参与者反馈的确认消息之后,执行事务的中断。
三段式在两段式的基础上作出改动,但也有缺点:
- 3PC在2PC的第一阶段和第二阶段中插入一个准备阶段,保证了在最后提交阶段之前各参与节点的状态是一致的。
- 一旦参与者无法及时收到来自协调者的信息之后,会默认执行Commit,这样就不会因为协调者单方面的故障导致全局出现问题。
- 但是我们知道,实际上超时之后的Commit决策本质上就是一个赌注罢了,如果此时协调者发送的是abort请求但是超时未接收,那么就会直接导致数据一致性问题。
3.TCC(补偿事务)
补偿事务TCC就是Try、Confirm、Cancel,它对业务有侵入性,一共分为三个阶段。
- Try阶段
比如我们需要在借书时,将书籍的库存-1
,并且用户的借阅量也-1
,但是这个操作,除了直接对库存和借阅量进行修改之外,还需要将减去的值,单独存放到冻结表中,但是此时不会创建借阅信息,也就是说只是预先把关键的东西给处理了,预留业务资源出来。 - Confirm阶段
如果Try执行成功无误,那么就进入到Confirm阶段,接着之前,我们就该创建借阅信息了,只能使用Try阶段预留的业务资源,如果创建成功,那么就对Try阶段冻结的值,进行解冻,整个流程就完成了。当然,如果失败了,那么进入到Cancel阶段。 - Cancel阶段
把冻结的东西还给人家,因为整个借阅操作压根就没成功。就像你付了款买了东西但是网络问题,导致交易失败,钱不可能不还给你吧。
跟XA协议相比,TCC就没有协调者这一角色的参与了,而是自主通过上一阶段的执行情况来确保正常,充分利用了集群的优势,性能也是有很大的提升。但是缺点也很明显,它与业务具有一定的关联性,需要开发者去编写更多的补偿代码,同时并不一定所有的业务流程都适用于这种形式。