事务隔离级别，CAP和BASE理论

勿以浮沙筑高台

---

什么是事务

是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；这些操作作为一个整体一起向系统提交，要么都执行、要么都不执行；事务是一组不可再分割的操作集合（工作逻辑单元）。
事务具备4个特性ACID

ACID介绍

原子性(Atomicity)：即整个事务单元要么成功要么失败，当中某一处失败全部回顾是基于日志的Redo/Undo机制。
一致性（Consistent）：指事务执行的前后状态要一直，数据要一致，即事务执行后的数据不能出错，要保证正确性。
隔离性（Isalotion）：指多个事务直接是相互不透明的，数据不相互印象，和事务的隔离性有关系
持久性(Durable)：指数据完成后提交到数据库中，插入修改删除永久性的更新到磁盘当中。

事务的隔离性

在mysql的事务中有4个隔离级别的设置，分别是读未提交（READ UNCOMMITTED）、读提交 （READ COMMITTED）、可重复读 （REPEATABLE READ）、串行化 （SERIALIZABLE）

读未提交（READ UNCOMMITTED）：即设置了事务已经begin，但是这个时候我的事务还没有commit，另一个用户读取这个数据，读取到了我还没没修过的数据，即产生脏读。

读提交 （READ COMMITTED)：即A事务已经begin，但是没有提交，这个时候B事务进来读取数据，由于A没有commit数据，则事务B不能读取到数据只能等待A事务commit，这个时候出现了数据不可重复读。

可重复读 （REPEATABLE READ）：即可以实时的读取我修改的数据，但是又引发了一个新的问题，即幻读：当A事务准备插入数据提前查询数据是否存在，这个时候B事务也读取到这几个数据不存在，但这个时候A数据已经读取到不存在，并进行了事务的插入操作，数据以存在，B事务还判断是不存在，即发生了幻读，执行插入数据，数据库这时候就会有2条相同的数据。

串行化 （SERIALIZABLE）：串行化是事务基本的最高级别的锁，即在每个读的上面加锁，必须等待读锁完成了下一个数据才能进行，比如select语句查询，有一个update数据进来了则必须等待读锁的完成才能进行。

分布式事务

什么是分布式事务

在我们微服务或者SOA架构中，我们单个流程执行会跨越多个服务器的问题，当某一个流程失败我们需要回滚时，这个时候单一事务就无法满足。

分布式事务理论

CAP

CAP理论是1998年，加州大学的计算机科学家 Eric Brewer 提出、分布式系统有三个指标，这三个指标就是CAP理论

Consistency (一致性)： 指当完成写操作时，在分布式系统中任意一个节点读取到数据都是我们写操作的数据。

Availability (可用性)： 指我们数据无论何时何地都要返回出去哪怕是错误的数据为了到达系统的可用性不能堆积也要返回回去，这里就和一致性发生了冲突，如果DB-A完成了写，DB-B还在同步DB-A的数据，这个时候DB-B有数据读取，就必须返回给服务，即产生了脏读。
Partition tolerance(分区容忍性)： 指我们数据库之间应该部署多个网段，避免网络故障，导致整个DB集群不可用，但是部署多个网段，但是数据一致性就无法保证。如果等待事务完成强行等待则可用性就不行。

CAP之间不能三个组成一起。在一起会相互破坏。

只能两两之间进行组合：

CP(一致性，分区容忍性)：即分区部署，等待
事务的完成，再执行下一步操作，没有保证可用性。

用于订单，转账，ERP（对接淘宝，JD）等需要双方确认的关系

CA(一致性，可用性)：即放弃分布式部署，单机操作，无需等待同步，数据可以操作也可以查询。

AP(一致性，可用性)：分布式部署，保证数据的可用性，即不要求实时同步消息。

消息通知，订单退订，用户可以等待的应用方面。

BASE

基本可用：即单一核心系统故障时不会影响整个流程，比如结账，但是依旧可以创建订单，浏览商品。

软状态：不要求强制性，系统中间存在软状态，比如订单正在处理中，支付中，请骚等等。

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

分布事务解决方案

最大努力通知

即消息发起方多次进行消息通知，没有事务验证，用于对于事务的一致性要求较低的场景，如记录登录日志等，阅读记录等。

发起方需要开放查询接口，给予接收方进行数据的校验。
事务完成的因素在于接收方

2PC（两阶段提交协议）（保证强一致性）

即准备提交协议。事务发起时，先通知查看DB或者服务是否准备好，准备好了，再统一进行commit提交。

第一阶段： 准备阶段，各本地事务完成准备工作begin业务内容，但此时事务没有提交。
第二阶段： 执行阶段，协调者根据阶段一的结果，进行通知提交或者回滚。倘若有一个commit失败则全部通知回滚。

这里有个问题，即事务协调者挂了，准备完成，还未commit的时候挂了，那么每个事务会锁定资源影响性能。

3PC（三阶段提交协议）（保证强一致性）

为了解决这个问题，提出了3PC。

第一步：paper阶段，则是判断资源是否存在，是否健康。
第二步：begin阶段，开始执行业务锁定资源。并进行预提交，如果预提交阶段过后，事务管理器挂掉了，那么会有个超时机制，进行最后的commit的提交。
第三步：commit阶段，提交或者回滚数据。

3PC比2PC进步了一点点，解决了单点故障问题，但是并没有解决根本问题，即事务管理者挂掉了，那么后续的数据事务问题。

TCC（Try - Confirm - Cancle）

柔性事务，

每个系统都需要开发三个方法，每个系统都必须开发try / confirm / cancle 三个方法，

try阶段：锁定资源，比如有100个商品，扣减10个，这个时候不动真实商品数量字段，操作冻结字段。依次将各个微服务的冻结字段写入数据。完成后写入日志记录文件。表示这个阶段完成

confirm 阶段：commit，用商品资源去减去冬冻结字段。完成commit。完成后写入日志记录文件，表示这个阶段完成。

cancle 阶段：rollback，即当记录日志里没有完成记录，则执行回滚方法，则是将冻结资源字段清0，并将以删减的数量加回来。

下图是Hmily的TCC架构图：

请求经过占位记录到redo.log日志数据库，再进行其他的confirm或者cancel操作，txmanager则进行redo.log日志记录的查看，如果发现没有记录则进行cancel操作。

优点:

1. 每个阶段会提交本地事务并释放锁，性能比较高。
2. 不需要等待其它事务执行结果，如其他事务失败，则执行补偿cancel操作。

缺点:

1. 业务复杂，实现try、confirm、cancle
2. 程序员要求高，需要考虑幂等性(即用户单次点击事件数据的一致性，不会因为因为网络问题多次点击触发多次。)，重试机制，confirm/cancle在try之前执行处理

可靠消息最终一致性

发起方完成本地事务后，一定成功发出消息。 消费者一定能接收消息，并处理事务成功。
那么如何保证本地事务 和 发消息的原子性？

方案（一）：基于RocketMQ

1.订单服务给予数据库事务写入业务数据然后发送消息。
2.基于MQ的机制，必须完成了才会完成消息消费完成库存服务的完成。

方案二：