分布式事务理论和解决方案

本地事务

本地事务，也就是传统的单机事务。在传统数据库事务中，必须要满足四个原则：

分布式事务问题

分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如：

• 跨数据源的分布式事务
• 跨服务的分布式事务
• 综合情况

在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例，包括下面几个行为：

• 创建新订单
• 扣减商品库存
• 从用户账户余额扣除金额

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。

订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。

但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。

此时ACID难以满足，这是分布式事务要解决的问题

------------另一种说法----------------------------------------------------------------------

business（下单）远程调用库存（storage）,保存订单（order），扣减积分（account），只有这三个步骤全部成功，我们的下订单才算成功。

如果是单体应用，我们将三处代码全部写在一个系统里面，而且我们全部连向的是一个数据库，这样的话我们使用本地事务就可以控制，只要有一个失败则全体回滚。

但是正是由于我们分布式系统的出现，由于我们业务太大，我们不可能将业务全写到一个系统里面，我们就拆分成了好多微服务，比如库存服务、订单服务、用户账户服务，而且每个服务还是连自己的数据库，操作自己的数据，还互相没有关系，
分布式系统之间部署还可能不在一块儿，库存服务在1号机器，订单服务在2号机器，用户账户服务在3号机器，这样我们想要完成下单逻辑，就需要远程调用这三个机器的各个方法，但由于我们分布式系统中经常会出现异常，

机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的 TCP、存储数据丢失…

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免。

分布式事务出现的原因，就是节点之间互相的状态不能同步，包括网络状况互相感知不到。

分布式事务解决理论

解决分布式事务问题，需要一些分布式系统的基础知识作为理论指导。

cap定理（cap和base都是理论）

CAP定理是说在P一定会出现的情况下，A和C之间只能实现一个

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

• Consistency（一致性）
• Availability（可用性）
• Partition tolerance （分区容错性）

它们的第一个字母分别是 C、A、P。

Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

一致性

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。

比如现在包含两个节点，其中的初始数据是一致的；当我们修改其中一个节点的数据时，两者的数据产生了差异；要想保住一致性，就必须实现node01 到 node02的数据 同步：

可用性

Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。

如图，有三个节点的集群，访问任何一个都可以及时得到响应：

当有部分节点因为网络故障或其它原因无法访问时，代表节点不可用：

分区容错

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

矛盾

在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance不可避免。

当节点接收到新的数据变更时，就会出现问题了：

如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。

如果此时要保证可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。

也就是说，在P一定会出现的情况下，A和C之间只能实现一个。

------------------------------ 另一种说法 ------------------------------------------

CAP 原则又称 CAP 定理，指的是在一个分布式系统中

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

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

3. 分区容错性（Partition tolerance）
   多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。
   分区容错的意思是，区间（服务器之间）通信可能失败。

CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

原因是：
123三台机器，我们让三个节点都保存a数据，这就满足了一致性

假设我们不是由于节点故障而是通信故障，13之间的网线断了，我们保存数据肯定只给某一个机器发了请求，1号机器让23同步，因为13之间网线断了，死活连不上，此时就发生了分区错误，

分区错误之后，假设我们想让它满足可用性，我们让3号机器恢复，比如我们负载均衡去3号机器读数据，但由于3号之前通信故障，数据没有同步过来，读到的数据自然就不一样了，所以一满足可用性就发现又不一致了。想要满足一致性，就必须让3号机器不能访问，不能访问就不可用了。所以一致性和可用性只能二选一。

在分布式系统中分区容错必须满足，因为网络肯定会出现问题；那么一致性与可用性就只能二选一，满足可用的话就得容忍业务能访问到不一致的数据，满足一致的话，就不能让整个集群可用了，如果让整个集群可用的话，数据就会不一致。

如何取舍

对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到99.99999%（N 个 9），即保证P 和 A，舍弃 C（一致性）。

base理论

BASE理论是对CAP的一种解决思路，包含三个思想：

• Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
• Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
• Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

-----------------------------另一种说法---------------------------------------------

是对 CAP 理论的延伸，思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但可以采用适当的采取弱一致性，即最终一致性。
BASE 是指

• 基本可用（Basically Available）

  • 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用。

    • 响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1~2 秒。

    • 功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。

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

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

• 强一致性、弱一致性、最终一致性
  从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性

解决分布式事务的思路

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：

• AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。

• CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

小知识：ES就是使用了AP模式。当有节点宕机时就会断开此节点，并将之前在此节点备份好的数据录入其他节点

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：

这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。

分布式事务解决方案

2PC

• 基于XA协议的两阶段提交(2PC)
• 二阶段提交2PC（Two phase Commit）是指，在分布式系统里，为了保证所有节点在进行事务提交时保持一致性的一种算法。
• 实现思路

有两个角色：协调者 和 参与者

（1）投票阶段：参与者将操作结果通知给协调者

（2）提交阶段：协调者收到参与者的通知后，根据参与者结果决定最终提交还是回滚

