本地事务&分布式事务

一、本地事务

1、事务的基本性质

数据库事务的几个特性：原子性(Atomicity)、一致性(Consistency)、隔离性或独立性(Isolation) 和持久性(Durabilily)，简称就是 ACID。

• 原子性：一系列的操作整体不可拆分，要么同时成功，要么同时失败

• 一致性：数据在事务的前后，业务整体一致。

• 隔离性：事务之间互相隔离。

• 持久性：一旦事务成功，数据一定会落盘在数据库。

在以往的单体应用中，我们多个业务操作使用同一条连接操作不同的数据表，一旦有异常， 我们可以很容易的整体回滚。

• Business：我们具体的业务代码

• Storage：库存业务代码；扣库存

• Order：订单业务代码；保存订单

• Account：账号业务代码；减账户余额

比如买东西业务，扣库存，下订单，账户扣款，是一个整体；必须同时成功或者失败。

一个事务开始，代表以下的所有操作都在同一个连接里面。

2、事务的隔离级别

• READ UNCOMMITTED（读未提交）

该隔离级别的事务会读到其它未提交事务的数据，此现象也称之为脏读。

• READ COMMITTED（读已提交）

一个事务可以读取另一个已提交的事务，多次读取会造成不一样的结果，此现象称为不可重复读问题，Oracle 和 SQL Server 的默认隔离级别。

• REPEATABLE READ（可重复读）

该隔离级别是 MySQL 默认的隔离级别，在同一个事务里，select 的结果是事务开始时时间点的状态，因此，同样的select操作读到的结果会是一致的，但是会有幻读现象。MySQL 的 InnoDB 引擎可以通过 next-key locks 机制（参考下文"行锁的算法"一节）来避免幻读。

在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。

当隔离级别设置为REPEATABLE READ 时，可以避免不可重复读。当A拿着工资卡去消费时，一旦系统开始读取工资卡信息（即事务开始），A的老婆就不可能对该记录进行修改，也就是A的老婆不能在此时转账。

幻读（前后多次读取，数据总量不一致）：

事务A在执行读取操作，需要两次统计数据的总量，前一次查询数据总量后，此时事务B执行了新增数据的操作并提交后，这个时候事务A读取的数据总量和之前统计的不一样，就像产生了幻觉一样，平白无故的多了几条数据，成为幻读。

• SERIALIZABLE（序列化）

在该隔离级别下事务都是串行顺序执行的，MySQL 数据库的 InnoDB 引擎会给读操作隐式加一把读共享锁，从而避免了脏读、不可重读复读和幻读问题。

不可重复读和脏读的区别是：脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。

幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。

3、事务的传播行为

• PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。

• PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行。

• PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。

• PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。

• PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当 前事务挂起。

• PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。

• PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与 PROPAGATION_REQUIRED 类似的操作。

下面是两个事务传播行为的案例：

案例一：

方法B()和方法A()共用一个事务，方法C则创建一个新事务，若出现异常则方法B()和方法A()会回滚，方法C()则不会（因为它自己是一个单独的事务）

    @Transactional
    public void A() {
        B();
        C();
        int i = 10 / 0;
    }
​
    @Transactional(propagation = Propagation.REQUIRED)
    public void B() {
​
    }
​
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void C() {
​
    }

案例二：

方法B()设置了事务的超时时间，但是方法B()和方法A()共用方法A()的事务，因此，以方法A设置的超时时间为准。

    @Transactional(timeout = 30)
    public void A() {
        B();
        C();
        int i = 10 / 0;
    }
​
    @Transactional(propagation = Propagation.REQUIRED, timeout = 20)
    public void B() {
​
    }
​
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void C() {
​
    }

4、本地事务在分布式下的问题

问题：

（1）、远程服务假失败：

• 远程服务其实成功了，由于网络故障等没有返回。比如锁库存假失败，由于网络原因导致连接超时，但是锁库存已经操作成功。此时，会导致订单数据回滚而锁库存数据没有回滚即库存扣减了。

• 先调用的远程服务调用成功，但是后面调用的远程服务失败，导致订单数据回滚，但已经执行成功的远程服务调用的数据库数据无法回滚。比如扣减库存成功，但是扣减之后确认订单失败，那么订单回滚但是库存服务的扣减库存是回滚不了的。

（2）、SpringBoot事务的坑（事务失效原因）

①未开启事务的自动配置

@TransactionAutoConfiguration，这个注解用来启用spring事务自动管理事务的功能，如果没写则SpringBoot不会开启自动管理事务的功能。

② 方法不是public类型的

@Transaction 可以用在类上、接口上、public方法上，如果将@Trasaction用在了非public方法上，事务将无效

③数据源未配置事务管理器

@Bean
public PlatformTransactionManager transactionManager(DataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
} 

④自身调用问题

spring是通过aop的方式，对需要spring管理事务的bean生成了代理对象，然后通过代理对象拦截了目标方法的执行，在方法前后添加了事务的功能，所以必须通过代理对象调用目标方法的时候，事务才会起效。

