传统事务和分布式事务

事务

1. 事务理论

1. ACID

   ACID是传统数据库常用的设计理念，追求强一致性模型。

   • 原子性（Atomicity） 所作出的改变是原子操作，不可分割

   • 一致性（Consistency） 数据库的状态始终保持一致

   • 隔离性（Isolation） 即使事务并发执行，但他们看起来更像是串行执行

   • 永久性（Durable） 一旦事务提交，它将不可撤销

2. CAP

   CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

   • 一致性（Consistency）

   一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。

   • 可用性（Availability）

   可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。

   • 分区容错性（Partition tolerance）

   分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

   通过CAP理论，我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要舍弃哪个呢？

   对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流程的严重程度。

   对于涉及到钱财这样不能有一丝让步的场景，C必须保证。网络发生故障宁可停止服务，这是保证CA，舍弃P。貌似这几年国内银行业发生了不下10起事故，但影响面不大，报到也不多，广大群众知道的少。还有一种是保证CP，舍弃A。例如网络故障事只读不写。

   孰优孰略，没有定论，只能根据场景定夺，适合的才是最好的。

3. BASE

   BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。

   • 基本可用（Basically Available）

     基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。

     电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

   • 软状态（ Soft State）

     软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

   • 最终一致性（ Eventual Consistency）

     最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

2. 分布式事务

分布式事物基本理论:基本遵循CPA理论，采用柔性事物特征，软状态或者最终一致性特点保证分布式事物一致性问题。

分布式事物常见解决方案:

1. 2PC两段提交协议
2. 3PC三段提交协议(弥补两端提交协议缺点)
3. TCC或者GTS(阿里)
4. 消息中间件最终一致性
5. 使用LCN解决分布式事物，理念“LCN并不生产事务,LCN只是本地事务的搬运工”。

一、两阶段提交（2PC）

2PC：coordinator(协调者节点)两次调用participant（参与者节点）

两次调用：Prepare，Commit

两阶段提交又称2PC,2PC是一个非常经典的强一致、中心化的原子提交协议。

这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（Participant）。

两个阶段：第一阶段：投票阶段 和第二阶段：提交/执行阶段。

举例 订单服务A，需要调用 支付服务B 去支付，支付成功则处理购物订单为待发货状态，否则就需要将购物订单处理为失败状态。

那么看2PC阶段是如何处理的

1、第一阶段：投票阶段

第一阶段主要分为3步

1）事务询问

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

2）执行本地事务

各个 参与者 节点执行本地事务操作,但在执行完成后并不会真正提交数据库本地事务，而是先向 协调者 报告说：“我这边可以处理了/我这边不能处理”。.

3）各参与者向协调者反馈事务询问的响应

如果 参与者 成功执行了事务操作,那么就反馈给协调者 Yes 响应,表示事务可以执行,如果没有 参与者 成功执行事务,那么就反馈给协调者 No 响应,表示事务不可以执行。

第一阶段执行完后，会有两种可能。1、所有都返回Yes. 2、有一个或者多个返回No。

2、第二阶段：提交/执行阶段（成功流程）

成功条件：所有参与者都返回Yes。

第二阶段主要分为两步

​ 1)所有的参与者反馈给协调者的信息都是Yes,那么就会执行事务提交

​ 协调者 向 所有参与者 节点发出Commit请求.

​ 2)事务提交

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

3、第二阶段：提交/执行阶段（异常流程）

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

异常流程第二阶段也分为两步

​ 1)发送回滚请求

​ 协调者 向所有参与者节点发出 RoollBack 请求.

​ 2)事务回滚

4、2PC缺点

通过上面的演示，很容易想到2pc所带来的缺陷

1）性能问题

无论是在第一阶段的过程中,还是在第二阶段,所有的参与者资源和协调者资源都是被锁住的,只有当所有节点准备完毕，事务 协调者 才会通知进行全局提交，

参与者 进行本地事务提交后才会释放资源。这样的过程会比较漫长，对性能影响比较大。

2）单节点故障

