分布式事务
背景
分布式事务理论基础
传统事务
刚性事务：遵循ACID原则，强一致性
原子性(Atomicity)：事务内的所有操作要么都提交成功，要么都失败回滚
一致性(Consistency)：由db和业务系统共同来保证，db保证提交一致性，业务系统保证业务逻辑一致
隔离性(Isolation)：事务必须在不干扰其他进程或事务的前提下独立执行，若有并发资源，则串行
持久性(Durability)：事务执行成功以后，该事务对数据库所作的更改便是持久的保存在数据库之中
分布式事务
柔性事务：基于CAP定理、BASE理论，最终一致性，允许一定时间内，不同节点的数据不一致，但要求最终一致
CAP定理的结论是：在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼，只能同时满足其二
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）
为了可用性(性能)、我们必须降低一致性的要求
分布式事务方案
2PC方案(两阶段提交)
交易中间件与数据库通过XA接口规范，使用两阶段提交来完成一个全局事务，XA 规范的基础是两阶段提交协议
第一阶段是表决阶段，所有参与者都将本事务能否成功的信息反馈发给协调者
第二阶段是执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚
缺点：
同步阻塞问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态
数据不一致：在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象
两阶段提交方案应用非常广泛，几乎所有商业OLTP数据库都支持XA协议。但是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题
TCC方案(业务补偿)
一个完整的业务活动由一个主业务服务与若干从业务服务组成
主业务服务负责发起并完成整个业务活动
从业务服务提供TCC型业务操作
TCC和2PC很像，不过TCC的事务控制都是业务代码层面的，而2PC则是资源层面的
TCC事务其实主要包含两个阶段：Try阶段、Confirm/Cancel阶段
-
Try-尝试执行业务
完成所有业务检查(一致性)
预留必须业务资源(准隔离性) -
Confirm-确认执行业务
真正执行业务
不作任何业务检查
只使用Try阶段预留的业务资源
Confirm操作必须保证幂等性 -
Cancel-取消执行业务
释放Try阶段预留的业务资源
Cancel操作必须保证幂等性
事务开始时，业务应用向事务协调器注册启动事务，之后业务应用会调用所有服务的try接口，完成一阶段准备，之后事务协调器会根据try接口返回情况，决定调用confirm接口或cancel接口，如接口调用失败，则进行重试
TCC方案让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。 当然TCC方案也有不足之处，集中表现在以下两个方面：
对应用侵入性强，业务逻辑每个分支都需要实现Try、Confirm、Cancel三个操作，应用侵入性较强，改造成本高
实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，Confirm和Cancel接口必须实现幂等
上述原因导致TCC方案大多被研发实力较强、有迫切需求的大公司所采用。微服务倡导服务的轻量化、易部署，而TCC方案中很多事务的处理逻辑需要应用自己编码实现，复杂且开发量大
Seata
Seata 的定位是分布式事全场景解决方案，有AT、TCC、SAGA、XA四种模式，每种模式都有它的适用场景：
AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景
TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景
SAGA 模式是长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式
XA 模式
大家可以根据自己的业务状况进行选择
AT模式
Seata AT模式是基于XA事务演进而来的一个分布式事务中间件，XA是一个基于数据库实现的分布式事务协议，本质上和两阶段提交一样，需要数据库支持，Mysql5.6以上版本支持XA协议，其他数据库如Oracle，DB2也实现了XA接口
Seata 中有三大模块：
TM、RM 和 TC，其中 TM 和 RM 作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 服务端独立部署
TC（Seata Server）：事务管理器服务功能，包括事务协调、存储、全局锁、RPC通讯、HA等
TM：事务管理器，开启、提交、回滚分布式事务
RM：资源管理器，注册、汇报分支事务
在 Seata 的AT模式中，分布式事务的执行流程：
一阶段：
TM 开启分布式事务（TM 向 TC 注册全局事务记录）
按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）
TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）
二阶段：
TC 汇总事务信息，决定分布式事务是提交还是回滚
TC 通知所有RM 提交/回滚 资源，事务二阶段结束
TCC模式
Seata也针对TCC做了适配兼容，支持TCC事务方案，原理前面已经介绍过，基本思路就是使用侵入业务上的补偿及事务管理器的协调来达到全局事务的一起提交及回滚
SAGA模式
XA模式
