springcloudseata（springcloudseata原理）

本篇文章给大家谈谈springcloudseata，以及springcloudseata原理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、springcloud+eureka+seata（AT模式）解决分布式事务
• 2、Spring Cloud Alibaba Dubbo整合Seata(Fescar)实现分布式事物回滚
• 3、86 SpringCloud解决分布式事务
• 4、springcloud整合分布式事务(seata)

springcloud+eureka+seata（AT模式）解决分布式事务

4.修改弊基陆registry.conf文件

5.修改file.conf

9.seata1.1.0以后，不需要手锋闹动代理租顷数据源，启动类上@SpringBootApplication（exclude = DataSourceAutoConfiguration.class)：

Spring Cloud Alibaba Dubbo整合Seata(Fescar)实现分布式事物回滚

作者使用的开发套件是Spring Cloud Alibaba，RPC框架采用Dubbo Spring Cloud，使用Feign的同学也可以看看，原理相通，大同小异。

这部分建议阅读 官方文档-README

Seata 全局事务的传播机制就是指事务上下文的传播，根本上，就是 XID 的应用运行时的传播方式。默认的，RootContext 的实现是基于 ThreadLocal 的，即 XID 绑定在当前线程上下文中扒斗。

而我们在分布式系统中，各系统不在一个线程中，为了察衡使Seata全局事物能够在分布式系统中传播，需要对此进行扩展，Seata内置了Dubbo的支持，引用官方文档中的描述：

这部分建议阅读 官网文档-微服务框架支持

通过阅读Feign + Seata的 配置教程 ，可以得知我们需要配置的就是将 GlobalTransactionScanner 和 DataSourceProxy 加入Spring容器

GlobalTransactionScanner 的配置较为简单，而配置 DataSourceProxy 网上主流的方式是手动配置，如：

这种方式的确简单，却使很多配置项丢失，不是完美的解决方式。完美的解决方式应为在Spring容器初始化后用new DataSourceProxy(dataSource)替换原有dataSource对象。

那么应如何替换呢，春没磨我们可以通过实现Spring提供的ApplicationContextAware接口来获取ApplicationContext。而ApplicationContext值有getBean()，而不能移除之前的dataSource。我们先看一张继承关系图：

虽然ApplicationContext不能直接向下转型为DefaultListableBeanFactory，但我们可以通过ApplicationContext中持有的AutowireCapableBeanFactory向下转型为DefaultListableBeanFactory，从而通过它来获取、删除和注册Bean。

参考链接：

86 SpringCloud解决分布式事务

1，分布式事务产生的背景；

分情况而定。

1，在单体项目中，多个不同的业务逻辑都是在同一个数据源中心实现事务管理，是不存在分布式事务的问题。因为在同一个数据源的情况下都是采用事务管理器，相当于每个事务管理器对应一个数据源。

2，在单体项目中，有多个不同的数据源，每个数据源中都有自己独立的事务管理器，互不影响，那么这时候也会存在多数据源事务管理：解决方案jta+Atomikos

3，在分布式/微服务架构中。每个服务都有自己的本地的事务。每个服务本地事务互不影响，那么这时候也会存在分布式事务的问题。

分布式事务产生的背景：订单服务调用派单服务接口成功之后，可能会引发错误。

2pc3pc思想，实际上都是解决我们在分布式系统中，每个节点保证数据一致性问题。

事务的定义。

对我们业务逻辑可以实现提交或者是回滚，保证数据一致性的情况。所以，要么提交，要么回滚。

原子性a 要么提交 要么回滚。

一致性 c

持久性d 事务一旦提交或者回滚后，不会再对该结果有任何的影响。

Base 与 cap理论。

1，cap定律

这个定理的内容是指的是在一个分布式系统中,Consistency（一致性），Availability（可用性），Partition tolerance(分区容错性)，二者不可兼容。

1，一致性（C）

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

2，可用性 A

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

3，分区容错性（p） 形成脑裂问题：

以实际效果而言，分区相当于对通信的时限要求，系统如果不能再时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

4，总结下

以上可以知道分区容错性（P）主要代表网络波动产生的错误，这是不可以避免的，且这三个模式不可以兼得，所以目前就2种模式: cp和Ap模式。

其中cp表示遵循一致性的原则，但不能保证高可用性，其中zookeeper作为注册中心就是采用cp模式，因为zookeeper有过半节点不可以的话整个zookeeper将不可用。

AP表示遵循于可用性原则，例如Eureka作为注册中心用的是AP模式，因为其为去中心化，采用你中有我我中有你的相互注册方式，只要集群中有一个节点可以使用，整个eureka服务就是可用的，但可能会出现短暂的数据不一致问题。

Ap保证可用性：但是不能保证每个副本数据数据一致性，

cp保证数据一致性；如果有过半的zk节点宕机的情况下，不能保证可用性，但是必须保证每个副本节点之间数据一致性，比如zk。

Base理论：