由于协调者的重要性，一旦 协调者 发生故障。参与者 会一直阻塞下去。尤其在第二阶段，协调者 发生故障，那么所有的 参与者 还都处于

锁定事务资源的状态中，而无法继续完成事务操作。（虽然协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

2PC出现单点问题的三种情况

(1)协调者正常,参与者宕机

​ 由于 协调者 无法收集到所有 参与者 的反馈，会陷入阻塞情况。

​ 解决方案:引入超时机制,如果协调者在超过指定的时间还没有收到参与者的反馈,事务就失败,向所有节点发送终止事务请求。

(2)协调者宕机,参与者正常

​ 无论处于哪个阶段，由于协调者宕机，无法发送提交请求，所有处于执行了操作但是未提交状态的参与者都会陷入阻塞情况.

​ 解决方案:引入协调者备份,同时协调者需记录操作日志.当检测到协调者宕机一段时间后，协调者备份取代协调者，并读取操作日志，向所有参与者询问状态。

(3)协调者和参与者都宕机

1. 发生在第一阶段： 因为第一阶段，所有参与者都没有真正执行commit，所以只需重新在剩余的参与者中重新选出一个协调者，新的协调者在重新执行第一阶段和第二阶段就可以了。

2)发生在第二阶段 并且 挂了的参与者在挂掉之前没有收到协调者的指令。也就是上面的第4步挂了，这是可能协调者还没有发送第4步就挂了。这种情形下，新的协调者重新执行第一阶段和第二阶段操作。

3)发生在第二阶段 并且 有部分参与者已经执行完commit操作。就好比这里订单服务A和支付服务B都收到协调者 发送的commit信息，开始真正执行本地事务commit,但突发情况，Acommit成功，B确挂了。这个时候目前来讲数据是不一致的。虽然这个时候可以再通过手段让他和协调者通信，再想办法把数据搞成一致的，但是，这段时间内他的数据状态已经是不一致的了！ 2PC 无法解决这个问题。

二、三阶段提交(3PC)

3PC：coordinator(协调者节点)三次次调用participant（参与者节点）

三次调用：CanCommit，PreCommit，DoCommit

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

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

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

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

1、CanCommit阶段

之前2PC的一阶段是本地事务执行结束后，最后不Commit,等其它服务都执行结束并返回Yes，由协调者发生commit才真正执行commit。而这里的CanCommit指的是 尝试获取数据库锁 如果可以，就返回Yes。

这阶段主要分为2步

事务询问 协调者 向 参与者 发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待 参与者 的响应。
响应反馈 参与者 接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

2、PreCommit阶段

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

3、DoCommit阶段

这里跟2pc的阶段二是差不多的。

总结

​ 相比较2PC而言，3PC对于协调者（Coordinator）和参与者（Participant）都设置了超时时间，而2PC只有协调者才拥有超时机制。这解决了一个什么问题呢？

这个优化点，主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，

自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。

​ 另外，通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。

以上就是3PC相对于2PC的一个提高（相对缓解了2PC中的前两个问题），但是3PC依然没有完全解决数据不一致的问题。

三、补偿事务（TCC）

TCC: Try、Confirm、Cancel

我的理解：2PC、3PC还有TCC都蛮相似的。3PC大致是把2PC的第一阶段拆分成了两个阶段，而TCC我感觉是把2PC的第二阶段拆分成了两个阶段

1. 概念

   TCC又称补偿事务。其核心思想是：“针对每个操作都要注册一个与其对应的确认和补偿（撤销操作）”。它分为三个操作：

   1、Try阶段：主要是对业务系统做检测及资源预留。
   2、Confirm阶段：确认执行业务操作。
   3、Cancel阶段：取消执行业务操作。
   

   TCC对应 Try、Confirm、Cancel 三种操作可以理解成关系型数据库事务的三种操作：DML、Commit、Rollback。

   在一个跨应用的业务操作中

   • Try：Try操作是先把多个应用中的业务资源预留和锁定住，为后续的确认打下基础，类似的，DML操作要锁定数据库记录行，持有数据库资源。

   • Confirm：Confirm操作是在Try操作中涉及的所有应用均成功之后进行确认，使用预留的业务资源，和Commit类似；

   • Cancel：Cancel则是当Try操作中涉及的所有应用没有全部成功，需要将已成功的应用进行取消(即Rollback回滚)。其中Confirm和Cancel操作是一对反向业务操作。

   TCC的具体原理图如（盗图）:
   

   从图中我们可以明显看到Confirm和Cancel操作是一对反向业务操作 即要try返回成功执行Confirm,要么try返回失败执行Cancel操作。

   分布式事务协调者：分布式事务协调者管理控制整个业务活动，包括记录维护TCC全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时确认所有的TCC型

   操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作。

