分布式事务

既然说起分布式事务，那么什么是分布式事务呢？简单来说就是说传统的单体系统架构、单体数据库已经无法满足海量的用户需求，这个时候就需要对原有系统进行升级改造，对大规模的流量进行分解到不同的应用服务中，数据也分散在不同服务器的数据库中存储，这样的结果就是对于数据的增删改查操作就会变得更加复杂，尤其是难以保证数据的一致性，那么这也就是常说的分布式事务了。

分布式事务理论基础

说到分布式事务，那么就一定会想到分布式事务相关的两个理论知识，CAP 理论、Base 理论

CAP 理论

什么是 CAP 理论？CAP 理论，指的是在一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，不能同时成立。

一致性

在互联网领域中，不管是哪家企业，数据的存储往往都不会是单份的，那么一致性就是指用户对数据的更新操作在数据库的所有副本中要么都执行成功，要么都执行失败。也就是说一致性要求所有数据节点的副本数据的更新是原子性操作，所有数据节点的副本数据都是最新的，用户从任意的数据节点请求到的都是数据的最新状态。

可用性

可用性就是说用户请求数据的时候，可以快速的得到响应，虽然每个存储节点的数据可能会不一致，但是出于可用性状态的系统，任何事务的操作都可以得到响应的结果，不会存在超时或者响应错误的情况，只是存在返回的不是最新数据或者说返回旧数据的情况。

分区容错性

分区容错性就是说如果存储系统部署的只有一个节点，那么节点挂掉，整个系统将无服务可用。那么将存储系统部署在不同的节点上，并且这些节点处于不同的网络中，这样就形成了网络分区，此时，即使其中一个节点不能对外提供服务了，其他节点还可以正常服务，整个系统处于可用状态。

Base 理论

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

基本可用

基本可用就是说当系统发生故障时，允许损失系统的部分可用性，比如响应时间或者部分功能，但是要保证系统基本可用。比如在电商场景中，积分功能故障时，商品下单功能不受影响，或者下单功能故障，加购物车或浏览商品功能不受影响。

软状态

这个软状态就是说可以允许存在一个中间状态，比如支付中，而不是只有待支付、支付成功、支付失败的状态，这些中间状态不影响系统的整体可用性，知识允许系统各个节点之间存在延迟。

最终一致性

最终一致性就是说最后各个数据副本的状态达到一致，而不是要求各个数据副本状态值实时一致，比如支付中的状态，最后都会变成支付成功的最终状态。

分布式事务解决方案

基于分布式事务的理论基础，那么分布式事务的解决方案可以分为强一致性解决方案和最终一致性解决方案。

强一致性解决方案

什么是强一致性解决方案呢？顾名思义，就是说不管在任意时刻查询参与全局事务的各节点的数据，返回的数据都是一致的。

最常见的比如银行转账的场景，你不能说对方都收到钱了，你这边账户还没有扣款；或者说你这边都已经扣款了，但是对方迟迟没收到钱，这些都是双方不能容忍的，因而就必须用强一致性解决方案，保证应用程序在任何时间，任意节点的数据都是最新的。

强一致性最常见的两种模型：2PC 模型、3PC 模型

2PC 模型

2PC 模型的执行流程

Prepare 阶段，TM 会向每个参与全局事务的 RM 发送 Prepare 消息，RM 要么返回失败，要么在本地执行相应的事务，同时将事务写入本地的 Redo Log 和 Undo Log 文件中，但是此时事务并没有提交。

Commit 阶段，如果 TM 收到了参与全局事务的 RM 返回的失败消息，那么 TM 直接给 Prepare 阶段返回成功消息的 RM 发送回滚消息；反之，则给每个 RM 发送 Commit 消息，相应的 RM 根据 TM 发送过来的消息指令，执行对应事务的回滚或者提交操作，并且释放事务处理过程中使用的锁资源。

2PC 存在的问题

同步阻塞：事务执行过程中，所有参与事务的节点都会对其占用的公共资源加锁，导致其他访问公共资源的线程或者进程阻塞。

单点故障：如果 TM 故障，则 RM 会一直阻塞。

数据不一致：如果 Commit 阶段部分 RM 没有接收到 TM 发送的 Commit 指令，会引起数据不一致。

3PC 模型

3PC 模型执行流程

3PC 模型是把 2PC 模型的 Prepare 阶段分为两个阶段，同时引入了超时机制。

CanCommit 阶段，TM 向参与全局事务的 RM 发送 CanCommit 消息，RM 收到消息 后认为能够执行事务，会向 TM 响应 Yes 消息，进入预备状态。

PreCommit 阶段，TM 向参与全局事务的 RM 发送 PreCommit 消息，RM 收到消息后，执行事务操作，将 Undo 和 Redo 日志写入日志文件，并向 TM 响应 Ack 状态，但是此时不会提交事务，如果任何一个 RM 向 TM 反馈了 No 或者等待超时后，TM 无法接收到所有参与者的反馈，那么就会中断事务，TM 向所有参与者发送 abort 请求，或者响应超时自动中断事务。

doCommit 阶段，如果 TM 收到了所有全局事务参与 RM 响应的 Ack 状态，则 TM 向参与全局事务的 RM 发送 doCommit 消息，RM 接收到消息后正式提交事务，并释放执行事务期间占用的资源，同时向 TM 响应事务 Ack 消息，TM 收到 RM 响应的事务已提交状态，完成事务提交。

3PC 问题

与 2PC 模型相比，3PC 主要解决了单点故障问题，减少了事务执行过程中的阻塞现象，但是如果 RM 无法及时收到 TM 发送的消息，那么 RM 就会执行提交事务操作，而不是一直处于占用资源阻塞状态，因而这种机制也会导致数据不一致问题。

最终一致性解决方案

最终一致性解决方案就是说并不要求参与事务的各个节点的数据时刻保持一致，而是允许有一个中间状态，在一段时间后，能够达到数据的最终一致状态就可以。

优点：性能比较高，适合高并发场景，具备可用性。

缺点：某一时刻查询到的数据可能会不一致，对于事务一致性要求高的场景不适用。