分布式系统 - 分布式事务及实现方案

为什么会引入事务

拿下单减库存来说举例:当系统的业务量很小时,“一站式”的系统完全可以满足现有业务需求,所有的业务都共用一个数据库,整个下单流程或许只用在一个方法里同一个事务下操作数据库即可。此时所有操作都在一个事务里,要么全部提交,要么全部回滚。

但随着业务量不断增长,“一站式”系统渐渐扛不住巨大的流量,就需要对数据库进行分库分表,将业务服务化拆分(SOA),就会分离出订单中心、用户中心、库存中心。而这样就造成业务间相互隔离,每个业务都维护着自己的数据库,数据的交换只能进行RPC调用。

用户再下单时,创建订单和扣减库存,需要同时对订单DB和库存DB进行操作。两步操作必须同时成功,否则就会造成业务混乱,可此时我们只能保证自己服务的数据一致性,无法保证调用其他服务的操作是否成功,所以为了保证整个下单流程的数据一致性,就需要分布式事务介入。

在说分布式事务之前,先回忆一下事务的基本概念:事务是一个程序执行单元,里面的所有操作要么全部执行成功,要么全部执行失败

事务的理论基础

ACID

一个事务有四个基本特性,也就是我们常说的(ACID):

  • Atomicity(原子性):事务是一个不可分割的整体,事务内所有操作要么全做成功,要么全失败。
  • Consistency(一致性):务执行前后,数据从一个状态到另一个状态必须是一致的(A向B转账,不能出现A扣了钱,B却没收到)。
  • Isolation(隔离性): 多个并发事务之间相互隔离,不能互相干扰。
  • Durablity(持久性):事务完成后,对数据库的更改是永久保存的,不能回滚。

CAP

BASE

分布式事务的解决方案

XA协议是一个基于数据库分布式事务协议,其分为两部分:事务管理器本地资源管理器。事务管理器作为一个全局的调度者,负责对各个本地资源管理器统一号令提交或者回滚。二阶提交协议(2PC)三阶提交协议(3PC)就是根据此协议衍生出来而来。主流的诸如Oracle、MySQL等数据库均已实现了XA接口。

XA接口是双向的系统接口,在事务管理器(Transaction Manager)以及一个或多个资源管理器(Resource Manager)之间形成通信桥梁。也就是说,在基于XA的一个事务中,我们可以针对多个资源进行事务管理,例如一个系统访问多个数据库,或即访问数据库、又访问像消息中间件这样的资源。这样我们就能够实现在多个数据库和消息中间件直接实现全部提交、或全部取消的事务。XA规范不是java的规范,而是一种通用的规范

两段提交(2PC)

两段提交顾名思义就是要进行两个阶段的提交:

  • 第一阶段,准备阶段(投票阶段);
  • 第二阶段,提交阶段(执行阶段)。

下面还拿下单扣库存举例子,简单描述一下两段提交(2PC)的原理:

之前说过业务服务化(SOA)以后,一个下单流程就会用到多个服务,各个服务都无法保证调用的其他服务的成功与否,这个时候就需要一个全局的角色(协调者)对各个服务(参与者)进行协调。

一个下单请求过来通过协调者,给每一个参与者发送Prepare消息,执行本地数据脚本但不提交事务。

如果协调者收到了参与者的失败消息或者超时,直接给每个参与者发送回滚(Rollback)消息;否则,发送提交(Commit)消息;参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过程中被占用的资源,显然2PC做到了所有操作要么全部成功、要么全部失败。

两段提交(2PC)的缺点

二阶段提交看似能够提供原子性的操作,但它存在着严重的缺陷:

  • 网络抖动导致的数据不一致:第二阶段中协调者向参与者发送commit命令之后,一旦此时发生网络抖动,导致一部分参与者接收到了commit请求并执行,可其他未接到commit请求的参与者无法执行事务提交。进而导致整个分布式系统出现了数据不一致。
  • 超时导致的同步阻塞问题:2PC中的所有的参与者节点都为事务阻塞型,当某一个参与者节点出现通信超时,其余参与者都会被动阻塞占用资源不能释放。
  • 单点故障的风险:由于严重的依赖协调者,一旦协调者发生故障,而此时参与者还都处于锁定资源的状态,无法完成事务commit操作。虽然协调者出现故障后,会重新选举一个协调者,可无法解决因前一个协调者宕机导致的参与者处于阻塞状态的问题。

三段提交(3PC)

三段提交(3PC)是对两段提交(2PC)的一种升级优化,3PC在2PC的第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前,各参与者节点的状态都一致。同时在协调者和参与者中都引入超时机制,当参与者各种原因未收到协调者的commit请求后,会对本地事务进行commit,不会一直阻塞等待,解决了2PC的单点故障问题,但3PC还是没能从根本上解决数据一致性的问题。

3PC的三个阶段分别是CanCommit、PreCommit、DoCommit

  • CanCommit:协调者向所有参与者发送CanCommit命令,询问是否可以执行事务提交操作。如果全部响应YES则进入下一个阶段。
  • PreCommit:协调者向所有参与者发送PreCommit命令,询问是否可以进行事务的预提交操作,参与者接收到PreCommit请求后,如参与者成功的执行了事务操作,则返回Yes响应,进入最终commit阶段。一旦参与者中有向协调者发送了No响应,或因网络造成超时,协调者没有接到参与者的响应,协调者向所有参与者发送abort请求,参与者接受abort命令执行事务的中断。
  • DoCommit:在前两个阶段中所有参与者的响应反馈均是YES后,协调者向参与者发送DoCommit命令正式提交事务,如协调者没有接收到参与者发送的ACK响应,会向所有参与者发送abort请求命令,执行事务的中断。

补偿事务 (TCC)

TCC(Try-Confirm-Cancel)又被称补偿事务,TCC与2PC的思想很相似,事务处理流程也很相似,但2PC是应用于在DB层面,TCC则可以理解为在应用层面的2PC,是需要我们编写业务逻辑来实现

TCC它的核心思想是:"针对每个操作都要注册一个与其对应的确认(Try)和补偿(Cancel)"。

还拿下单扣库存解释下它的三个操作:

  • Try阶段:下单时通过Try操作去扣除库存预留资源。
  • Confirm阶段:确认执行业务操作,在只预留的资源基础上,发起购买请求。
  • Cancel阶段:只要涉及到的相关业务中,有一个业务方预留资源未成功,则取消所有业务资源的预留请求。

TCC的缺点

  • 应用侵入性强:TCC由于基于在业务层面,至使每个操作都需要有try、confirm、cancel三个接口。
  • 开发难度大:代码开发量很大,要保证数据一致性confirm和cancel接口还必须实现幂等性。

参考文章

  • http://www.dockone.io/article/9903
  • https://juejin.im/post/6871435457893728263
  • https://juejin.im/post/6844903734753886216

联系我

添加@pdai微信

PS:添加时请备注Java全栈,谢谢!