2. 举例

   例子：A服务转30块钱、B服务转50块钱，一起到C服务上。

   1. Try：尝试执行业务。完成所有业务检查(一致性)：检查A、B、C的帐户状态是否正常，帐户A的余额是否不少于30元，帐户B的余额是否不少于50元。预留必须业务资源(准隔离性)：帐户A的冻结金额增加30元，帐户B的冻结金额增加50元，这样就保证不会出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中，帐户A和B的可用余额不够的情况。
   2. Confirm：确认执行业务。真正执行业务：如果Try阶段帐户A、B、C状态正常，且帐户A、B余额够用，则执行帐户A给账户C转账30元、帐户B给账户C转账50元的转帐操作。 这时已经不需要做任何业务检查，Try阶段已经完成了业务检查。只使用Try阶段预留的业务资源：只需要使用Try阶段帐户A和帐户B冻结的金额即可。
   3. Cancel：取消执行业务释放Try阶段预留的业务资源：如果Try阶段部分成功，比如帐户A的余额够用，且冻结相应金额成功，帐户B的余额不够而冻结失败，则需要对帐户A做Cancel操作，将帐户A被冻结的金额解冻掉。

3. TCC和2PC比较

   2PC是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。

   XA事务中的两阶段提交内部过程是对开发者屏蔽的，事务管理器在两阶段提交过程中，从prepare到commit/rollback过程中，资源实际上一直都是被加锁的。

   如果有其他人需要更新这两条记录，那么就必须等待锁释放。

   TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。

   我的理解就是当执行try接口的时候，已经把所需的资源给预扣了，比如上面举例的A服务已经预扣30元，B服务已经预扣50元，它是由try接口实现，这样就保证不会

   出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中，帐户A和B的可用余额不够的情况，同时保证不会一直锁住整个资源。（核心点应该就在这）

   TCC中的两阶段提交并没有对开发者完全屏蔽，也就是说从代码层面，开发者是可以感受到两阶段提交的存在。

   1、try过程的本地事务，是保证资源预留的业务逻辑的正确性。

   2、confirm/cancel执行的本地事务逻辑确认/取消预留资源，以保证最终一致性，也就是所谓的补偿型事务。

   由于是多个独立的本地事务，因此不会对资源一直加锁。

   总的来讲
   TCC 实质上是应用层的2PC，好比把 XA 两阶段提交那种在数据资源层做的事务管理工作提到了数据应用层。

   2PC是资源层面的分布式事务，是强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。

   TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。

   TCC相比较于2PC来讲性能会好很多，但是因为同时需要改造try、confirm、canel3个接口，开发成本高。

   注意 还有一点需要注意的是Confirm和Cancel操作可能被重复调用，故要求Confirm和Cancel两个接口必须是幂等。

四、RocketMQ实现分布式事务原理

• 一、举个分布式事务场景

  列子：假设 A 给 B 转 100块钱，同时它们不是同一个服务上。

  目标：就是 A 减100块钱，B 加100块钱。

  实际情况可能有四种：

  1）就是A账户减100 （成功），B账户加100 （成功）
  
  2）就是A账户减100（失败），B账户加100 （失败）
  
  3）就是A账户减100（成功），B账户加100 （失败）
  
  4）就是A账户减100 （失败），B账户加100 （成功）
  

  这里 第1和第2 种情况是能够保证事务的一致性的，但是 第3和第4 是无法保证事务的一致性的。

  那我们来看下RocketMQ是如何来保证事务的一致性的。

