一：分布式事务理论基础

原子性（Atomicity）
原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
一致性（Consistency）
事务前后数据的完整性必须保持一致。
隔离性（Isolation）
事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。
持久性（Durability）
持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响
————————————————

在原来学的单体架构项目中，往往只有一个服务，这个服务只访问一个数据库，业务比较简单，基于数据库本身的特性，能够实现ACID，我们现在要研究微服务，微服务的业务比较复杂，可能一个业务需要跨越多个服务，每个服务要有自己的数据库，这个时候考数据库本身的特性不能保证整个业务的ACID

订单模块：

OrderService：

远程调用的客户端：

数量模块： 

 客户端：

库存模块：

使用Postman发送订单请求：

订单表刷新一下：

余额由1000变成800：

库存表变成由10变8：

更改订单数量：变大订单购买数量超过余额导致失败：

此时用户的余额不应该扣除，但是扣减了

此时的状态不是一致的

理论上库存服务报错，前面也应该跟着回滚，但是没有，因为每个服务都是独立的，库存服务抛了异常，账户服务不知道，第二每个服务都是独立的，他们的事务也是独立的，订单服务，账户服务执行完业务之后事务结束了执行提交了，没有办法回滚，最终没有达成事务状态的一致，这个时候就出现了分布式事务的问题

解决分布式事务的理论基础

1.CAP定理 

为了满足一致性可以让node03等待node02网络的恢复和数据同步，在恢复之前，所有访问的请求都阻塞下去，这么做就可以满足数据的一致性，此时node03就变成不可用的了

为了满足可用性，就没有办法保持一致性

当网络分区出现时，可用性跟一致性没有办法同时满足

分区是不可避免的，只要你是分布式系统节点之间都是通过网络连接的，只要通过网络连接的，就没有办法永远保持永远健康

我们可以这么认为分布式系统分区一定会出现，整个集群不需要对外提供服务，P一定要实现，此时C和A之间只能要一个

 

2.BASE理论

P分区一定会出现，A可用跟C一致一定只能选一个，这两个特性都非常重要，都不想放弃那怎么办？BASE理论正好可以解决这个问题

BASE理论是对CAP理论的调和跟选择和调和

我们分布式事务当中分为很多子事务，他们各自执行跟提交，有些成功，有些失败，这个时候状态不一致，我们希望分布式事务的子事务状态要一致，要么都成功，要么都失败，基于BASE理论去解决：

各个子事务要去互相通信，去辨别对方的执行状态，各个子事务之间怎么去通信呢，需要一个协调者帮助子事务去通信，感知对方的状态