微服务架构下的分布式事务解决方案

微服务架构下的分布式事务解决方案

基础概念

事务

        事务是指作为单个逻辑工作单元执行的一系列操作，要么完全（全部）的执行，要么完全的失败。简单的说，事务就是并发控制的单位，是用户定义的一个操作序列。

本地事务

        在计算机系统中，更多的是通过关系型数据库来控制事务，这是利用数据库本身的事务特性来实现的，因此叫数据 库事务，由于应用主要靠关系数据库来控制事务，而数据库通常和应用在同一个服务器，所以基于关系型数据库的事务又被称为本地事务。
回顾一下数据库事务的四大特性 ACID：
        A（Atomic）：原子性，构成事务的所有操作，要么都执行完成，要么全部不执行，不可能出现部分成功部分失败的情况。
        C（Consistency）：一致性，在事务执行前后，数据库的一致性约束没有被破坏。比如：张三向李四转100元， 转账前和转账后的数据是正确状态这叫一致性，如果出现张三转出100元，李四账户没有增加100元这就出现了数据错误，就没有达到一致性。
        I（Isolation）：隔离性，数据库中的事务一般都是并发的，隔离性是指并发的两个事务的执行互不干扰，一个事务不能看到其他事务运行过程的中间状态。通过配置事务隔离级别可以避脏读、重复读等问题。
        D（Durability）：持久性，事务完成之后，该事务对数据的更改会被持久化到数据库，且不会被回滚。
数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的执行单元，该执行单元中的所有操作要么都成功，要么都失败，只要其中任一操作执行失败，都将导致整个事务的回滚。

分布式事务

        分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务。

常见场景：

1.微服务架构之间通过远程调用完成事务操作。（跨jvm进程产生的事务）
2.单体系统访问多个数据库实例
3.多服务访问同一个数据库

分布式理论

分布式事务理论基础

        与本地事务不同的是，分布式系统之所以叫分布式，是因为提供服务的各个节点都在不同的服务器上，相互之间通过网络交互，不能因为网络问题一些服务不可用导致整个系统都不能用；网络因素成了分布式事务考量标准之一。因此分布式事务更需要一些理论支持“CAP理论”、“BASE理论”。
理解CAP
        CAP理论：CAP指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
        C - Consistency：一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分部到多个节点上，从任意节点读取到的数据都是最新状态。
        A - Availability：可用性指的是任何事物操作都可以得到响应结果，且不会出现响应超时或者响应错误。
        P - Partition tolerance：通常分布式系统的各节点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题而导致节点之间通信失败，此时仍可以对外提供服务，这叫分区容忍性。（分区容忍性是分布式系统具备的基本能力）示例：注册中心Eureka与ZooKeeper之间的对比
CAP组合方式：
        在所有分布式事务场景中不会同时具备CAP三个特性，因为在具备了P的前提下C和A是不能共存的，所以在生成中对分布式事务处理时要根据需求来确定CAP组合的两种。
        1.AP：放弃一致性，追求分区容忍性和可用性。（Eureka）
示例：比如银行转账，在一定的时间内到账
        2.CP：放弃可用性，追求一致性和分区容错性，zookeeper其实就是追求强一致性
示例：跨行转账，一次转账请求要等双方银行系统都完成整个事务才算完成。
        3.CA：放弃分区容忍性，即不进行分区，不考虑用于网络不通或节点挂掉的问题，则可以试下一致性和可用性，一般这种都是单体服务。

Base理论

强一致性和最终一致性
        CAP理论告诉我们一个分布式系统最懂只能同时满足一致性、可用性和分区容错性这三项中的两项，现实场景中AP在实际应用中比较多，舍弃一致性，保证可用性和分区容忍性，但是在实际生产中很多场景都要实现一致性，即最终一致性，而我们CAP中的一致性要求在任何时间查询每个节点数据都必须一致，它强调的是强一致性，但是最终一致性是允许可以在一段时间内 每个节点的数据不一致，但是经过一段时间每个节点的数据必须一致，它强调的是最终数据一致性。
Base理论介绍
        BASE是Basically Avaliable(基本可用)、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。Base理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，也称“柔性事务”。
        基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
        软状态：由于不要求强一致性，所以Base允许系统中存在中间状态，这个 状态不影响系统可用性。
        最终一致性：最终一致性是经过一段时间后，所有节点数据都将会达到一致。