看下面代码，大家思考一个问题：当外部直接调用m1的时候，m2方法的事务会生效么？

@Component
public class UserService {
    public void m1(){
        this.m2();
    }
    @Transactional
    public void m2(){
        //执行db操作
    }
}

显然不会生效，因为m1中通过this的方式调用了m2方法，而this并不是代理对象，this.m2()不会被事务拦截器拦截，所以事务是无效的

如果外部直接调用通过UserService这个bean来调用m2方法，事务是有效的，上面代码可以做一下调整，如下，@1在UserService中注入了自己

@Component
public class UserService {
    @Autowired //@1
    private UserService userService;
​
    public void m1() {
        this.userService.m2();
    }
    @Transactional
    public void m2() {
        //执行db操作
    }
}
​

此时会产生更为严重的问题：循环依赖

⑤ 异常类型错误

spring事务回滚的机制：对业务方法进行try catch，当捕获到有指定的异常时，spring自动对事务进行回滚，那么问题来了，哪些异常spring会回滚事务呢？

并不是任何异常情况下，spring都会回滚事务，默认情况下RuntimeException和Error的情况下，spring事务才会回滚

也可以自定义回滚的异常类型(需继承*RuntimeException)：

@Transactional(rollbackFor = {异常类型列表})

@Transactional(rollbackFor = {异常类型列表})

⑥异常被吞了

当业务方法抛出异常，spring感知到异常的时候，才会做事务回滚的操作，若方法内部将异常给吞了，那么事务无法感知到异常了，事务就不会回滚了。

如下代码，事务操作2发生了异常，但是被捕获了，此时事务并不会被回滚

@Transactional
public void m1(){
    事务操作1
    try{
        事务操作2，内部抛出了异常
    }catch(Exception e){
    }
}

⑦业务和spring事务代码必须在一个线程中

spring事务实现中使用了ThreadLocal，ThreadLocal大家应该知道吧，可以实现同一个线程中数据共享，必须是同一个线程的时候，数据才可以共享，这就要求业务代码必须和spring事务的源码执行过程必须在一个线程中，才会受spring事务的控制，

比如下面代码，方法内部的子线程内部执行的事务操作将不受m1方法上spring事务的控制，这个大家一定要注意

@Transactional
public void m1() {
    new Thread() {
        一系列事务操作
    }.start();
}

 

最后一个是本项目中老师提到的在同一个类里面，编写两个方法，内部调用的时候，会导致事务设置失效问题。原因是没有用到代理对象的缘故。

概括：同一个对象内事务方法互调默认失效(事务是加上的，但是事务的设置失效。比如说：设置超时时间)，原因：绕过了代理对象，因为Spring使用事务是利用了AOP，加事务是通过代理对象加的事务，而相同对象直接调用内部方法时不会重新生成代理对象（默认是this调用），也就不会为方法加上事务。

解决方案： 使用代理对象来调用事务方法

1. 引入spring-boot-starter-aop(帮我们引入了aspectj)

2. 开启@EnableTransactionManagement(proxyTargetClass = true)对外暴露代理对象

3. 开启@EnableAspectJAutoProxy(exposeProxy=true)开启 aspectj 动态代理功能。

4. 在使用方法时使用AopContext.currentProxy()调用方法

public void a() {
    //可以直接强制类型转换，因为AopContext.currentProxy获取的就是当前类的代理对象
    XxxServiceImpl o = (XxxServiceImpl)AopContext.currentProxy();
    o.b();
    o.c();//这里使用了o这个代理对象，其实只要我们不是直接调用c()方法都可以加上事务，因为直接调用默认是this
}
public void b() {
    System.out.println("b...");
}
public void c() {
    System.out.println("c...");
}

二、分布式事务

1、为什么有分布式事务

分布式系统经常出现以下异常：

机器宕机、消息丢失、消息乱序、数据错误、不可靠的TCP、存储数据丢失……

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个 东西，特别是在微服务架构中，几乎可以说是无法避免，因为微服务架构中，各个服务之间互相调用难免会出现一些问题（尤其网络问题），那么如果没有实现分布式事务，就会出现数据一致性问题。

2、分布式cap定理和BASE理论

（1）cap定理

CAP 原则又称 CAP 定理：指的是在一个分布式系统中，以下三种性质最多只能同时实现两点，不可能三者兼顾（CP/AP）

• 一致性(Consistency)：

  在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

• 可用性(Availability)：

  在集群中一部分节点故障后，集群整体是否还能享用客户端的读写请求。（对数据更新具备高可用性）

• 分区容错性(Partition tolerance)：

  大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition)。分区容错的意思是：区间通信可能失败。比如：一台服务器放在中国，另一台服务器放在美国，这就是两个区，他们之间可能无法通信。

一般来说分区容错无法避免。因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们， 剩下的 C 和 A 无法同时做到。

 

分布式系统中实现一致性的 raft 、paxos的raft动画演示传送门：Raft(thesecretlivesofdata.com)

Raft算法的原理说明：

首先，在Raft中一个节点有三种角色：

