分布式系统原理

高可用是指系统无中断的执行功能的能力，代表了系统的可用程度，是进行系统设计时必须要遵守的准则之一。
而高可用的实现方案，无外乎就是冗余，就存储的高可用而言，问题不在于如何进行数据备份，而在于如何规避数据不一致对业务造成的影响。
对于分布式系统而言，要保证分布式系统中的数据一致性就需要一种方案，可以保证数据在子系统中始终保持一致，避免业务出现问题。
这种实现方案就叫做分布式事务，要么一起成功，要么一起失败，必须是一个整体性的事务。

1、理论基础

1.1 CAP

CAP，Consistency Availability Partition tolerance 的简写：

Consistency：一致性，对某个客户端来说，读操作能够返回最新的写操作结果。
Availability：可用性，非故障节点在合理的时间内返回合理的响应。
Partition tolerance：分区容错性，分布式系统中系统肯定部署在多台机器上，无法保证网络做到 100% 的可靠，所以网络分区一定存在，即 P 一定存在。

在出现网络分区后，就出现了可用性和一致性的问题，我们必须要在这两者之间进行取舍，因此就有了两种架构：

• CP 架构

• AP 架构

1.2  BASE理论

BASE 理论指的是基本可用 Basically Available，软状态 Soft State，最终一致性 Eventual Consistency，核心思想是即便无法做到强一致性，但应该采用适合的方式保证最终一致性。

BASE，Basically Available  Soft State  Eventual Consistency 的简写：
BA：Basically Available 基本可用，分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
S：Soft State 软状态，允许系统存在中间状态，而该中间状态不会影响系统整体可用性。
E：Consistency 最终一致性，系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

BASE 理论本质上是对 CAP 理论的延伸，是对 CAP 中 AP 方案的一个补充。

2、分布式事务协议

2.1  二阶段提交协议:2PC

2.1.1 概述

二阶段提交（Two-phase Commit），是指，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法（Algorithm）。通常，二阶段提交也被称为是一种协议（Protocol）。

在分布式系统中，每个节点虽然可以知晓自己的操作是成功或者失败，却无法知道其他节点的操作是成功或失败。

当一个事务跨越多个节点时，为了保持事务的 ACID 特性，需要引入一个作为协调者的组件来统一掌控所有节点（称作参与者）的操作结果并最终指示这些节点是否要把操作结果进行真正的提交（比如将更新后的数据写入磁盘等等）。

因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

2.1.2  二阶段提交过程

• 投票阶段

投票阶段执行流程：

1. 协调者向所有参与者询问是否可以执行提交操作，并开始等待各参与者的响应。

2. 参与者执行事务操作，如果执行成功就返回 Yes 响应，如果执行失败就返回 No 响应。

3. 如果协调者接受参与者响应超时，也会认为执行事务操作失败。

• 提交阶段

提交阶段执行流程：

1. 如果第一阶段汇总所有参与者都返回 Yes 响应，协调者向所有参与者发出提交请求，所有参与者提交事务。

2. 如果第一阶段中有一个或者多个参与者返回 No 响应，协调者向所有参与者发出回滚请求，所有参与者进行回滚操作。

2.1.3 优缺点

• 优点
  尽量保证了数据的强一致，但不是 100% 一致

• 缺点

1. 单点故障，由于协调者的重要性，一旦协调者发生故障，参与者会一直阻塞，尤其是在第二阶段，协调者发生故障，那么所有的参与者都处于锁定事务资源的状态中，而无法继续完成事务操作。

2. 同步阻塞，由于所有节点在执行操作时都是同步阻塞的，当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

3. 数据不一致，在第二阶段中，当协调者向参与者发送提交事务请求之后，发生了局部网络异常或者在发送提交事务请求过程中协调者发生了故障，这会导致只有一部分参与者接收到了提交事务请求。
   而在这部分参与者接到提交事务请求之后就会执行提交事务操作。但是其他部分未接收到提交事务请求的参与者则无法提交事务。从而导致分布式系统中的数据不一致。

2.2  三阶段提交协议:3PC

2.2.1 概述

三阶段提交（Three-phase commit），是为解决两阶段提交协议的缺点而设计的。与两阶段提交不同的是，三阶段提交是“非阻塞”协议。

三阶段提交在两阶段提交的第一阶段与第二阶段之间插入了一个准备阶段，使得原先在两阶段提交中，参与者在投票之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。

2.2.2 三阶段提交过程

询问阶段：CanCommit
协调者向参与者发送 Commit 请求，参与者如果可以提交就返回 Yes 响应，否则返回 No 响应。

准备阶段：PreCommit
协调者根据参与者在询问阶段的响应判断是否执行事务还是中断事务：
如果所有参与者都返回 Yes，则执行事务。
如果参与者有一个或多个参与者返回 No 或者超时，则中断事务。
参与者执行完操作之后返回 ACK 响应，同时开始等待最终指令

提交阶段：DoCommit
协调者根据参与者在准备阶段的响应判断是否执行事务还是中断事务：
如果所有参与者都返回正确的 ACK 响应，则提交事务。
如果参与者有一个或多个参与者收到错误的 ACK 响应或者超时，则中断事务。
如果参与者无法及时接收到来自协调者的提交或者中断事务请求时，会在等待超时之后，会继续进行事务提交。
协调者收到所有参与者的 ACK 响应，完成事务。

2.2.3  解决二阶段提交时的问题：