2PC

        2PC即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Preparephase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。
在计算中部分关系数据库如Oracle、Mysql支持两阶段提交协议。
        1.准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此事务没有提交。（Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改手的数据，用于提交事务后写入数据文件）
        2.提交阶段（Commit phase）：如果事务管理器收到了参与者的执行或者超时消息时，直接给每个参与者发送回滚（RollBack）消息；否则，发送提交（Commit）消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意：必须在最后阶段释放锁资源。
成功示例：失败示例：

XA协议：
        2PC的传统方案是在数据库层面实现的，如Oracle、Mysql都支持2PC协议，为了统一标准减少行业内不必要的对接成本，需要制定标准化的处理模型及标准接口，国际开放标准组织Open Group定义了分布式事务处理模型DTP（Distributed Transaction Processing Reference Model）。
DTP模型定义如下角色：
        AP（Application Program）：即应用程序，可以理解为使用DTP分布式事务的程序。
        RM（Resource Manager）：即资源管理器，可以理解为事务的参与者，一般情况下是指一个数据库实例，通过资源管理器对数据库进行控制，资源管理器控制着分支事务。
        TM（Transcation Manager）：事务管理器，负责协调和管理事务，事务管理器控制着全局事务，管理事务生命周期，并协调各个RM。全局事务是指分布式事务处理环境中，需要操作多个数据库共同完成一个工作，这个工作即时一个全局事务。
        DTP模型定义TM和RM之间通讯的接口规范叫“XA”，简单理解为数据库提供的2PC接口协议，基于数据库的XA协议来实现2PC又称为XA方案。
交互方式：
        TM向AP提供应用程序编程接口，AP通过TM提交及回滚事务。
        TM交易中间件通过XA接口来通知RM数据库事务的开始、结束以及提交、回滚等。
总结：
        整个2PC事务流程涉及到三个角色AR、RM、TM。
        1》、在准备阶段RM执行实际业务操作，但不提交事务，资源锁定；
        2》、在提交阶段TM会接收RM在准备阶段的执行回复，只要有任意一个RM执行失败，TM会通知所有的RM执行回滚操作，否则，TM将会通知你所有的RM提交该事务，提交阶段结束资源锁释放。
不足之处：
        1.需要本地数据库支持XA协议
        2.资源锁需要等到两个阶段结束后才释放，性能较差。
Seata方案
        Seata是由阿里中间件团队发起的开源项目Fescar，后更名为Seata，它是一个开源的分布式事务框架。
        传统2PC的问题在Seata中得到了解决，他通过对本地关系数据库的分支事务的协调来驱动完成全局事务，是工作在应用层中的中间件。主要优点是性能较好，且不长时间占用连接资源，它以高效并且对业务0侵入的方式解决微服务场景下面临的分布式事务的问题，它是目前提供AT模式（即2PC）及TCC模式的分布式事务解决方案。
Seata设计思想：
        Seata的设计目标是对业务无侵入，因此从业务无侵入的2PC方案着手，在传统的2PC的基础上演进，并解决2PC方案面临的问题。
Seata把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务。与传统2PC的模拟类型，Seata定义了3个组件来协议分布式事务的处理过程：        Transcation Coordinator(TC)：事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收TM指令发起全局事务的提交与回滚，负责与RM通信协调各分支事务的提交或回滚。
        Transaction Manager（TM）：事务管理器，TM需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向TC发起全局提交或全局回滚指令。
        Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接受事务协调器TC的指令，驱动分支（本地）事务的提交或回滚。

具体执行流程如下：

• 1.用户服务的TM向TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID。
• 2.用户服务的RM向TC注册分支事务，改分支事务在用户服务执行新增用户逻辑，并将其纳入XID对应全局事务的管辖。
• 3.用户服务执行分支事务。
• 4.逻辑执行到远程调用积分服务是（XID在微服务调用链路的上下文中传播）。积分服务的RM向TC注册分支事务，改分支事务执行增加积分的逻辑，并将其纳入XID对应全局事务的管辖。
• 5.积分服务执行分支事务，向积分记录插入一条记录，执行完毕后，返回用户服务。
• 6.用户服务分支事务执行完毕。
• 7.TM向TC发起对XID的全局提交或回滚协议。
• 8.TC调度XID下管辖的全部分支事务完成提交或回滚请求。

