分布式事务入门

分布式事务入门

一、为什么会产生分布式事务

我们从单体架构不断的演变成为SOA架构、微服务架构的时候就会一个是事务里包含多个系统，多个数据库的操作，这个时候传统事务就解决不了；

• 数据库分库分表：在单库单表场景下，当业务数据量达到单库单表的极限时，就需要考虑分库分表，将之前的单库单表拆分成多库多表；分库分表之后，原来在单个数据库上的事务操作，可能就变成跨多个数据库的操作，此时就需要使用分布式事务。
• 业务服务化：业务服务化即业务按照面向服务（SOA）的架构拆分整个网站系统，所有的业务操作都以服务的方式对外发布，跨应用、跨服务的操作需要使用分布式事务才能保证数据的一致性。

二、解决分布式事务前序

1、CAP原理

由于对服务或者数据库进行了拆分，这里就使用到了分布式的CAP原理；

• C一致性；
• A可用性；
• P分区容错性
  对于分布式系统，分区容错性是一定要满足的，这里就分出来AP和CP两种情况，我们常见的注册中心ZK主要保证了CP，eureka主要保证了AP

2、BASE原理

对于CAP原理的数据一致性，后来又提出了BASE原理，核心思想：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一致性。

• BA：基本一致性，比如流量大的时候，有一部分用户响应不过来，进行了降级处理，但还是有一部分可用的；
• S：柔性状态
• E：最终一致性，这里要求幂等性

3、柔性事务与刚性事务

• 刚性：主要是指那些满足ACID的事务
• 柔性：
  • 两阶段提交：基于XA协议实现
  • 补偿型TCC：Try/Confirm/Cancel
  • 异步确保型（使用消息中间件）

三、解决分布式事务问题的方案

1、两阶段提交方案：基于XA协议实现

下图为XA规范主要组件：

• AP：定义事务的边界，即定义了事务开始和结束的边界
• TM：事务管理器，负责管理全局事务，分配事务唯一标 识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。
• RMs：资源管理器，Rm管理计算机共享的资源，许多软件都可 以去访问这些资源，资源包含比如数据库、文件系统、打印机服务器等。

第一阶段：TM要求所有的RM准备提交对应的事务分支，询问RM是否有能力保证成功的提交事务分支，RM根据自己的情况，如果判断自己进行的工作可以被提交，那就就对工作内容进行持久化，并给TM回执OK；否者给TM的回执NO。RM在发送了否定答复并回滚了已经的工作后，就可以丢弃这个事务分支信息了。 
第二阶段：TM根据阶段1各个RM prepare的结果，决定是提交还是回滚事务。如果所有的 RM都prepare成功，那么TM通知所有的RM进行提交；如果有RM prepare回执NO的 话，则TM通知所有RM回滚自己的事务分支。 也就是TM与RM之间是通过两阶段提交协议进行交互的. 

优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不 能100%保证强一致） 
缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

注释：常见的XA的解决方案有atomikos；

2、补偿型TCC：核心思想是针对每一个操作，都注册一个与其对应的确认（Confirm）和取消（Concel）操作；

主要分为以下三个步骤：

• Try 阶段主要是对业务系统做检测及资源预留（比如这里先弄一些预留字段，把资源冻结处理，不进行真正的update）
• Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm 阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
• Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源 释放。

注释：confirm、cancel阶段可以使用到一些分布式框架（大佬的话，也可以自己写），比如：tcc-transaction、EasyTransaction
https://github.com/QNJR-GROUP/EasyTransaction
https://github.com/changmingxie/tcc-transaction

例如： A要向 B 转账，思路大概是：
我们有一个本地方法，里面依次调用

1、首先在 Try 阶段，要先调用远程接口把 B和 A的钱给冻结起来。例如在A,B所在账户表中各自新增一个字段，在try阶段不update，而是将转账金额存下来；
2、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。 
3、如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解 冻方法 (Cancel)。

优点： 相比两阶段提交，可用性比较强 
缺点： 数据的一致性要差一些。TCC属于应用层的一种补偿方式，所以需要程序员在实 现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

3、消息中间件：核心思想就是将分布式事务拆分为本地事务进行处理；

基本思路就是： 
消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一 个事务里提交，也就是说他们要在一个数据库里面。
然后消息会经过MQ发送到消息的消 费方。如果消息发送失败，会进行重试发送。 

消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成 功，表明已经处理成功了，如果处理失败，那么就会重试执行。
如果是业务上面的失 败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。 生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一 遍。
如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。 

优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。 
缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

总结：

分布式事务是一个复杂的问题，我这里只是简单做一下介绍，如果有不当之处，欢迎指正；