本质上来说,分布式事务就是为了保证不同数据库的数据一致性。
分布式事务

  1. 分布式理论
    1.1. CAP定律
    CAP指的是:一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。
    CAP定律说的是,在一个分布式系统中,最多只能满足C、A、P中的两个,不可能三个同时满足。
    在分布式系统中,网络无法 100% 可靠,分区其实是一个必然现象。如果我们选择了 CA 而放弃了 P,那么当发生分区现象时,为了保证一致性,这个时候必须拒绝请求,但是 A 又不允许,所以分布式系统理论上不可能选择 CA 架构,只能选择 CP 或者 AP 架构。
    而且,显然,任何横向扩展策略都要依赖于数据分区。因此,设计人员必须在一致性与可用性之间做出选择。
    1.2. BASE理论
    往往在分布式系统中无法实现完全一致性,于是有了BASE理论,它是对CAP定律的进一步扩充
    BASE指的是:
    BASE理论是对CAP中的一致性和可用性进行一个权衡的结果
    BASE理论核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性
    BASE理论是通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态
  2. 分布式事务解决方案
    2.1. 基于XA协议的两阶段提交
    XA协议包含两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,目前主流的关系型数据库都实现了XA接口,而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。
    分布式事务
    优点:尽量保证了数据的强一致,适合对数据强一致要求很高的关键领域。(其实也不能100%保证强一致)
    缺点:XA协议遵循强一致性。在事务执行过程中,各个节点占用着数据库资源,只有当所有节点准备完毕,事务协调者才会通知提交,参与者提交后释放资源。这样的过程有着非常明显的性能问题。
    (PS:XA三阶段提交在两阶段提交的基础上增加了CanCommit阶段,并且引入了超时机制。这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。)
    两阶段提交方案锁定资源时间长,对性能影响很大,基本不适合解决微服务事务问题。
    2.2. TCC方案
    TCC 其实就是采用的补偿机制,其核心思想是:针对每个操作,都要注册一个与其对应的确认和补偿(撤销)操作。
    其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作,confirm部分完成业务的提交,cancel部分完成事务的回滚。
    分布式事务
    拿前面的下单的例子来说,服务A的try相当于查询是否有可用的积分,Confirm相当于扣减积分,Cancel相当于增加积分。
    优点:跟2PC比起来,实现以及流程相对简单了一些,但数据的一致性比2PC也要差一些
    缺点:TCC属于应用层的一种补偿方式,所以需要程序员在实现的时候多写很多补偿的代码,而且补偿的时候也有可能失败,在一些场景中,一些业务流程可能用TCC不太好定义及处理。
    2.3. 本地消息表
    其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。
    消息生产方,需要额外建一个消息表,并记录消息发送状态。消息表和业务数据要在一个事务里提交,也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败,会进行重试发送。
    消息消费方,需要处理这个消息,并完成自己的业务逻辑。此时如果本地事务处理成功,表明已经处理成功了,如果处理失败,那么就会重试执行。如果是业务上面的失败,可以给生产方发送一个业务补偿消息,通知生产方进行回滚等操作。
    生产方和消费方定时扫描本地消息表,把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑,这种方案还是非常实用的。
    本地消息表是一个比较好的做法,这样可以有效防止重复消息处理
    以转账为例,这种方式的过程是这样的:
    有了消息表以后,可以防止重复、可以重试、保证消息不丢失、做幂等性校验
    优点:一种非常经典的实现,避免了分布式事务,实现了最终一致性。
    缺点:消息表会耦合到业务系统中,如果没有封装好的解决方案,会有很多杂活需要处理。
    2.4. MQ(非事务消息)
    如果不把本地数据库操作和消息投递放在同一个事务中,那么很难保证本地事务成功后消息一定发送成功
    如果把它们放在同一个事务中,那么考虑下面几种情况:
    以上三种情况都是正常的,不会有什么问题
    然而,考虑下面这种情况:
    本地数据库操作成功,消息投递成功,应用服务器挂了,事务回滚,于是不一致出现了,即本地数据库操作没成功,而消息却发成功了
    如果这是转账的话,对方会无缘无故多出一笔钱
    究其原因,是因为发消息不是数据库操作,它不受ACID的限制,也就是说数据库事务管不了发消息,因为他们不是同一个数据库的同一个事务,当然还有一个原因是发出去的消息是无法撤销的。(PS:在后面将要介绍的RocketMQ的事务消息可以撤销)
    而上面消息表的话,是同一个数据库的同一个事务,因此不会出现这种问题
    综上,这种方式有一定的风险,它无法保证本地数据库操作 与 消息投递的一致性,不建议使用
    2.5. MQ(事务消息)
    目前,仅阿里云的RocketMQ支持事务消息。帮助用户实现类似 X/Open XA 的分布事务功能,通过 MQ 事务消息能达到分布式事务的最终一致。
    分布式事务
    说明:
    其中,事务消息发送对应步骤1、2、3、4,事务消息回查对应步骤5、6、7
    2.6. GTS
    全局事务服务(Global Transaction Service,简称 GTS)是一款高性能、高可靠、接入简单的分布式事务中间件,用于解决分布式环境下的数据一致性问题。GTS 可以保证分布式系统中的分布式事务的 ACID 特性。它是阿里云的一款产品。