【分布式事务】CAP定理和Base理论

1、事务的ACID原则

所有的事务都要满足ACID原则，在单体架构中，只有一个服务，这个服务访问一个数据库，场景简单。基于数据库本身的特性，就已经可以实现ACID。

但微服务下，一个业务可能跨越多个微服务，而每个服务又会有自己的数据库，这个时候，仅靠数据库自身，已经不能保证业务上的ACID了。

2、分布式服务案例

微服务下单，下单时调用订单服务，创建订单并写入数据库。然后订单服务还要调用账户服务和库存服务（三个微服务有各自的数据库）：

• 账户服务负责扣减用户余额
• 库存服务负责扣减商品库存

对应上面的场景，创建一个demo工程，包含三个模块：

测试下单功能：

POST 'http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=2&money=200'

发现当库存数量不足扣减时，订单和账户却都更新成功了。

在分布式系统下，一个业务跨越多个服务或数据源，每个服务都是一个分支事务，而这些分支事务之间互相无感知，要保证所有分支事务最终状态一致，这样的事务就是分布式事务。

3、CAP定理

分布式系统有三个指标：

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

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统无法同时满足这三个指标，即CAP定理。

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

即用户访问节点01和节点02得到的数据要一致。但问题是，用户将数据写如node01，01同步给02总是需要一个过程和时间的。

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

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

如下图，网络故障,使得node02和node03之间无法通信，此时用户将数据data:v1写入node02：

此时就出现了悖论，网络故障期间，如果所有节点仍然对外提供服务，则可用性A成立，但数据不一致了，即C不成立。如果节点node03暂时不提供服务，此时返回的01和02节点返回的数据当然是一致的，即C成立，但可用性A不成立。

网络故障不可避免，因此分区容错P一定要实现，此时分布式系统需要在C和A之间抉择。要CP还是AP。

总结就是：

- 分布式系统节点通过网络连接，一定会出现分区问题（P）
- 当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足
- CP、AP选其一

ElasticSearch集群，就属于CP：

ES集群出现分区时，故障节点会被剔除出集群，其上的数据分片会重新分配到其它节点，保证数据一致。因此是低可用性，高一致性，属于CP

4、Base理论

CAP中，不管是CP还是AP，单独保证一方，而完全丢掉另一方，总是差点意思，因此Base理论出现。BASE理论是对CAP的一种解决思路，是对C和A的一种居中调和。Base理论主要有三个思想：

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

eg：ES集群就是Basically Available的一个体现：

某ES节点挂了，就先踢出集群，其上的数据数据分片分配到其他节点。等这个节点恢复，又重新加到集群中，重新给它分片，这个节点又可用了。

而最后的软状态和最终一致性，则是另一种调和：

即我完全保证可用性，但一致性C我也不是完全抛弃，它只是这一小会儿不一致，最终我会同步成一致的。

5、分布式事务模型

分布式事务最大的问题是各个子事务的一致性问题，借鉴CAP定理和BASE理论就有了：

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

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

不管CP还是AP，各个子事务之间都需要做一个通信，去辨别对方是否执行成功。而想实现各个子事务之间通信，需要一个事务协调者，分支事务需要将自己的执行结果告诉事务协调者。

解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务