①追随者(Follower)

②候选人(Candidate)

③领导者(Leader)

一开始，所有节点都是追随者状态，如果没有领导者给他们发信息，他们可以变成候选人，候选人将会给追随者发起选举，追随者们将会投票给候选人，如果候选人得到了大多数票则它将会成为领导者。这个过程被成为：领导选举。

追随者是如何成为候选人的呢？首先，节点有一个自旋超时时间(150ms-300ms),谁自旋结束的快谁就是候选者，候选人发起选举，如果节点在此轮选举中还没有投票，那么节点将会投票给它，一旦候选人收到大多数投票那么它将成为领导者。成为领导者之后则开始心跳联络，定期向节点发出我还在的消息，节点回复收到，这种状态直到领导者挂掉为止。

所有改变将需要听从领导者，假设客户端发来一条 SET 5 命令，首先，领导者会将这条命令保存到log中，然后会将 SET 5 命令发送给它的追随者，追随者们也是将命令保存至log中，领导者接收到大多数节点的回复–已经将这条命令写入log中了，此时，所有节点日志中的这条命令都是uncommited的。然后，领导会将这条命令commit并通知它的追随者让它们也去提交。这个过程被成为：日志复制。

日志复制过程在分区中的体现：由于网络原因，A、B被划分为1区，C、D、E被划分为2区，1区和2区之间不能通信，A原来是领导者所以在1区它还是领导者，2区经过多轮选举选出了新的领导者，现在有Client1给1区发 SET 10 的命令，A保存命令至日志然后通知B也保存日志，但是通知没有得到大多数节点的回复因此是uncommited的状态，Client2给2区发 SET 100 命令，2区领导者保存命令至日志，同时通知其它节点页保存命令至日志并且收到大多数节点的回复，2区领导者将会commit并会通知其它节点也去commit的。最终，1区和2区的通信回复了，由于2区的领导者是经过多轮选举选出的所以它成为了所以节点的领导者，原来1区的领导者就变成了追随者，1区A、B节点发现跟领导者的日志不一致，马上回滚日志并更新新的日志和提交，至此所有节点的数据是一致的。

（2）CP面临的问题

对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到 99.99999%（N 个 9），即保证 P 和 A，舍弃 C。

（3）BASE理论

它是对 CAP 理论的延伸，思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但可以适当的采取弱一致性即最终一致性。

BASE 是指：

基本可用(Basically Available)：

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性(例如：响应时间、功能上的可用性)，允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用。

• 响应时间上的损失：正常情况下搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1～2秒。

• 功能上的损失：购物网站在购物高峰（如双十一时），为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。

软状态(Soft State)：

软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication 的异步复制也是一种体现。

最终一致性(Nventual Consistency)：

最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

（4）强一致性、弱一致性、最终一致性

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。

对于关系型数据库，要求更新过的数据能够被后续的访问都能看到，这是强一致性。 ​ 如果能容忍后续的部分或者全部访问不到，则是弱一致性。 ​ 如果经过一段时间后要求能够访问到更新后的数据，则是最终一致性。

3、分布式事务常见解决方案

（1）2PC 模式

数据库支持的 2PC【2 phase commit 二阶提交】，又叫做 XA Transactions。

MySQL 从 5.5 版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。 其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：

• 第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.

• 第二阶段：事务协调器要求每个数据库提交数据。 其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。

• XA 协议比较简单，而且一旦商业数据库实现了 XA 协议，使用分布式事务的成本也比较低。

• XA 性能不理想，特别是在交易下单链路，往往并发量很高，XA 无法满足高并发场景

• XA 目前在商业数据库支持的比较理想，在 mysql 数据库中支持的不太理想，mysql 的 XA 实现，没有记录 prepare 阶段日志，主备切换回导致主库与备库数据不一致。

• 许多 nosql 也没有支持 XA，这让 XA 的应用场景变得非常狭隘

• 也有 3PC，引入了超时机制（无论协调者还是参与者，在向对方发送请求后，若长时间 未收到回应则做出相应处理）

（2）柔性事务-TCC事务补偿型方案

刚性事务：遵循 ACID 原则，强一致性

柔性事务：遵循 BASE，最终一致性；

与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。

Try代码模块中需要Coder自己编写业务逻辑，Confirm代码块中会提交数据(例如：加2)，那么在Cancel中则需要Coder编写回滚逻辑(例如：减2)

一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。

二阶段 commit 行为：调用 自定义 的 commit 逻辑。

二阶段 rollback 行为：调用 自定义 的 rollback 逻辑

所谓 TCC 模式，是指支持把自定义的分支事务纳入到全局事务的管理中。

（3）柔性事务-最大努力通知方案

按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对。这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种方案也是结合 MQ 进行实现，例如：通过 MQ 发送 http 请求，设置最大通知次数。达到通知次数后即不再通知。

案例：银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对账文件），支付宝的支付成功异步回调。

（4）柔性事务-可靠消息+最终一致性方案（异步确保型）

实现：业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正的发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才会真正发送。