Day09-第四章-分布式事务使用

1.分布式事务产生的原因

分布式架构的影响

当架构由单体向多服务演进时，整个系统的可靠性变得难以控制，在单体服务中，一个请求的整个周期，从请求到响应结果，都是在一台服务器上，本地事务就可以保证一组数据操作的一致性。 
事务的作用：保证数据源数据一致性。
每个数据源中的事务都是独立，它只能确保自己事务数据的一致性。
原因：主要是受分布式架构的影响，分布式架构中要确保多个数据源的数据一致性。

服务架构操作数据源体现形式
单体服务

分布式服务-有分布式事务

分布式事务具体例子

2.什么是分布式事务

数据库的事务：
    事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。
分布式事务：
     分布式系统中，多个服务操作多个数据库，不同服务参与同一个操作时，要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

用户下单例子

3.分布式事务场景

从软件架构的演变，应用中常用的分布式形式大体分诶两种形式：
    1.单服务多个数据源
    2.多服务多个数据源
分布式场景
    1.单服务多个数据源
        应用场景：数据库分库
    2.多服务多个数据源
        应用场景：跨库事务

单服务多个数据源

多服务多个数据源

4.分布式事务理论

分布式理论：
    1.CAP定理
    2.BASE理论

CAP定理

CAP 定理，又被叫作布鲁尔定理。
C (一致性)：对某个指定的客户端来说，读操作能返回最新的数据。如果读操作时，正在进行写操作，此时读操作会等待，当写操作完后，读操作再进行并返回最新的数据。
A (可用性)：客户端的请求，服务端并会有响应，此动作不会关系数据有没有同步，所有客户端获得的数据可能不是最新的数据。
P (网络分区容错性)：在分布式系统中，由于网络等不稳定因素，导致系统服务间的数据没有同步，此时会出现数据上的错误，而这种数据上出错误是可以容忍存在。不稳定因素解决后，服务间的数据最终会同步。

分区容错

一致性

可用性

BASE 理论

BASE理论是对CAP理论的延伸,满足BASE理论的事务，我们称之为“柔性事务”。
BASE理论通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。
BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。
- 软状态:允许系统中存在中间状态，这个状态不影响系统可用性，如订单的"支付中"状态、不同节点数据副本同步延迟等。
  举例：你参加工作后，通常在拿到第一个月工资的时候，都会选择向家里汇款，当你完成转账操作后，结果银行提示“您的转账预计3日内到账”，而该笔交易的状态为”转账中“。
- 最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，早晚会变为“支付成功”或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。
  举例：向家里汇款2天后，家里人收到转载的钱。
- 基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如，电商网站交易付款出现问题了，商品依然可以正常浏览。
  举例：在这个期间,两个银行的通信网络出现问题，导致实际的转账操作无法完成，但你依然能查询到你的该笔交易状态为”转账中“。

5.分布式系统能否兼顾C、A、P？

分布式系統无法同时满足CAP三项，分布式系统中 P 永远存在。
CAP有哪些组合方式:
    CA，若不需要关注P，那么系统不是分布式系统，加强一致性和可用性，关系数据库按照CA进行设计。
    CP，放弃可用性，追求一致性和分区容错性，比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。
    AP，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的BASE也是根据AP来扩展。比如：订单退款，今日退款成功，明日账户到账，只要在预定的用户可以接受的时间内退款事务走完即可。

CAP 组合图

6.分布式事务的解决方案

企业中分布式事务解决方案有以下5种：
1.XA的2pc两段提交(强一致)
2.3pc三段提交(强一致)
3.TCC事务补偿(最终一致)
4.本地消息表(最终一致)

2PC两阶段提交

2PC是基于XA规范分布式事务解决方案。
XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。
两阶段提交协议(Two Phase Commitment Protocol)中，涉及到两种角色
    一个事务协调者（coordinator）：负责协调多个参与者进行事务投票及提交(回滚)
    多个事务参与者（participants）：即本地事务执行者
两阶段提交：
    prepare阶段：事务执行但不提交阶段
    commit阶段：事务提交阶段

正常情况：

异常情况：

一阶段：
- 事务协调者通知每个事物参与者执行本地事务
- 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁
二阶段：
- 事务协调者基于一阶段的报告来判断下一步操作
  - 如果一阶段都成功，则通知所有事务参与者，提交事务
  - 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务
优点：
    尽量保证了数据的强一致（无法完全保证），适合对数据强一致要求很高的关键领域。
缺点：
    - 同步阻塞问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
    - 单点故障：由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
    - 数据不一致：在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

2PC操作示例

3pc 三阶段提交

三段提交是两段提交的升级版
CanCommit阶段：询问阶段
PreCommit阶段：事务执行但不提交阶段
doCommit阶段：事务提交阶段
优点：相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。
、
缺点：会导致数据不一致性问题。由于网络原因，协调者发送的中断响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到中断命令并执行回滚的参与者之间存在数据不一致的情况。

3pc阶段阶段

TCC事务补偿

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

| 操作方法

| 含义

| | —- | —- | | Try

| 预留业务资源/数据效验-尝试检查当前操作是否可执行

| | Confirm

| 确认执行业务操作，实际提交数据，不做任何业务检查。try成功，confirm必定成功

| | Cancel

| 执行业务出错时，需要回滚数据的状态下执行的业务逻辑 |

优点： 
- 一阶段完成直接提交事务，释放数据库资源，性能好
- 不依赖数据库事务，无同步阻塞，性能好
- 依赖补偿操作，可以用于非事务型数据库
缺点： 
- 在2 3 4步中都有可能失败，从而导致数据不一致。
- TCC属于应用层的一种补偿方式，需要程序员在实现的时候多写很多补偿的代码，复杂业务场景下代码逻辑非常复杂。
- 幂等性无法确保。

TCC事务流程

TCC操作例子

可靠消息最终一致性

可靠消息最终一致性应该是业界使用最多的，其核心思想是将分布式事务拆分成多个本地事务进行处理.
工作流程：
1. 消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。
2. 消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
3. 生产方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。
优点：
- 消息时效性比较高
- MQ实现了消息的可靠性
- 方案比较轻量级，容易实现
缺点： 
- 业务场景强耦合，不可以其他业务场景共用。
- 消息数据与业务数据同步，占用业务系统资源
- 业务系统在使用关系型数据的情况下，消息服务性能会受到关系型数据库的限制。

可靠消息最终一致性

分布式事务解决方案的选择：