Seata实现2PC与传统2PC的差别：
        架构层次方面，传统的2PC方案的RM实际上市在数据库层，RM本质上就是数据库自身，通过XA协议实现，而Seata的RM是以jar包的形式作为中间件层部署在应用程序这一侧的。
        两阶段提交方面，传统2PC无论第二阶段的决议是Commit还是RollBack，事务性资源的锁都要保持到阶段2完成才释放，而Seata的做法是在阶段1就将本地事务提交，这样就可以省去阶段2持锁的时间，整体提高效率。
Seata实现2PC要点：

• 1.全局事务开始使用@GlobalTransactional标识
• 2.每个本地事务方案仍然使用@Transactional标识。
• 3.每个数据都需要创建undo_log表，此表是Seata保证本地事务一致性的关键。

TCC

        TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作即回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。

TCC分为三个阶段：

• 1.Try阶段是做业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的Confirm一起才能真正构成一个完整的业务逻辑。
• 2.Confirm阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行Confirm。通常情况下，采用TCC则认为Confirm阶段是不会出错的。即：只要try成功，Confirm一定成功，若Confirm阶段真的出错了，需引入重试机制或人工处理。
• 3.Cancel阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。
• 4.TM事务管理器：可以实现独立的服务，也可以让全局事务发起方充当TM角色，TM独立出来是为了成为共用组件，是为了考虑系统结构和软件复用。
          TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条，用来记录事务上下文和记录状态，由于Confirm和Cancel失败需进行重试，因此需要实现幂等，幂等行是指同一个操作无论请求多少次，结果都一样。

Hmily实现TCC事务
        Hmily是一个高性能分布式事务TCC开源框架。基于java开发，支持Dubbo，SpringCloud等RPC框架进行分布式事务，支持的特征如下：

• 1.支持事务嵌套
• 2.采用disruptor框架进行事务日志的异步读写，与RPC框架的性能毫无差别。
• 3.支持SpringBoot-Starter项目启动，使用简单。
• 4.RPC框架支持：dubbo、motan、springcloud。
• 5.本地事务存储支持：redis、mongodb、zookeeper、file、mysql。
• 6.事务日志序列化支持：java、hession、kyno、porotostuff。
• 7.采用Aspect AOP切面思想与Spring无缝集成，天然支持集群。
• 8.RPC事务回复，超时异常恢复等。

        Hmily利用AOP对参与分布式事务的本地方法与远程方法进行拦截处理，经过多方拦截，事务参与者能透明的调用到另一方的Try、confirm、Cancel方法；传递事务上下文；并记录事务日志，酌情进行补偿，重试等。Hmily不需要事务协调服务，但需要提供一个数据库来进行 日志存储。
        Hmily实现的TCC服务与普通的服务一样，只需要暴露一个接口，也就是它的Try业务。Confirm/Cancel业务逻辑，只是因为全局事务提交/回滚的需要才提供的，因此Confirm/Cancel业务只需要被Hmily TCC事务框架发现即可，不需要被调用它的业务服务所感知。

TCC需要注意三种异常处理分别是空回滚、幂等、悬挂：
        空回滚：在没有调用TCC资源Try方法的情况下，调用了二阶段的Cancel方法，Cancel方法需要识别出这是一个空回滚，然后直接返回成功。
        出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。
        解决思路：首先查看第一阶段是否执行，如果执行了，那就是正常回滚；如果没执行，那就是空回滚。
        TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条。在额外增加一张分支事务记录表，其中有全局事务ID和分支事务ID，第一阶段Try方法里会插入一条记录，表示一阶段执行了。Cancel接口读取改记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。
        幂等：为了保证TCC二阶段提交重试机制不会引发数据不一致，要求TCC的二阶段Try、Confirm和Cancel接口保证幂等，这样不会重复使用或者释放资源。如果接口幂等控制没有做好，何有可能导致数据不一致等严重问题。
        悬挂：悬挂就是对于一个分布式事务，其二阶段Cancel接口比Try接口先执行。
        出现原因是在RPC调用分布式事务try时，先注册分支事务，在执行RPC调用，如果此时RPC调用的网络发生拥堵，通常RPC调用是有超时间的，RPC超时以后，TM就会通知RM回滚该分布式事务，可能回滚完成后，RPC请求才能达到参与这真正执行，而一个Try方法预留的业务资源，只有该分布式事务才能使用，该分布式事务第一阶段预留的业务资源就再也没有人能够处理了，对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。

