day10 分布式事务

分布式事务

分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如：

• 跨数据源的分布式事务

• 跨服务的分布式事务

• 综合情况

在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例，包括下面几个行为：

• 创建新订单

• 扣减商品库存

• 从用户账户余额扣除金额

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。

分布式事务： 分布式系统中，多个服务操作多个数据库，不同服务参与同一个操作时，要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

CAP定理

Consistency(一致性): ：对某个指定的客户端来说，读操作能返回最新的数据。如果读操作时，正在进行写操作，此时读操作会等待，当写操作完后，读操作再进行并返回最新的数据。
Availability（可用性）: 客户端的请求，服务端并会有响应，此动作不会关系数据有没有同步，所有客户端获得的数据可能不是最新的数据。
Partition tolerance（分区容错性）: 在分布式系统中，由于网络等不稳定因素，导致系统服务间的数据没有同步，此时会出现数据上的错误，而这种数据上出错误是可以容忍存在。不稳定因素解决后，服务间的数据最终会同步。
================结论:
CP : 强一致性,弱可用性(牺牲部分机器的可用性,保证数据一致性)
AP : 强可用性,弱一致性(牺牲一致性,保证可用性)

CAP有哪些组合方式:

CA，若不需要关注P，那么系统不是分布式系统，加强一致性和可用性，关系数据库按照CA进行设计。

CP，放弃可用性，追求一致性和分区容错性，比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。

AP，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的BASE也是根据AP来扩展。比如：订单退款，今日退款成功，明日账户到账，只要在预定的用户可以接受的时间内退款事务走完即可。

BASE 理论

BASE理论是对CAP理论的延伸,强调AP,满足BASE理论的事务，我们称之为“柔性事务”。BASE理论通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

 

解决分布式事务的思路

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：

• AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。

• CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：

 

这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。

分布式事务解决方案

2PC是基于XA规范分布式事务解决方案。

XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。

两阶段提交协议(Two Phase Commitment Protocol)中，涉及到两种角色
    一个事务协调者（coordinator）：负责协调多个参与者进行事务投票及提交(回滚)
    多个事务参与者（participants）：即本地事务执行者

两阶段提交：
    prepare阶段：事务执行但不提交阶段
    commit阶段：事务提交阶段

TCC事务补偿

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。三个阶段如下：

操作方法	含义
Try	预留业务资源/数据效验-尝试检查当前操作是否可执行
Confirm	确认执行业务操作，实际提交数据，不做任何业务检查。try成功，confirm必定成功
Cancel	执行业务出错时，需要回滚数据的状态下执行的业务逻辑

Seata的架构

Seata事务管理中有三个重要的角色：

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

• TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。

• RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

整体的架构如图：

 

 

四种模式对比

我们从以下几个方面来对比四种实现：

• 一致性：能否保证事务的一致性？强一致还是最终一致？

• 隔离性：事务之间的隔离性如何？

• 代码侵入：是否需要对业务代码改造？

• 性能：有无性能损耗？

• 场景：常见的业务场景