• 举例说明

甲 乙 丙 丁会议

• 缺陷：

1 强一致性

2 协调者单点故障问题

3 丢失消息

TCC

• TCC不是强一致性，保证最终一致性

本地消息表

• 执行流程：
  • 订单系统，添加一条订单和一条消息，在一个事务里提交。
  • 订单系统，使用定时任务轮询查询状态为未同步的消息表，发送到 MQ，如果发送失败，就重试发送。
  • 库存系统，接收 MQ 消息，修改库存表，需要保证幂等操作。
  • 如果修改成功，调用 RPC 接口修改订单系统消息表的状态为已完成或者直接删除这条消息。
  • 如果修改失败，可以不做处理，等待重试。

订单系统中的消息有可能由于业务问题会一直重复发送，所以为了避免这种情况可以记录一下发送次数，当达到次数限制之后报警，人工接入处理；库存系统需要保证幂等，避免同一条消息被多次消费造成数据一致。

------------------------------------另一种------------------------------------------------------

其核心思想是将分布式事务拆分成本地事务进行处理。

方案通过在消费者额外新建事务消息表，消费者处理业务和记录事务消息在本地事务中完成，轮询事务消息表的数据发送事务消息，提供者基于消息中间件消费事务消息表中的事务。

条件：

服务消费者需要创建一张消息表，用来记录消息状态。

服务消费者和提供者需要支持幂等。

需要补偿逻辑。

每个节点上起定时线程，检查未处理完成或发出失败的消息，重新发出消息，即重试机制和幂等性机制。

处理流程：

1. 服务消费者把业务数据和消息一同提交，发起事务。

2. 消息经过MQ发送到服务提供方，服务消费者等待处理结果。

3. 服务提供方接收消息，完成业务逻辑并通知消费者已处理的消息。

容错处理情况如下：

当步骤1处理出错，事务回滚，相当于什么都没有发生。

当步骤2、3处理出错，由于消息保存在消费者表中，可以重新发送到MQ进行重试。

如果步骤3处理出错，且是业务上的失败，服务提供者发送消息通知消费者事务失败，且此时变为消费者发起回滚事务进行回滚逻辑。

优点：从应用设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于消息中间件，弱化了对 MQ 中间件特性的依赖。

缺点：与具体的业务场景绑定，耦合性强，不可公用。消息数据与业务数据同库，占用业务系统资源。业务系统在使用关系型数据库的情况下，消息服务性能会受到关系型数据库并发性能的局限。

分布式事务的三种解决方案

• 其他问法：谈谈分布式事务的3种解决方案

在分布式系统中，分布式事务是一个复杂且关键的问题。以下将介绍分布式事务的三种常见解决方案。

两阶段提交（2PC）

1. 概念

两阶段提交是一种强一致性设计，通过协调者来统一掌控所有参与者的操作结果，并最终决定是否进行事务提交。它将事务的提交过程分为准备阶段和提交阶段。

2. 执行过程

准备阶段：协调者向所有参与者发送事务内容，询问是否可以执行事务操作，并等待参与者的响应。参与者执行事务操作，但不提交事务，将 undo 和 redo 信息记录到事务日志中，然后向协调者回复是否可以执行事务操作。

提交阶段：如果所有参与者都回复可以执行事务操作，协调者向所有参与者发送提交事务的请求。参与者接收到提交请求后，正式提交事务，并释放事务期间占用的资源。如果有任何一个参与者回复不能执行事务操作，协调者向所有参与者发送回滚事务的请求。参与者接收到回滚请求后，利用事务日志中的 undo 信息执行回滚操作，并释放事务期间占用的资源。

3. 优点

强一致性保证，事务要么全部成功，要么全部失败。

4. 缺点

同步阻塞问题，在执行过程中，所有参与者都处于阻塞状态，等待其他参与者的响应，性能较差。

单点问题，协调者一旦出现故障，整个系统将无法正常工作。

数据不一致风险，如果在提交阶段协调者向部分参与者发送了提交请求，而向另一部分参与者发送了回滚请求，可能会导致数据不一致。

三阶段提交（3PC）

1. 概念

三阶段提交是在两阶段提交的基础上进行改进，将事务的提交过程分为三个阶段：CanCommit、PreCommit 和 DoCommit。

2. 执行过程

CanCommit 阶段：协调者向所有参与者发送事务询问请求，询问是否可以执行事务操作，并等待参与者的响应。参与者检查自身状态，如果可以执行事务操作，则回复 Yes 并进入预备状态，否则回复 No。

PreCommit 阶段：如果所有参与者都回复 Yes，协调者向所有参与者发送预提交请求。参与者接收到预提交请求后，执行事务操作，并将 undo 和 redo 信息记录到事务日志中。然后向协调者回复 ACK 确认消息。如果有任何一个参与者回复 No 或者超时未回复，协调者向所有参与者发送中断事务的请求。参与者接收到中断事务的请求后，利用事务日志中的 undo 信息执行回滚操作，并释放事务期间占用的资源。