可靠消息最终一致性

        可靠消息最终一致性方案是指当事务发起方执行完成本地事务后发出一条信息，事务参与者（消息消费者）一定能够接收消息并处理事务成功，此事务强调的是只要消息发给事务参与方最终事务要达到一致。
        事务发起方（消息生产方）将消息发送给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件之间，事务参与方 （消息消费方）和消息中间件之间通过网络通信，由于网络通信的不确定性会导致分布式事务问题。

• 1.本地事务与消息发送的原子性问题

        本地事务与消息发送的原子性问题即：事务发起方在本地事务执行成功后必须发出去，否则就丢弃消息。即实现本地事务和消息发送的原子性，要么都成功，要么都失败。本地事务与消息发送的原子性问题是实现可靠消息最终一致性方案的关键问题。

• 2.事务参与方接收消息的可能性
          事务参与者必须能够从消息队列接收到消息，如果接收消息失败可以重复接收消息，
• 3.消息重复消费的问题
          由于网络存在，若某一个消费节点超时但是消费成功，此时消息中间件会重复投递次消息，就导致了消息的重复消费。
  要解决消息重复消费的问题就要实现事务参与方的方法幂等性。

本地消息表方案
        本地消息表核心是通过本地事务保证数据业务操作和消息的一致性，然后通过定时任务将消息发送至消息中间件，待确认消息发送给消费方成功再将消息删除。
流程如下：
        1）消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。
        2）消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作
        3）生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的

消息中间件事务消息方案

Producer即MQ发送方

• 1.Producer发送事务消息
          Producer发送事务消息值MQ Server，MQ Server将消息状态标志为Prepared（预备状态），此时消息消费者是无法消费到的。
• 2.MQ Server回应消息发送成功
          MQ Server接收到Producer发送的消息则回应发送成功表示MQ已接收到消息。
• 3.Producer执行本地事务
          Producer端执行业务代码逻辑，通过本地数据库事务控制。
• 4.消息投递
          若Producer本地事务执行成功则自动向MQ Server发送Commit消息，MQ server接收到Commit消息后将状态标记为可消费，此时MQ订阅方可正常消费消息。
  若Producer本地事务执行失败则自动向MQ Server发送rollback消息，MQ Server接收到rollback消息后将删除第一步里面所做的操作。
• 5.事务回查
          如果执行Producer端本地事务过程中，执行端挂掉，或者超时，MQ Server将会不停的询问 同组的其他Producer来获取事务执行状态，这个过程叫事务回查。MQServer 会根据事务回查结果来决定是否投递消息。

        可靠消息最终一致性就是保证消息从生产方经过消息中间件传递到消费方的一致性。
可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后，同步的事务操作变为基于消息执行的异步操作，避免了分布式事务中同步阻塞操作的影响，并实现了两个服务的解耦。

最大努力通知

        最大努力通知方案主要也是借助MQ消息系统来进行事务控制，这一点与可靠消息最终一致方案一样。看来MQ中间件确实在一个分布式系统架构中，扮演者重要的角色。最大努力通知方案是比较简单的分布式事务方案，它本质上就是通过定期校对，实现数据一致性。
最大努力通知方案的实现

• 1.业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息，允许消息丢失。
• 2.主动方可以设置时间阶梯型通知规则，在通知失败后按规则重复通知，直到通知N次后不再通知。
• 3.主动方提供校对查询接口给被动方按需校对查询，用于恢复丢失的业务消息。
• 4.业务活动的被动方如果正常接收了数据，就正常返回响应，并结束事务。
• 5.如果被动方没有正常接收，根据定时策略，向业务活动主动方查询，恢复丢失的业务消息。

最大努力通知方案的特点

