分布式事务

分布式事务

1 本地事务

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

数据库事务的3大特性

（1）A（Atomic）：原子性，构成事务的操作要不全部成功，要么全部不执行，不可能部分成功部分失败的情况。
（2）C（Consistency）：一致性，事务执行前后，数据库一致性约束没有被破坏。如：张三向李四转账100，转账前和转账后的数据准确才可以，不能出现张三少了100，李四没有增加100。
（3）I（Isolation）：隔离性，数据库中的事务都是并发的，并发的事务之间不会相互干扰，一个事务不能看到其他事务的中间状态。通过配置事务隔离级别可以避免重复读，脏读等问题。
（4）D（Durability）：持久性，事务完成后，该事务对数据的更改会持久化到数据库，不会被回滚。

分布式事务（分布式系统中存在的，跨jvm进程所产生的）

分布式系统会把一个应用系统拆分为多个独立部署的多个服务，因此需要服务与服务之间远程协作来完成事务，这种分布式系统环境下有不同的服务之间通过网络协作完成事务称为分布式事务。如：银行转账事务

分析：分布式事务通过本地事务的思想是解决不了的（涉及网络通信就会有很多问题）
如果1本地数据库操作失败，可以回滚。
如果1本地数据库操作成功，2远程调用返回异常失败，那么同样事务可以回滚整个事务。
如果1本地数据操作成功，2远程调用操作成功（远程服务已经增加了金额了），但是远程调用由于网络超时返回异常了，那么方法事务会回滚（回滚张三减少金额的操作，但是李四增加金额是回滚不了的）

产生分布式事务的其他场景

1 单体系统访问多个数据库实例
跨数据库实例产生分布式事务，单体应用所做的2件事，一个数据库连接连接的是1个数据库，另一个数据库连接的是另一个数据库。（因为是2个不同的数据库连接）

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

如：微服务中的2个java应用（每个java应用有自己的jvm），属于跨jvm进程，2个服务使用的不同的数据库连接对数据库进行操作。，产生分布式事务。

基础理论

因为提供服务的各个节点不在同一机器上，相互之间通过网络交互，不能因为一点网络问题就导致整个系统无法提供服务，通过理论知识指导我们确定分布式事务控制的目标，帮助理解每个解决方案。

CAP（3个分布式的目标）

CAP是Consistency、Availablity、Partition.tolerance三个词语的缩写，分别表示一致性，可用性，分区容忍性。

一致性：是指写操作后的读操作可以读取到最新的数据状态（满足这个状态，读取的数据库无法提供服务）
例如数据库的主从复制：写入数据库后，1个数据库向从数据库同步（会锁定从数据库，期间主从数据库无法提供对外服务，读取被锁定的数据库节点可以返回报错信息，但是一定不能返回旧数据）

可用性：任何事务操作都可以得到响应结果，且不会出现响应超时或响应错误。（可以返回旧数据，2个数据库都需要能提供服务）
例如：主从数据库同步期间，也需要对外提供服务。

分区容忍性：（是分布式系统应具备的基本能力）
分布式系统的各节点分布在不同的子网里面，由于网络问题，可能会导致节点之间通讯失败，但是此时2个服务都可对外提供服务。（一个节点挂了不影响另一个节点）。

CAP组合方式

在具备了P的情况下，不会同时具备C和A

1 AP

放弃一致性，追求可用性和容忍性，很多分布式系统的选择。
例如：订单退款，可以容忍明天才会到账，此时查看账户还是原来的旧数据。

2 CP
放弃可用性，追求一致性和容忍性，如：zookeeper追求的就是强一致性。
如：跨行转账，要等待双方银行系统都完成整个事务才算完成，就是转账页面的3 2 1倒计时，结束代表转账完毕。此时去查询，钱是最新的（转账过来的）

BASE理论（满足这个理论的事务称为柔性事务）

是对CAP理论里面的AP的扩展，通过牺牲强一致性来获得可用性。当出现故障允许一部分不可用但要保证核心功能可用。允许数据在一段时间内是不一致的，但最终达到一致性。

（1）基本可用：分布式系统出现故障时，允许一部分不可用但要保证核心功能可用。

（2）软状态：由于不要求强一致性，允许系统中存在中间状态（软状态）。不影响系统可用性，如订单的”支付中“等状态，待数据最终一致后，改为”成功“状态。

（3）最终一致性：是指经过一段时间后，所有节点数据都会达到一致。