Base是 Basically Available(基本可用)，Softstate(软状态)和Eventually consistent(最终一致性)三个短语的缩写。Base理论是对CAP定理逐步演化而来的，base理论核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式达到最终一致性缓耐。

1基本可用性；

基本可用是指分布式系统在出现不可预知扰并春故障的时候，允许损失部分可用性，注意：这绝不等于系统不可用。

比如： 响应时间的损失，正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能顺利完成每一笔订单，但是在一些介入大促销购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能被引导在一个降级页面。

2，软状态。

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，既允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3，最终一致性

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到蔽兄一个一致的状态，因此，最终一致性的本质需要系统保证数据能够达成一致，而不需要时时保证系统数据的强一致性。

2pc 与3pC

通过2pc和3pc 思想可以实现保证每个节点的数据一致性问题。

目前主流分布式解决框架

1，单体项目多数据源，可以jta+Atomilos；

2，基于Rabbitmq的形式解决 最终一致性思想；

3，基于Rocketmq解决分布式事务 ，采用事务消息。

4，lcn采用lcn模式，假关闭连接

5，Alibaba的seata 背景强大，已经成为了主流。

以上适合于微服务架构中，不适合于和外部接口保证分布式事务问题。

6，跨语言的方式实现解决分布式事务问题。类似于支付宝回调方式。

2阶段提交协议基本概念。

2阶段提交协议基本概念：

俩阶段提交协议可以理解为2pc，也就是分为参与者和协调者，协调者会通过2次阶段实现数据最终一致性的

2pc和3pc 的区别就是解决参与者超时问题和多加了一层询问。保证了数据传输的可靠性。

简单的回顾下lcn解决分布式事务。

LCN并不生产事务，LCN只是本地事务的协调工

现在官网已经不维护呢，可以参考：GitEE

默认密码为：codingapi

lcn基本实现的原理：

1，发起方与参与方都与我们的lcn保持长连接；

2，发起方调用接口前，先向lcn管理器中申请一个全局的事务分组id;

3,发起方调用接口的时候在请求头里传递事务分组id.

4,参与方获取到请求头中有事务分组的id的，则当前业务逻辑执行完实现假关闭，不会提交或者回滚当前事务，

5，发起方调用完接口后，如果出现异常的情况下，在通知事务协调者回滚事务，这时候事务协调则告诉给参与者回滚当前的事务。

lcn 解决分布式事务的原理：

角色划分

1，全局事务协调者（组长）；

2，发起方---调用接口者；

3，参与方---被别人调用接口

订单（发起方）调用派单（参与方）

1.发起方和参与方都会与我们的全局事务协调者保持长连接；

整合和源码解读

spring-boot 2.1.6.RELEASE+spring-cloud Greenwich.RELEASE +seata 1.4

pom如下：

file.conf

registry.conf:

yml配置：

添加 DataSourceConfiguration

其他模块参照此模块配置，

seata的registry.conf 和file.conf配置和项目配置一致。

添加全局事务：

1,如何学会分析框架的源码？思想有哪些？

A： spring入口角度分析 springbean 生命周期ioc容器底层原理。

B. 报错日志法

2，seata 底层如何解决分布式事务的？

3，seata 如何生成全局xid

4,Seata如何生成前置和后置镜像。

5，seata 如何传递xid的

6， Seata 如何实现逆向回滚

7，如果协调者宕机了，参与事务是回滚还是提交

8，如果协调者宕机发起方没有通知协调者到底是提交还是回滚？

[img]

springcloud整合分布式事务(seata)

一.理论部分

二.实践部分

这里整理了一些落地的分布式事务中间件：

其中凳则裂tx-lcn项目git3.9K的star，5.0以后由于框架兼容了LCN（2pc）、TCC、TXC 三种事务模式，为了区分LCN模式，特此将LCN分布式事务改名为TX-LCN分布式事务枣闭框架。它是一种本地事务协调，本身并不会产生事务，2020年10月之后暂时没有新的提交记录。

seata的git18.7K的star，开源之前的内部版本在阿里经济体内部一直扮演着分布式一致性中间件的角色，帮助经济体平稳的度过历年的双11，对各BU业务进行了有力的支撑。商业化产品GTS 先后在阿里云、金融云进行售卖。Seata分TC、TM和RM三个角色，TC（Server端）为单独服务端部署，TM和RM（Client端）由业务系统集成。

因为项目是使用alibaba springcloud的，并且seata比较活跃，禁受住了双十一的考验，本文使用seata整合目前的项目。

官方文档：

准备工作：

1.客户端依赖引盯码入：

这里需要注意，需要根据自身项目的Spring Cloud Alibaba Version版本进行相应seata版本的选择，以下是Spring Cloud Alibaba个版本与seata版本的对应关系：

如果还是无法启动，可以使用以下依赖：

2.客户端应用配置

注意波浪线处需要相同

3.服务端配置

参考：

关于springcloudseata和springcloudseata原理的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。