DoCommit 阶段：如果协调者接收到所有参与者的 ACK 确认消息，则向所有参与者发送提交事务的请求。参与者接收到提交请求后，正式提交事务，并释放事务期间占用的资源。如果协调者在超时时间内未接收到所有参与者的 ACK 确认消息，则向所有参与者发送中断事务的请求。参与者接收到中断事务的请求后，利用事务日志中的 undo 信息执行回滚操作，并释放事务期间占用的资源。

3. 优点

相比两阶段提交，降低了同步阻塞的时间，在参与者出现故障时，能够更快地中断事务。

4. 缺点

仍然存在单点问题，协调者一旦出现故障，整个系统将无法正常工作。

数据不一致风险虽然有所降低，但仍然存在。

补偿事务（TCC）

1. 概念

TCC 是一种基于业务层面的分布式事务解决方案，它将事务的提交过程分为三个阶段：Try、Confirm 和 Cancel。TCC 要求每个业务服务都实现三个接口：Try 接口用于尝试执行事务操作，Confirm 接口用于确认事务操作，Cancel 接口用于取消事务操作。

2. 执行过程

Try 阶段：尝试执行事务操作，完成所有业务检查（一致性），预留必须业务资源（准隔离性）。
Confirm 阶段：如果所有事务参与者的 Try 阶段都执行成功，则执行 Confirm 阶段，确认事务操作。Confirm 操作需要满足幂等性，即无论执行多少次，结果都是一样的。
Cancel 阶段：如果任何一个事务参与者的 Try 阶段执行失败，则执行 Cancel 阶段，取消事务操作。Cancel 操作也需要满足幂等性。

3. 优点

性能较好，相比两阶段提交和三阶段提交，TCC 不需要长时间的阻塞等待，可以快速地响应业务请求。

基于业务层面实现，灵活性高，可以根据不同的业务场景进行定制化开发。

4. 缺点

开发成本高，需要业务服务实现三个接口，并且需要考虑幂等性、悬挂等问题。

对业务有一定的侵入性，需要业务服务了解分布式事务的实现原理，并进行相应的代码改造。

TCC解决了base的什么问题

TCC（Try-Confirm-Cancel）主要解决了基于传统两阶段提交（2PC）的数据库事务（如基于 XA 协议的事务）中的一些问题，与 BASE（Basically Available, Soft-state, Eventually consistent）理念相关的方面主要有以下几点：

一、解决可用性问题

在传统的两阶段提交中，事务协调者在准备阶段会锁定所有参与事务的资源，直到提交或回滚阶段完成才释放资源。这期间如果协调者出现故障，或者某个参与者出现故障导致事务长时间阻塞，会极大地影响系统的可用性。

TCC 则将事务的执行过程分为三个阶段，在 Try 阶段只是预留资源而不真正锁定资源，使得其他事务仍然可以对这些资源进行访问，从而提高了系统的可用性。例如在电商系统中，下单时 Try 阶段只是冻结库存，而不是完全锁定库存，其他用户仍然可以查看商品信息和剩余库存数量，保证了系统基本可用。

二、适应软状态

BASE 强调系统存在中间的软状态，即允许系统在一定时间内处于不一致的状态，最终达到一致。TCC 允许在 Try 阶段后，系统处于一个临时的中间状态，例如在转账场景中，Try 阶段从转出账户扣除金额但未真正转入目标账户，此时系统处于一个软状态。如果 Confirm 阶段成功执行，系统达到最终一致状态；如果出现问题进入 Cancel 阶段，回滚事务使系统恢复到初始状态。

三、支持最终一致性

TCC 通过 Confirm 和 Cancel 阶段来保证事务的最终一致性。如果所有参与者的 Try 阶段都成功，那么协调者会发起 Confirm 阶段，确保事务的最终提交；如果在 Try 阶段或之后出现问题，协调者会发起 Cancel 阶段，回滚事务。这种方式符合 BASE 的最终一致性理念，允许系统在一段时间内存在不一致，但最终会达到一致状态。例如在分布式微服务架构中，多个服务之间的交互通过 TCC 模式可以在一定程度上容忍短暂的不一致，最终通过不断地重试和补偿机制实现数据的最终一致性。

todo 这篇文章的部分知识感觉需要重新消化或者整理感觉

部分内容引用自：
https://cloud.tencent.com/developer/article/2236312
https://zhuanlan.zhihu.com/p/665517818

第一，高端技术人才在适合的工作岗位，一定会显出他的价值来，然后在价值体系去评价他。我们可以设一个高端投诉平台，大家有问题就写邮件到这个平台，人力资源去听他倾诉，做成纪要报给有关部门帮助他调整。我们可以安排一些人际理解力强、熟悉华为流程、善于沟通、善于团结人的老员工，到导师部去听群众的声音，调节矛盾。

任正非