• 二、RocketMQ实现分布式事务原理

  RocketMQ虽然之前也支持分布式事务，但并没有开源，等到RocketMQ 4.3才正式开源。

  1、基础概念

  1. 最终一致性

     RocketMQ是一种最终一致性的分布式事务，就是说它保证的是消息最终一致性，而不是像2PC、3PC、TCC那样强一致分布式事务，至于为什么说它是最终一致性事务下面会详细说明。

  2. Half Message(半消息)

     半消息是指暂不能被Consumer消费的消息。Producer 已经把消息成功发送到了 Broker 端，但此消息被标记为暂不能投递状态，处于该种状态下的消息称为半消息。需要 Producer对消息的二次确认后，Consumer才能去消费它。

  3. 消息回查

     由于网络闪段，生产者应用重启等原因。导致 Producer 端一直没有对 Half Message(半消息) 进行 二次确认。这是Brock服务器会定时扫描长期处于半消息的消息，会主动询问 Producer端 该消息的最终状态(Commit或者Rollback),该消息即为 消息回查。

  2、分布式事务交互流程

  理解这张阿里官方的图，就能理解RocketMQ分布式事务的原理了。

  

  我们来说明下上面这张图

  1. A服务先发送个Half Message给Brock端，消息中携带 B服务 即将要+100元的信息。
  2. 当A服务知道Half Message发送成功后，那么开始第3步执行本地事务。
  3. 执行本地事务(会有三种情况1、执行成功。2、执行失败。3、网络等原因导致没有响应)
     1. 如果本地事务成功，那么Product像Brock服务器发送Commit,这样B服务就可以消费该message。
     2. 如果本地事务失败，那么Product像Brock服务器发送Rollback,那么就会直接删除上面这条半消息。
     3. 如果因为网络等原因迟迟没有返回失败还是成功，那么会执行RocketMQ的回调接口,来进行事务的回查。

  从上面流程可以得知 只有A服务本地事务执行成功 ，B服务才能消费该message。然后我们再来思考几个问题？

  • 为什么要先发送Half Message(半消息)

    我觉得主要有两点

    ​ 1）可以先确认 Brock服务器是否正常 ，如果半消息都发送失败了 那说明Brock挂了。

    ​ 2）可以通过半消息来回查事务，如果半消息发送成功后一直没有被二次确认，那么就会回查事务状态。什么情况会回查

    也会有两种情况

    ​ 1）执行本地事务的时候，由于突然网络等原因一直没有返回执行事务的结果(commit或者rollback)导致最终返回UNKNOW，那么就会回查。

    ​ 2) 本地事务执行成功后，返回Commit进行消息二次确认的时候的服务挂了，在重启服务那么这个时候在brock端它还是个Half Message(半消息)，这也会回查。

    特别注意: 如果回查，那么一定要先查看当前事务的执行情况，再看是否需要重新执行本地事务。

    想象下如果出现第二种情况而引起的回查，如果不先查看当前事务的执行情况，而是直接执行事务，那么就相当于成功执行了两个本地事务。

  • 为什么说MQ是最终一致性事务

    通过上面这幅图，我们可以看出，在上面举例事务不一致的两种情况中，永远不会发生：

    A账户减100 （失败），B账户加100 （成功）

    因为：如果A服务本地事务都失败了，那B服务永远不会执行任何操作，因为消息压根就不会传到B服务。

    那么 A账户减100 （成功），B账户加100 （失败） 会不会可能存在的。

    答案是会的

    因为A服务只负责当我消息执行成功了，保证消息能够送达到B,至于B服务接到消息后最终执行结果A并不管。

    那B服务失败怎么办？

    如果B最终执行失败，几乎可以断定就是代码有问题所以才引起的异常，因为消费端RocketMQ有重试机制，如果不是代码问题一般重试几次就能成功。

    如果是代码的原因引起多次重试失败后，也没有关系，将该异常记录下来，由人工处理，人工兜底处理后，就可以让事务达到最终的一致性。