分布式事务详解及解决方案

分布式事务基本概念

举例：

市场交易
一手交钱 一手交货

这就是一个简单的事务，交钱和交货必须全部成功，整个事务才算成功，任何一个活动失败，事务将撤销所有已成功的活动。

事务可以看做是一次大的活动，大的活动由一个个小的活动组成，要么全部成功，要么全部失败。

本地事务

首先我们先了解一下什么是本地事务

在计算机系统中，更多地是通过关系型数据库来控制事务，这是利用数据库本身的特性来实现的，因此叫数据库事务，而数据库通常和应用在同一个服务器，所以基于关系型数据库的事务又叫“本地事务”。

这里我们要了解到一个概念，就是ACID

A：Atomic 原子性，一个事务要么全部提交成功，要么全部失败回滚，不能只执行其中的一部分操作，这就是事务的原子性

C：Consistency一致性，事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处于一致性状态。

如果数据库系统在运行过程中发生故障，有些事务尚未完成就被迫中断，这些未完成的事务对数据库所作的修改有一部分已写入物理数据库，这是数据库就处于一种不正确的状态，也就是不一致的状态

I：Isolation隔离性，事务的隔离性是在并发情况下，多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。

D：Durability持久性，一旦事务提交，那么它对数据库中的对应数据的状态的变更就会永久保存到数据库中。
–即使发生系统崩溃或机器宕机等故障，只要数据库能够重新启动，那么一定能够将其恢复到事务成功结束的状态

数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的单元，该单元中的所有操作要么成功，要么失败，只要其中任意一个失败，都将导致整个事务的回滚；

分布式事务

领会概念：

在分布式系统中会把一个应用系统拆分为可独立部署的多个微服务，因此需要
服务与服务之间远程操作才能完成事务操作，这种分布式系统环境下由不同的服务
之间通过网络远程协作完成的事务称之为分布式事务

例如：用户注册送积分，创建订单减库存，银行转账等都是分布式事务。

分布式事务产生的场景

我们先想象一个场景：

我们知道本地事务依赖数据库本身提供的事务特性来实现，因此以下逻辑可以控制本地事务：
begin transation;
//1、本地数据库操作：张三减少金额
//2、本地数据库操作：李四增加金额
commit transation;
但是在分布式环境下，会变成这样
begin transation;
//1、本地数据库操作：张三减少金额
//2、远程调用：让李四增加金额
commit transation;
可以设想，当远程调用让李四金额增加成功了，由于网络原因远程调用并没有返回，此时本地事务提交失败，就回滚了张三减少金额的操作，此时张三和李四的数据就不一致了

因此：分布式事务使用本地事务的思想来解决是行不同的；

场景一

我们以微服务架构来举例子

微服务之间通过远程调用完成事务操作，订单微服务与库存微服务
下单的同事订单微服务请求库存微服务锁定库存‘
这里就涉及到了 跨JVM进程 进而产生分布式事务~

场景二

单体应用访问多个数据库实例

当单体系统需要访问多个数据库（实例）时会产生分布式事务，例如：用户信息和订单信息分别存在两个MySQL实例存储，用户管理系统删除用户信息，需要分别删除用户信息和用户的订单信息，由于数据库分布在不同的数据实例上，需要不同的数据库连接去操作
此时涉及到了 跨数据库实例 进而产生分布式事务~

场景三

多服务访问同一个数据库实例

比如：订单微服务和库存微服务即使访问同一个数据库也会产生分布式事务，原因就是跨JVM进程，两个微服务持有了不同的数据库连接进行数据库操作。
这里就涉及到了 跨JVM进程 进而产生分布式事务~

分布式事务基础理论

分布式系统之所以叫分布式，是因为提供服务的各个节点分布在不同的机器上，互相之间通过网络交互。不能因为有一个网络节点就导致整个系统无法提供服务，网络因素成为了分布式事务的考量标准之一。因此，分布式事务需要进一步的理论支持；

重点来了

CAP理论

Consistencey一致性
Availability可用性
Partion tolerance分区容错性

注意：我们最多满足其中两个特性，也就是说可以同时满足CA CP AP,无法做到同时满足CAP

给大家整张图

本人艺术天赋有限，所画之图已竭尽本人所能，大家理解一下老同志。
好了，进入正题

先看下这整套执行流程

1. 商品服务请求主数据写入商品信息（添加商品，修改商品、删除商品）
2. 主数据向商品服务响应写入成功
3. 商品服务请求从从数据库读取商品信息

Consistency：一致性是指写操作后的读操作，可以读取到最新的数据状态，当数据分部在多个节点上，从任意节点读取得到数据都是最新的状态；

图中，商品信息的读写要满足一致性就是实现以下目标：

1. 商品服务写入主数据成功，则向从数据库查询新数据也成功；
2. 商品服务写入主数据失败，则向从数据库查询数据也失败；

如何实现一致性呢？

• 写入主数据库后要将数据同步到从数据库；
• 写入主数据库后，在向从数据库同步期间要将从数据库锁定，带同步完成后，再释放锁，以免在新数据写入成功后，向从数据库查询到旧的数据；

