分布式事务理论

前面的文章中我们学习了搭建spring cloud微服务架构项目，通常部署时都采用分布式方式。学到这里总感觉差点什么，就像电影周星驰版《苏乞儿》中降龙十八掌前面十七掌已经学会了，最关键的一掌不会总打不死那个赵无极。再说回来，这种微服务架构总感觉不能随心随遇在各种场景都立于不败之地。接下来我们要学习的东西对微服务架构而言就像降龙十八掌的最后一掌那么重要，它就是分布式事务。

什么是分布式事务

在说什么是分布式事务之前我们先来回顾下单体架构项目的事务。

单体架构项目的事务

简单来说就是，一件事要么成功要么失败。即，这件事所包含的所有环节要么全部成功，要么全部失败。

事务的4个特性，ACID，如下：

事务原子性（atomicity)，一个事务要么全部提交成功，要么全部失败回滚，不能只执行其中的一部分操作。

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

隔离性（isolation），事务的隔离性是指在并发环境中，并发的事务时相互隔离的，一个事务的执行不能不被其他事务干扰。

持久性（durability），一旦事务提交，那么它对数据库中的对应数据的状态的变更就会永久保存到数据库中。

分布式事务

在一些微服务架构项目中通常情况下，一个微服务专门负责事情的一个环节。往往一件事情（一个请求过来）完成需要调用好几个微服务。如果程序能够保证执行一个请求时，这些微服务要么全执行成功，要么全执行失败。那么这就是分布式事务。

我们来举个例子：

假如支付宝做了微服务架构系统可以完成提现业务。即，用户可以从支付宝把钱转到银行卡。这个系统恰好有一个微服务负责用户的支付宝账户余额扣减，有另一个微服务负责用户的银行卡账户余额增加。

正好马上要放国庆假了，张三想要把支付宝的钱转到银行里去。张三在操作过程中输入支付密码后支付宝余额显示减少了，过了几秒系统提示”系统繁忙“，张三查了又查自己的银行卡账户发现钱并没有增多啊，急得他差点报警了。

上面的情况当然不允许发生了，我们要采取措施保证：

要么让张三支付宝账户余额没有扣减，银行卡账户余额没有增加；

要么让张三的支付宝账户余额扣减了，银行卡账户余额增加了。

这里就轮到我们的分布式事务登场了。

CAP理论

CAP理论：一个分布式系统不可能同时满足一致性，可用性和分区容错性这个三个基本需求，最多只能同时满足其中两项

一致性(C，Consistency)：数据在多个副本之间是否能够保持一致的特性。

例如，主数据库数据发生变化向从数据库同步的期间。锁定数据库，不提供服务，当数据同步完成之后再释放锁，提供服务。

可用性(A， Availability)：是指系统提供的服务必须一致处于可用状态，对于每一个用户的请求总是在有限的时间内返回结果，超过时间就认为系统是不可用的。

当向数据库发送请求时，在任何时候都要有响应数据，哪怕这个数据不是当前最新的。如果响应超时或者响应错误则不叫高可用。

分区容错性(P，Partition tolerance )：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非整个网络环境都发生故障。

现实中分布式系统通常布不同的子网，难免因为网络原因发生各种延迟，超时等故障。这个时候C和A就不可能同时满足。

这样的话可以有这几种组合CA、CP、AP。实际情况中我们一般采用AP组合，牺牲强一致性，保证最终一致性。

BASE理论

​ BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。

分布式事务理论就说到这里，后面我们去看看分布式事务的实现方式。