三阶段提交解决了二阶段提交中存在的由于协调者和参与者同时挂掉可能导致的数据一致性问题和单点故障问题，并减少阻塞。
因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行提交事务（三阶段），而不会一直持有事务资源并处于阻塞状态（二阶段会）。

2.2.4  三阶段提交的问题：

在提交阶段如果发送的是中断事务请求，但是由于网络问题，导致部分参与者没有接到请求。
那么参与者会在等待超时之后执行提交事务操作，这样这些由于网络问题导致提交事务的参与者的数据就与接受到中断事务请求的参与者存在数据不一致的问题。

所以无论是 2PC 还是 3PC 都不能保证分布式系统中的数据 100% 一致。

3、最终一致性分布式事务方案

3.1 本地消息表

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

例如，在订单系统新增一条消息表，将新增订单和新增消息放到一个事务里完成，然后通过轮询的方式去查询消息表，将消息推送到 MQ，库存系统去消费 MQ。

执行流程：

1. 订单系统，添加一条订单和一条消息，在一个事务里提交。

2. 订单系统，使用定时任务轮询查询状态为未同步的消息表，发送到 MQ，如果发送失败，就重试发送。

3. 库存系统，接收 MQ 消息，修改库存表，需要保证幂等操作。

4. 如果修改成功，调用 RPC 接口修改订单系统消息表的状态为已完成或者直接删除这条消息。
   如果修改失败，可以不做处理，等待重试。

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

本地消息表这种方案实现了最终一致性，需要在业务系统里增加消息表，业务逻辑中多一次插入的 DB 操作，所以性能会有损耗，而且最终一致性的间隔主要由定时任务的间隔时间决定。

3.2 MQ 消息事务

消息事务的原理是将两个事务通过消息中间件进行异步解耦。

从上面可以看出，消息事务一定要保证业务操作与消息发送的一致性，如果业务操作成功，这条消息也一定投递成功。

消息事务依赖于消息中间件的事务消息，基于消息中间件的二阶段提交实现的，RocketMQ 就支持事务消息。RabbitMQ也支持事务消息

执行流程：

1. 发送 Prepare 消息到消息中间件。

2. 发送成功后，执行本地事务。

3. 如果事务执行成功，则 Commit，消息中间件将消息下发至消费端。

4. 如果事务执行失败，则回滚，消息中间件将这条 Prepare 消息删除。

5. 消费端接收到消息进行消费，如果消费失败，则不断重试。

这种方案也是实现了最终一致性，对比本地消息表实现方案，不需要再建消息表，不再依赖本地数据库事务了，所以这种方案更适用于高并发的场景。

3.3 最大努力通知

最大努力通知相比前两种方案实现简单，适用于一些最终一致性要求较低的业务，比如支付通知，短信通知这种业务。
以支付通知为例，业务系统调用支付平台进行支付，支付平台进行支付，进行操作支付之后支付平台会尽量去通知业务系统支付操作是否成功，但是会有一个最大通知次数。
如果超过这个次数后还是通知失败，就不再通知，业务系统自行调用支付平台提供一个查询接口，供业务系统进行查询支付操作是否成功。

执行流程：

1. 业务系统调用支付平台支付接口， 并在本地进行记录，支付状态为支付中。

2. 支付平台进行支付操作之后，无论成功还是失败，都需要给业务系统一个结果通知。

3. 如果通知一直失败则根据重试规则进行重试，达到最大通知次数后，不再通知。

4. 支付平台提供查询订单支付操作结果接口。

5. 业务系统根据一定业务规则去支付平台查询支付结果。

这种方案也是实现了最终一致性。

3.4 补偿事务 TCC

TCC，Try-Confirm-Cancel 的简称，针对每个操作，都需要有一个其对应的确认和取消操作。
当操作成功时调用确认操作，当操作失败时调用取消操作，类似于二阶段提交，只不过是这里的提交和回滚是针对业务上的，所以基于 TCC 实现的分布式事务也可以看做是对业务的一种补偿机制。

3.4.1 TCC 的三个阶段：

• Try 阶段：对业务系统做检测及资源预留、冻结。

• Confirm 阶段：对业务系统做确认提交，Try 阶段执行成功并开始执行 Confirm 阶段时，默认 Confirm 阶段是不会出错的。即：只要 Try 成功，Confirm 一定成功。

• Cancel 阶段：在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

在 Try 阶段，是对业务系统进行检查及资源预览，比如订单和存储操作，需要检查库存剩余数量是否够用，并进行预留，预留操作的话就是新建一个可用库存数量字段，Try 阶段操作是对这个可用库存数量进行操作。

3.4.2  TCC执行流程：

步骤一(Try 阶段)：订单系统将当前订单状态设置为支付中，库存系统校验当前剩余库存数量是否大于 2，然后将可用库存数量设置为库存剩余数量 -2，并且设置冻结库存为2

步骤二(Confirm 阶段)：如果 Try 阶段执行成功，执行 Confirm 阶段，将订单状态修改为支付成功，库存剩余数量修改为可用库存数量。

步骤三(Cancel 阶段)：如果 Try 阶段执行失败，执行 Cancel 阶段，将订单状态修改为支付失败，可用库存数量修改为库存剩余数量。

3.4.3 基于 TCC 实现的分布式事务框架：

ByteTCC，github.com/liuyangming
tcc-transaction：github.com/changmingxi

「更多精彩内容请关注我的公众号，喜欢的请分享给更多的朋友哦」