分布式事务

标签：事务调用发送 PROPAGATION 消息一致性分布式

本地事务在分布式下会出现的问题

只能各自回滚各自的
1. 簇点头那边抛出异常--->全部回滚(ok)
2. 簇点第一个远程调用返回code不正确,我们可在主方法这抛异常(ok)
3. 簇点非第一个远程调用code不正确,我们只有那个远程调用和主方法会rollback,在其之前的远程调用无法rollback没人通知(NO)

事务观念复习

事务的基本性质:ACID

A:原子性

C:一致性

I:隔离性

D:持久性(一旦事务成功,数据一定会落盘在数据库)

事务的隔离级别

读未提交(会出现幻读,可能每次读到的值之后会马上变化)
读已提交(oracle和sqlserver默认,只会读到已经commit的数据)
可重复读(你先读值,对方改值,你再读值仍然会和没改值一样)
序列化(串行化)

事务的传播行为

1、PROPAGATION_REQUIRED：**如果当前没有事务，就创建一个新事务，如果当前存在事务，

就加入该事务，该设置是最常用的设置。

2、PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当

前不存在事务，就以非事务执行。

3、PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果

当前不存在事务，就抛出异常。

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

5、PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当

前事务挂起。

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

7、PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，

则执行与 PROPAGATION_REQUIRED 类似的操作。

SpringBoot关于事务的坑

同一个类中,调用自己的方法都是没有用的

因为springboot的@Transactional是用aop切面来实现的

所以a中调用b,c相当于把b和c的代码复制粘贴,同时配置的传播行为和参数也不会起效果,仅在直接调用b,c方法起效

 @Transactional(timeout = 30)
    public void a(){
        b();
        c();
    }
    @Transactional(timeout = 20)
    public void b(){

    }
    @Transactional(propagation = Propagation.REQUIRES_NEW,timeout = 555)
    public void c(){

    }

解决方法:

0）、导入 spring-boot-starter-aop

1）、@EnableTransactionManagement(proxyTargetClass = true)

2）、@EnableAspectJAutoProxy(exposeProxy=true)

3）、AopContext.currentProxy() 调用方法

@Transactional(timeout = 30)
public void a(){
    OrderServiceImpl orderService = (OrderServiceImpl) AopContext.currentProxy();
    orderService.b();
    orderService.c();
    //用this.b()也没用,他仍然是复制粘贴的效果
}

CAP理论

专指在一个分布式系统中

C:一致性(分布式系统中所有数据备份,在同一时刻是否是同样的值)
A:可用性(在集群中一部分节点故障后,集群整体能否响应客户端的读写请求)
P:分区容错性(大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。)

分区容错性是一定要解决的

毕竟我们刚开始选择分布式就是不想要,一台机器挂就完全不可用吧?

假如一台现在网络连接出现问题

那么现在出现数据不一致,你要么选择数据一致性,要么选择可用性,毕竟你选了使用这台机器,那么就得忍受这台机器的数据是不一致的

所以我们只能选择

CP OR AP

保持数据一致性的算法Raft

leader election

在现任领导挂后或者无法取得联系后,在我们从节点自旋等待时间一过,哪个过的快直接转变身份成为候选人(并且自己投自己一票),同时向自己能通信的其他节点发出了拉票请求,如果自己票数达到大多数,那么光荣成为下一位领导

如果出现了多位候选人,且这轮票数不分伯仲,那么进入下一轮选举!!!!

每个节点中都会统计自己目前参与过多少轮选举,即使一直是从节点,这是有目的的

例如东汉末年分三国,原先汉-->刘,之后即使是三个国家,如果势均力敌的情况下,这时候谁都commit不了,例如我们发送的所有要保存到刘的数据都无法commit(顺便一提,发送数据是通过heartbeat实现的,从节点收到后就会返回数据),毕竟获取不到原先票数的大多数return,如果有一方势力达到了大多数,那么在下次融合时,他会成为新领导,也就是自身存经历多少轮选举的目的

(我说的自旋时间)The election timeout is randomized to be between 150ms and 300ms.

不过候选人长时间收不到其他节点的心跳,他会自己成为leader

CP可行吗?

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

总不能导致不可用吧?

BASE理论

即使做不到强一致性(CAP的一致性),但可以采用适当的采取弱一致性,即最终一致性

Base(基本可用)的相关理念

基本可用指分布式系统出现故障时,允许损失部分可用性(如响应时间,功能上的可用性)

响应时间的损失:比以往延长1~2s
功能上的损失:部分消费者被引导到一个降级页面

软状态:

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

说白了,就是在所有机器在极短时间内都一致和很长一段时间不一致的中间值

最终一致性

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

强一致性、弱一致性、最终一致性

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到(相当于立即要看到)，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性