目录

  • 事务
  • 分布式事务
  • XA（2PC/3PC）
  • 2PC
  • 3PC
  • TCC
  • Saga模式
  • 半消息模式
  • 本地消息表模式
  • BASE
  • CAP
  • spring的@Transactional

事务

是一个程序执行单元，里面的所有操作要么全部执行成功，要么全部执行失败。

一个事务有四个基本特性，也就是我们常说的（ACID）：

• Atomicity（原子性）：事务是一个不可分割的整体，事务内所有操作要么全做成功，要么全失败。
• Consistency（一致性）：事务执行前后，数据从一个状态到另一个状态必须是一致的（A 向 B 转账，不能出现 A 扣了钱，B 却没收到）。
• Isolation（隔离性）：多个并发事务之间相互隔离，不能互相干扰。
• Durablity（持久性）：事务完成后，对数据的更改是永久保存的，不能回滚。

分布式事务

是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。分布式事务通常用于在分布式系统中保证不同节点之间的数据一致性。

分布式事务的解决方案一般有以下几种：

XA（2PC/3PC）

最具有代表性的是由 Oracle Tuxedo 系统提出的 XA 分布式事务协议。XA 中大致分为两部分：事务管理器和本地资源管理器。

其中本地资源管理器往往由数据库实现，比如 Oracle、DB2 这些商业数据库都实现了 XA 接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。如下：AP自己操作RM，当需要事务时，AP向TM请求发起事务，TM负责整个事务的提交，回滚等。

分布式事务和redisson 分布式事务和事务_分布式事务和redisson

  • AP，即应用，也就是我们的业务服务；
  • RM指的是资源管理器，即DB，MQ等；
  • TM则是事务管理器；

2PC

XA 协议通常包含两阶段提交（2PC）和三阶段提交（3PC）两种实现。两阶段提交顾名思义就是要进行两个阶段的提交：第一阶段，准备阶段(投票阶段)；第二阶段，提交阶段（执行阶段）。过程如下：

分布式事务和redisson 分布式事务和事务_分布式事务和redisson_02


分析整个2PC的过程，我们可以发现，事务的操作真正执行其实是在准备阶段，并且对于每个参与者来说，在整个事务阶段，资源都是锁定状态。也就是说，这种事务机制，为了达到事务目的，长时间锁定资源，导致承受并发的能力很低。这种无法应对并发的缺陷，其实是和分布式目的相背的。

3PC

三阶段提交协议（3PC）主要是为了解决两阶段提交协议的阻塞问题，2pc存在的问题是当协作者崩溃时，参与者不能做出最后的选择。因此参与者可能在协作者恢复之前保持阻塞。三阶段提交（Three-phase commit），是二阶段提交（2PC）的改进版本。

与两阶段提交不同的是，三阶段提交有两个改动点：

  1. 引入超时机制，同时在TM和AP中都引入超时机制；
  2. 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的;

也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

TCC

是 Try、Confirm、Cancel 三种指令的缩写，Try就是尝试，请求链路中每个参与者依次执行Try逻辑，如果都成功，就再执行Confirm逻辑，如果有失败，就执行Cancel逻辑。又被称补偿事务。

其逻辑模式类似于 XA 两阶段提交，事务处理流程也很相似，但 2PC 是应用于在 DB 层面，TCC 则可以理解为在应用层面的 2PC，弱化每个步骤中对于资源的锁定，以达到一个能承受高并发的目的（基于最终一致性），需要我们编写业务逻辑来实现。

TCC 它的核心思想是：“针对每个操作都要注册一个与其对应的确认（Try）和补偿（Cancel）”。

TCC是可以解决部分场景下的分布式事务的，但是，它的一个问题在于，需要每个参与者都分别实现Try，Confirm和Cancel接口及逻辑，这对于业务的侵入性是巨大的。

Saga模式

SAGA模型是在1987年，由普林斯顿大学的Hector Garcia-Molina和Kenneth Salem提出，它的核心思想是，通过某种方案，将分布式事务转化为本地事务，从而降低问题的复杂性。

半消息模式

分布式事务和redisson 分布式事务和事务_事务管理_03

半消息和普通消息的唯一区别是，在事务提交之前，对于消费者来说，这个消息是不可见的

原理如下：

分布式事务和redisson 分布式事务和事务_分布式事务和redisson_04


虽然上面的方案能够完成 A 和 B 的操作，但是 A 和 B 并不是强一致的，而是最终一致（Eventually consistent）的。

本地消息表模式

在DB中，新增一个消息表，用于存放消息。如下：

  1. 在DB业务表中插入数据；
  2. 在DB消息表中插入数据；
  3. 异步将消息表中的消息发送到MQ，收到ack后，删除消息表中的消息

BASE

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写
//todo

CAP

//todo

spring的@Transactional

//todo