Availability：可用性是指任何事物操作都可以得到相应结果，且不会出现响应超时或者错误信息；

右图中，商品信息读取满足可用性就是要实现以下目标：

1. 从数据库接收到商品查询的请求则立即能够响应数据查询结果
2. 从数据库不允许出现响应超时或者响应错误；

如何实现可用性呢？

• 写入主数据库后要将数据同步到从数据库；

• 由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定

• 即使数据还没有同步过来，从数据库也要返回查询的数据，哪怕是旧数据，如果哪怕连旧数据也没有，则可以返回一个默认信息，但不能返回错误或相应超时；

分布式系统可用性的特点： 所有请求都用响应，且不会出现响应超时或者响应错误

Partition tolerance：通常分布式系统的各个节点部署在不同的子网，这就是网络分区，不可避免的会出现网络问题造成节点之间通信失败，此时仍可对外提供服务，这叫分区容忍性

图中，商品信息读写满足可用性就是要实现以下目标：

1. 主数据库向从数据库同步数据失败不影响读写操作；
2. 其中一个节点挂掉不影响另一个节点对外提供服务

如何实现分区容忍性呢？

• 尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据库，这样节点直接能有效地实现了松耦合
• 添加数据库节点，其中一个从节点挂掉其他节点提供服务；

分布式系统分区容忍性的特点： 分区容忍性就是分布式系统具备的基本能力；

如果满足P的前提下，实现C或A？

如果要实现C，就必须保证数据一致性，在数据同步的时候为防止向从数据库查询不一致的数据，需要将从数据库的数据错定，待同步完成后解锁，若果同步失败从数据库要返回错误信息或超时信息。如果同步失败要返回错误信息或超时信息；

如果要实现A则必须保证数据可用性，不管任何时候都可以向从数据库查询数据，则不会响应超时或返回错误

CAP不能同时满足。

CAP的组合方式

• AP：放弃一致性，追求分区容忍性和可用性。这是分布式系统设计时的选择；
  右图的商品管理，完全可以实现AP，前提是只要用户可以接受所查询的数据在一定时间内不是最新的即可；
  通常实现AP都会保证最终一致性，例如一些业务场景，订单退款，今日退款成功，明天账户到账，只要用户可以接受在一定的时间即可；后面我会讲另一个理论来扩展AP。

• CP：放弃可用性，追求一致性和分区容忍性，例如我们zookeeper就是最求的强一致性，例如：跨行转账，一次转账请求要等对方银行系统都完成，整个事务才算完成；

• CA：放弃分区容忍性，即不进行网络分区，不考虑网络不通或者节点挂掉的问题，则可以实现一致性和可用性，那么这个系统就不是一个标准分布式系统，其实我们最常用的关心性数据就满足了CA

BASE理论；

理解强一致性和最终一致性

CAP理论强调的一致性是强一致性；
最终一致性是允许可以在一段时间内，每个加点的数据不一致，但是经过一段时间后每个节点的数据必须一致，它强调的最终一致性

BASE理论是

Basically Available(基本可用)
Soft state（软状态），
Eventually consistent(最终一致性)

BASE是对CAP中的AP的扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内不一致的，但是最终达到一致状态，满足basse理论我们叫做“柔性事务”；

特点：

• 基本可用：例如：电商网站交易付款出现问题，商品依然可以浏览
• 软状态：由于不要求强一致性，所以BASE理论允许系统存在中间状态（软状态），这个状态不影响系统可用性，例如“订单支付中”“数据同步中”等状态，待数据最终一致后状态改为“成功”

最终一致性：
2PC：两阶段提交协议，是将整个事务流程分为两个阶段：准备阶段(Prepare phase)，提交阶段（commit phase），2是指两个极端，P是准备阶段，C是指提交阶段；

例如：张三和李四好久不见了，老友约起聚聚，饭店老板要求先买单，才能出票；这是张三和李四分别抱怨近况不如意，囊肿羞涩，都不愿意请客，这时只能AA制，只有张三和李四都付款，老板才能安排就餐，但由于张三和李四都是铁公鸡，形成了尴尬的一幕；
准备阶段：老板要求张三付款，张三付款。老板要求李四付款，李四付款；
提交阶段：老板出票，两人拿票纷纷就座；
这就形成了一个事务，若张三或李四其中一人拒绝付款，店老板都不会给票，并且会把已收的款退回；

整个事务过程由事务管理器和事务参与者组成，店老板就是事务管理器，张和李四就是事务参与者，事务管理器负责决策整个分步实施事务的提交和回滚，事务参与者负责自己本地事务的提交和回滚；

关系数据里MySQL和Oracle，都支持两阶段提交协议：

1. 准备阶段(prepare
   phase)：事务管理器给每个参与者发prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo、Redo日志，此时事务没有提交；
2. 提交阶段(commit
   phase)：如果是事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚（Rollback）消息；否则，发送提交（commit）消息；参与者根据事务管理的
   指令执行提交或者回滚操作，并释放处理过程中使用的所资源。注意，必须在最后释放所资源；

下一篇打算写一篇 分布式事务管理实战 敬请期待~