事务

事物具有ACID这四个特性

  1. 原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态。
  2. 一致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性限制没有被破坏。
  3. 隔离性（Isolation）：两个事务的执行是互不干扰的，两个事务时间不会互相影响。
  4. 持久性（Durability）：在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，并且是完全的。

    分布式事务与XA规范

    分布式事务是指会涉及到操作多个数据库的事务，同样需要保证ACID
    X/Open XA 定义了分布式事务处理的规范，并由数据库厂商在驱动层面进行实现。XA规范的基础是两阶段提交协议，并定义了分布式事务处理所涉及的角色：
  • 应用程序（AP）
  • 事务管理器（TM）——可以理解为事务处理中间件
  • 资源管理器（RM）——可以理解为各个数据库
  • 通信资源管理器（CRM）

    CAP定律和BASE理论

    CAP定律

    在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
  1. 一致性（C）

在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

  1. 可用性（A）

在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

  1. 分区容错性（P）

以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 :::info 分区容错性（P）主要代表网络波动产生的错误，这是不可避免的，且这三个模式不可兼得，目前就只有两种模式：**CP**和**AP**模式。

  • **CP**模式：遵循一致性原则，但不保证高可用，其中zookeeper作为注册中心就是采用CP模式，因为zookeeper有过半节点不可用的话，整个zookeeper将不可用。
  • **AP**模式：遵循可用性原则，但不保证强一致性，例如Eureka作为注册中心用的是AP模式，因为其为去中心化，采用你中有我我中有你的相互注册方式，只要集群中有一个节点可以使用，整个eureka服务就是可用的，但可能会出现短暂的数据不一致问题。 :::

    BASE理论

    BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
  1. Basically Available（基本可用）

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，注意，这绝不等价于系统不可用。 :::info 比如：

  1. 响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒。

  2. 系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。 :::

  3. Soft state（软状态）

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

  1. Eventually consistent（最终一致性）

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

分布式事务常见解决方案

  1. 2PC两阶段提交协议
  2. 3PC三阶段提交协议
  3. TCC或者阿里的GTS
  4. 使用LCN解决分布式事务。理念：“LCN并不生产事务,LCN只是本地事务的搬运工”
  5. 本地消息表（避免了分布式事务）

  6. 消息中间件最终一致性

    一、两阶段提交（2PC）

    两阶段提交协议（Two-phase commit protocol, 2PC）将一次分布式事务处理划分为两个阶段：预提交阶段（也称为准备阶段或投票阶段），提交阶段。
    两阶段提交协议可以在数据库层面通过驱动支持，也可以在应用框架中按照其原理进行设计实现。

    1.1 预提交阶段

    步骤：

  7. 事务询问：协调者 向所有的 参与者 发送事务预处理请求，称之为Prepare，并开始等待各 参与者 的响应。

  8. 执行本地事务：各个 参与者 节点执行本地事务操作,但在执行完成后并不会真正提交数据库本地事务，而是先向 协调者 报告说：“我这边可以处理了/我这边不能处理”。
  9. 各参与者向协调者反馈事务询问的响应：如果 参与者 成功执行了事务操作,那么就反馈给协调者 Yes 响应,表示事务可以执行,如果没有 参与者 成功执行事务,那么就反馈给协调者 No 响应,表示事务不可以执行。

第一阶段执行完后，会有两种可能：

  1. 所有都返回 Yes。

  2. 有一个或者多个返回 No。 :::tips 当一个数据库接收到咨询后，它会将需要执行的操作写入日志，禁止其他写入操作（锁定资源）。 ::: image.png

    1.2 提交阶段

    分布式事务处理系统对各个资源管理器下达提交/回滚的指令，使整个分布式事务结束。
    当一个数据库接受到提交/回滚指令时，它将根据第一阶段的日志进行提交/回滚处理。

    1.2.1 成功提交

    成功条件：所有参与者都返回yes
    步骤：

  3. 协调者 向所有 参与者 节点发出 commit 请求

  4. 参与者 收到 commit 请求之后，就会正式执行本地事务commit操作，并在完成提交之后释放整个事务执行期间占用的事务资源。

image.png

1.2.2 异常情况

异常条件：任何一个 参与者 向 协调者 反馈了 No 响应,或者等待超时之后,协调者尚未收到所有参与者的反馈响应。
步骤：

  1. 协调者 向所有 参与者 节点发出 RollBack 请求
  2. 参与者 收到 RollBack 请求之后，会回滚本地事务。

image.png

2PC的不足

  • 性能问题：无论是在第一阶段的过程中,还是在第二阶段,所有的参与者资源和协调者资源都是被锁住的,只有当所有节点准备完毕，事务协调者才会通知进行全局提交，参与者进行本地事务提交后才会释放资源。这样的过程会比较漫长，对性能影响比较大。
  • 单节点故障：由于协调者的重要性，一旦协调者发生故障，参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（虽然协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题） :::warning 2PC的数据不一致问题：在第二阶段，部分参与者已经执行完commit操作，但有参与者挂了，这时数据就会是不一致的。虽然这个时候可以再通过手段让它们和协调者通信，再想办法把数据搞成一致的，但是，这段时间内它们的数据状态已经是不一致的了！ 2PC 无法解决这个问题。 :::

    二、三阶段提交（3PC）

    三阶段提交协议主要是为了解决两阶段提交协议的阻塞问题，2pc存在的问题是当协作者崩溃时，参与者不能做出最后的选择，因此参与者可能在协作者恢复之前保持阻塞。
    3PC相较于2PC的改动点： :::info
  1. 同时在协调者和参与者中都引入了超时机制。
  2. 在第一阶段和第二阶段中插入了一个准备阶段，保证了在最后提交阶段之前各参与节点的状态是一致的。

3PC相对缓解了2PC中的前两个问题，但是依然没有完全解决数据不一致的问题。 :::

2.1 CanCommit阶段

步骤:

  1. 事务询问：协调者 向 参与者 发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待 参与者 的响应。

  2. 响应反馈：参与者 接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No。

    2.2 PreCommit阶段

    在阶段一中，如果所有的参与者都返回Yes的话，那么就会进入PreCommit阶段进行事务预提交。这里的PreCommit阶段 跟上面的第一阶段是差不多的，只不过这里 协调者和参与者都引入了超时机制 （2PC中只有协调者可以超时，参与者没有超时机制）。

    2.3 DoCommit阶段

    和2PC的阶段二差不多

    三、TCC（Try-Confirm-Cancel）

    3.1 Try

    尝试执行业务
    步骤:

  3. 完成所有业务检查，保证一致性

  4. 预留必须业务资源

    3.2 Confirm

    确认执行业务
    步骤:

  5. 真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源

Confirm操作要满足幂等性

3.3 Cancel

取消业务执行
步骤:

  1. 释放Try阶段预留的业务资源

Cancel操作要满足幂等性