• 1.用到的服务模式：可查询操作、幂等操作。
• 2.被动方的处理结果不影响主动方的处理结果；
• 3.适用于对业务最终一致性的时间敏感度低的系统；
• 4.适合跨企业的系统间的操作，或者企业内部比较独立的系统间的操作，比如银行通知、商户通知等；

最大努力通知方案的设计
        相比于可靠消息最终一致方案，最大努力通知方案设计上比较简单，主要是由两部分构成。

• 1.实时消息服务（MQ）：接收主动方发送的MQ消息。

• 2.通知服务子系统：监听MQ消息，当收到消息后，向被动方发送通知（一般是URL方式），同时生成通知记录。如果没有接收到被动方的返回消息，就根据通知记录进行重复通知。

        最大努力通知方案实现方式比较简单，本质上就是通过定期校对，适用于数据一致性时间要求不太高的场合，其实不把它看作是分布式事务方案，只认为是一种跨平台的数据处理方案也是可以的。

方案一：

流程如下：

• 1.发起方通知方将通知发送给MQ
          使用普通消息机制将通知发送给MQ。
• 2.接收通知方监听MQ
• 3.接收通知方接收消息，业务处理完成回应ack
• 4.接收通知方若没有回应ack则MQ会重复通知。
          MQ会按照时间间隔1min、5min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔，直到达到通知要求的时间窗口上限。
• 5.接收通知方可通过消息校对接口开校对消息的一致性。

方案二：
交互流程如下：

• 1.发起通知方将通知发给MQ
          使用可靠消息一致性方案中的事务消息保证本地事务与消息的原子性，最终将通知发给MQ。
  2.通知程序监听MQ，接收MQ的消息
          通知程序若没有回应ack则MQ会重复通知。
• 3.通知程序通过互联网接口协议（如http、webService）调用接收通知方案接口，完成通知。
          通知程序调用接收通知方案接口成功就表示通知成功，即消费MQ消息成功，MQ将不再向通知程序投递通知消息。
• 4.接收通知方可通过消息校对接口来校对消息的一致性

方案一与方案二的不同：
        1.方案一种接收通知方与MQ接口，即接收通知方案监听MQ，此方案主要应用与内部应用程序之间的通知
        2.方案二中由通知程序与MQ接口，通知程序监听，收到MQ的消息后有通知程序通过互联网接口协议调用接收通知方。此方案主要应用于外部应用之间的通知，例如支付宝、微信的支付结果通知。
        最大努力通知方案是分布式事务中对一致性要求最低的一种，使用与一些最终一致性 时间敏感度低的业务；最大努力通知方案需要实现如下功能：

• 1.消息重复通知机制
• 2.消息校对机制

分布式事务对比

        2PC最大的诟病是一个阻塞协议。RM在执行分支事务后需要等待TM的决定，此时服务会阻塞并锁定资源。不适用于并发较高以及事务生命周期较长的分布式服务中。
        TCC相比较2PC来说，2PC通常都是在跨库的DB层面，而TC则在应用层的处理，需要通过业务逻辑来实现。代码量较大，维护难，业务侵入性强，实现难度较大，需要按照网路状态，系统故障等不同的失败原因实现不同的回滚策略。
        可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后，同步的事务操作变为基于消息执行的异步操作，避免了分布式事务中的同步阻塞操作的影响，并实现了两个服务的解耦。
        最大努力通知是分布式事务中要求最低的一种，适用于一些最终一致性时间敏感度低的业务；允许发起通知方处理业务失败，在接收通知方收到通知后积极进行失败处理，无论发起通知方如何处理结果都不会影响到接收通知方的后续处理；发起通知发需提供查询执行情况接口，用于接收通知方校对结果。

总结：
        在条件允许的情况下，尽可能选择本地事务但数据源，减少了网络交互带来的性能损耗，且避免了数据弱一致性带来的种种问题。
        无论是数据库层的XA协议，还是应用层TCC、可靠消息、需求最大努力通知方案，都无法完美解决 分布式事务问题，只是各自在性能、一致性、可用性等方面做取舍，寻求某些场景偏好下的权衡。

结束语：

        本文在撰写的过程中有涉及到别人的版权地方，私信必删！