11.SpringCloud
概述
什么是微服务
微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。
谈谈你对微服务的理解？它有什么优缺点？
微服务是一种架构风格，通过将大型的单体应用划分为比较小的服务单元，从而降低整个系统的复杂度。
优点：
服务部署更灵活：每个应用都可以是一个独立的项目，可以独立部署。不依赖其他服务，耦合性降低。
技术更新灵活：在大型单体应用中，技术要进行更新往往非常困难。而为服务可以根据业务特点，灵活选择技术栈。
应用的性能得到提高：大型单体应用中，往往启动就会成为一个很大的难关。而采用微服务之后，整个系统的性能是能够得到提高的。
更容易组合专门的团队：在单体应用中，团队成员往往需要对系统的各个部分都要有深入的了解，门槛很高。而采用微服务之后，可以给每个微服务组件专门的团队。
代码复用：很多底层服务可以以 REST API 的方式对外提供统一的服务，所有基础服务可以在整个微服务系统中通用。
缺点：
服务调用的复杂性提高了，容易出现很多问题，如：网络问题、容错问题、负载问题、高并发问题等。
产生分布式事务。
测试的难度提升了。
运维难度提升了：对部署、监控、警告等要求变得非常困难。
SOA、分布式、微服务之间有什么关系和区别？
分布式架构师指将单体架构中的各个部分拆分，然后部署不同的集群或进程中去。SOA 和微服务基本上都是分布式架构。
SOA 是一种面向服务的架构，系统的所有服务都注册在总线上。当调用服务时，从总线上查找服务信息，然后调用。
微服务是一种更彻底的面向服务的架构，将系统中各个功能个体抽成一个个小的应用程序，基本保持一个应用对应一个服务的架构。
Spring Cloud 和 Dubbo 有哪些区别？
Spring Cloud 是一个微服务框架，提供了微服务领域中的很多功能组件。Dubbo 是一个 RPC 调用框架，核心是解决服务调用间的问题。Spring Cloud 是一个大而全的框架，Dubbo 侧重于服务调用，所以 Dubbo提供的功能没有 Spring Cloud 全面，但是 Dubbo 的服务调用性能比 Spring Cloud 高。Spring Cloud 和 Dubbo不是对立的，可以结合起来一起使用。
CAP定理
Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。
Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务
BASE理论
BASE理论是对CAP的一种解决思路，包含三个思想：
- Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
- **Soft State（软状态）：**在一定时间内，允许出现中间状态，比如临时的不一致状态。
- Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致
注册中心
概述
Eureka
Eureka的基本架构
Eureka采用了C-S的架构设计，EurekaServer 作为服务注册功能的服务器，他是服务注册中心
而系统中的其他微服务。使用Eureka的客户端连接到EurekaServer并维持心跳连接。这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行，Springcloud的一些其他模块就可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑；
Eureka 包含两个组件：Eureka Server 和 Eureka Client •
Eureka Server提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样 Eureka Server中的服务注册表中将会村粗所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
Eureka Client是一个ava客户端，用于简化Eureka Server的交互，客广端同时也具备一个内置的，使用轮询负载算法的负载均衡器。
在应用启动后，将会向EurekaServer发送心跳（默认周期为30秒）。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除掉（默认周期90秒）
自我保护机制
在发生网络分区故障时，各服务与Eureka之间无法正常通信。各服务本身是健康的，Eureka不应该注销这个服务。
Eureka通过自我保护机制解决这个问题：
当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该Eurekaserver节点会自动退出自我保护模式。
Eureka和ZooKeeper区别
ZooKeeper中的节点服务挂了就要选举 在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的， 选举就是改微服务做了集群，必须有一台主其他的都是从
Eureka各个节点是平等关系,服务器挂了没关系，只要有一台Eureka就可以保证服务可用，数据都是最新的。 如果查询到的数据并不是最新的，就是因为Eureka的自我保护模式导致的
Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper 一样使得整个注册系统瘫痪
ZooKeeper保证的是CP，Eureka保证的是AP
Nacos
Nacos的实现原理
1.客户端provider向nacos server的open api发起调用,把自己的服务地址链接,服务名称注册上去
2.nacos server与服务提供者provider建立心跳机制,用来检测服务状态
3.服务消费者consumer查询出提供服务实例列表
4.并且默认10s去nacos server拉取服务实例列表
5.当服务消费者检测到服务异常,基于UDP协议推送更新
6.服务消费者即可调用
Nacos 心跳机制
nacos内部注册的服务分为两大类
1>临时实例(默认)
2>持久化实例(永久实例)
我们可以通过设置属性来确定他是临时还是永久
cloud:nacos:discovery:# ephemeral设置当前项目启动时注册到nacos的类型 true(默认):临时实例 false:永久实例ephemeral: true
临时实例
默认情况下,启动服务后,每隔5秒会向nacos发送一个"心跳包",这个心跳包中包含了当前服务的基本信息
Nacos收到这个"心跳包"如果发现这个服务的信息不在注册列表中,就进行注册,如果这个服务的信息在注册列表中就表明这个服务还是健康的
如果Nacos15秒内没接收到某个服务的心跳包,Nacos会将这个服务标记为不健康的状态
如果30秒内没有接收到这个服务的心跳包,Nacos会将这个服务从注册列表中剔除
这些时间都是可以通过配置修改的
持久化实例(永久实例)
持久化实例启动时向nacos注册,nacos会对这个实例进行持久化处理
心跳包的规则和临时实例一致,只是不会将该服务从列表中剔除
@LoadBalanced的作用是什么？
描述RestTemplate对象，用于告诉Spring框架，在使用RestTempalte进行服务调用时，这个调用过程会被一个拦截器进行拦截,然后在拦截器内部。启动负载均衡策略。
项目中为什么要定义bootstrap.yml文件？
此文件被读取的优先级比较高，可以在服务启动时读取配置中心的数据
Nacos配置中心宕机了，我们的服务还可以读取到配置信息吗?
可以从内存，客户端获取配置中心的配置信息以后，会将配置信息在本地存储一份
微服务应用中我们的客户端如何从配置中心获取信息？
我们的服务一般会先从内存中读取配置信息，同时我们的微服务还可以定时向nacos配置中心发请求拉取(pull)更新的配置信息。
微服务应用中客户端如何感知配置中心的数据变化？
1.4.x版本以后nacos客户端会基于长轮询机制从nacos获取配置信息，所谓的长轮询就是没有配置更新时，会在nacos服务端的队列进行等待。
Nacos配置中的管理模型是怎样的？
namespace，group，service/data-id
Nacos和Eureka的区别
CAP理论
C一致性,A高可用,P分区容错性
eureka只支持AP
nacos支持CP和AP两种
nacos是根据配置识别CP或AP模式,如果注册Nacos的client节点注册时是ephemeral=true即为临时节点,那么Naocs集群对这个client节点效果就是AP,反之则是CP,即不是临时节点
#false为永久实例，true表示临时实例开启，注册为临时实例
spring.cloud.nacos.discovery.ephemeral=true
连接方式
nacs使用的是netty和服务直接进行连接,属于长连接
eureka是使用定时发送和服务进行联系,属于短连接
服务异常剔除
eureka:
Eureka client在默认情况每隔30s想Eureka Server发送一次心跳,当Eureka Server在默认连续90s秒的情况下没有收到心跳, 会把Eureka client 从注册表中剔除,在由Eureka-Server 60秒的清除间隔,把Eureka client 给下线
EurekaInstanceConfigBean类下
private int leaseRenewalIntervalInSeconds = 30; //心跳间隔30s
private int leaseExpirationDurationInSeconds = 90; //默认90s没有收到心跳从注册表中剔除
EurekaServerConfigBean 类下
private long evictionIntervalTimerInMs = 60000L; //异常服务剔除下线时间间隔
也就是在极端情况下Eureka 服务 从异常到剔除在到完全不接受请求可能需要 30s+90s+60s=3分钟左右(还是未考虑ribbon缓存情况下)
nacos:
nacos client 通过心跳上报方式告诉 nacos注册中心健康状态,默认心跳间隔5秒，
nacos会在超过15秒未收到心跳后将实例设置为不健康状态，可以正常接收到请求
超过30秒nacos将实例删除,不会再接收请求
操作实例方式
nacos:提供了nacos console可视化控制话界面,可以对实例列表进行监听,对实例进行上下线,权重的配置,并且config server提供了对服务实例提供配置中心,且可以对配置进行CRUD,版本管理
eureka:仅提供了实例列表,实例的状态,错误信息,相比于nacos过于简单
自我保护机制
相同点：保护阈值都是个比例，0-1 范围，表示健康的 instance 占全部instance 的比例。
不同点：
1）保护方式不同
Eureka保护方式：当在短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关(eureka.server.enable-self-preservation: false)
Nacos保护方式：当域名健康实例 (Instance) 占总服务实例(Instance) 的比例小于阈值时，无论实例 (Instance) 是否健康，都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量，但是保证了集群的剩余健康实例 (Instance) 能正常工作。
2）范围不同
Nacos 的阈值是针对某个具体 Service 的，而不是针对所有服务的。但 Eureka的自我保护阈值是针对所有服务的。
负载均衡
概述
负载平衡的意义什么？
负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。
Ribbon
Nginx与Ribbon的区别
Nginx是反向代理同时可以实现负载均衡，nginx拦截客户端请求采用负载均衡策略根据upstream配置进行转发，相当于请求通过nginx服务器进行转发。Ribbon是客户端负载均衡，从注册中心读取目标服务器信息，然后客户端采用轮询策略对服务直接访问，全程在客户端操作。
Feign
Ribbon和Feign调用服务的区别
调用方式同：Ribbon需要我们自己构建Http请求，模拟Http请求然后通过RestTemplate发给其他服务，步骤相当繁琐
而Feign则是在Ribbon的基础上进行了一次改进，采用接口的形式，将我们需要调用的服务方法定义成抽象方法保存在本地就可以了，不需要自己构建Http请求了，直接调用接口就行了，不过要注意，调用方法要和本地抽象方法的签名完全一致
Open Feign
什么是openfeign？它的作用是什么？
openfeign是spring cloud在feign的基础上支持了spring mvc 的注解，如@RequesMapping、@GetMapping、@PostMapping等。openfeign还实现与Ribbon的整合。
服务提供者只需要提供 API 接口，而不需要像 dubbo那样需要强制使用 implem ents实现接口，即使用 fegin不要求服务提供者在 Controller使用 implements关键字实现接口。
Feign底层实现原理
openfeign通过包扫描将所有被 @FeignClient注解注释的接口扫描出来，并为每个接口注册一个FeignClientFactoryBean实例。FeignClientFactoryBean是一个FactoryBean，当Spring调用FeignClientFactoryBean的getObject方法时，openfeign返回一个Feign生成的动态代理对象，拦截接口的方法执行。
feign会为代理的接口的每个方法Method都生成一个MethodHandler。
当为接口上的@FeignClient注解的url属性配置服务提供者的url时，其实就是不与Ribbon整合，此时由SynchronousMethodHandler实现接口方法进行远程同步调用。
当接口上的@FeignClient注解的url属性不配置时，且会走负载均衡逻辑，也就是需要与Ribbon整合使用。这时候不再是使用默认的Client（Default）调用接口，而是使用LoadBalancerFeignClient调用接口，由LoadBalancerFeignClient实现与Ribbon的整合。
网关
概述
什么是网关
网关相当于一个网络服务架构的入口，所有网络请求必须通过网关转发到具体的服务。
网关的作用是什么
统一管理微服务请求，权限控制、负载均衡、路由转发、监控、安全控制黑名单和白名单等
网关与过滤器有什么区别
网关是对所有服务的请求进行分析过滤，过滤器是对单个服务而言。
Zuul
什么是Spring Cloud Zuul（服务网关）
Zuul是对SpringCloud提供的成熟对的路由方案，他会根据请求的路径不同，网关会定位到指定的微服务，并代理请求到不同的微服务接口，他对外隐蔽了微服务的真正接口地址。 三个重要概念：动态路由表，路由定位，反向代理：
动态路由表：Zuul支持Eureka路由，手动配置路由，这俩种都支持自动更新
路由定位：根据请求路径，Zuul有自己的一套定位服务规则以及路由表达式匹配
反向代理：客户端请求到路由网关，网关受理之后，在对目标发送请求，拿到响应之后在 给客户端
它可以和Eureka,Ribbon,Hystrix等组件配合使用，
Zuul的应用场景：
- 对外暴露，权限校验，服务聚合，日志审计等
Zuul与Nginx有什么区别？
Zuul是java语言实现的，主要为java服务提供网关服务，尤其在微服务架构中可以更加灵活的对网关进行操作。
Nginx是使用C语言实现，性能高于Zuul，但是实现自定义操作需要熟悉lua语言，对程序员要求较高，可以使用Nginx做Zuul集群。
Getwall
熔断
概述
服务限流
服务限流是指在高并发请求下，为保护系统对服务请求数量进行限制，从而防止系统不被大量请求压垮。在秒杀中，限流是非常重要的。
服务雪崩
多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B 和微服务C又调用其他的微服务，这就是所谓的“扇出〞 如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃
服务降级
当客户端请求服务器端的时候，防止客户端一直等待，不会处理业务逻辑代码，直接返回一个友好的提示给客户端。
服务熔断
在服务降级的基础上更直接的一种保护方式，当在一个统计时间范围内的请求失败数量达到设定值或当前的请求错误率达到设定的错误率阈值时开启断路，之后的请求直接走fallback方法，在设定时间后尝试恢复。
Hystrix
什么是 Hystrix
在分布式系统，我们一定会依赖各种服务，那么这些个服务一定会出现失败的情况，就会导致雪崩，Hystrix就是这样的一个工具，防雪崩利器，它具有服务降级，服务熔断，服务隔离，监控等一些防止雪崩的技术。
Hystrix有四种防雪崩方式:
服务降级：接口调用失败就调用本地的方法返回一个空
服务熔断：接口调用失败就会进入调用接口提前定义好的一个熔断的方法，返回错误信息
服务隔离：隔离服务之间相互影响
服务监控：在服务发生调用时,会将每秒请求数、成功请求数等运行指标记录下来。
Sentinel
分布式事务
概述
Steta
Seata的架构
Seata事务管理中有三个重要的角色：
TC (Transaction Coordinator) - **事务协调者：**维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) - **事务管理器：**定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - **资源管理器：**管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
Seata基于上述架构提供了四种不同的分布式事务解决方案：
- XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
- TCC模式：最终一致的分阶段事务模式，有业务侵入
- AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
- SAGA模式：长事务模式，有业务侵入
无论哪种方案，都离不开TC，也就是事务的协调者。
XA模式
XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。
正常情况：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C1lURPb2-1676986676258)(assets/image-20210724174102768.png)]
异常情况：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vs8LwL9o-1676986676259)(assets/image-20210724174234987.png)]
一阶段：
- 事务协调者通知每个事物参与者执行本地事务
- 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁
二阶段：
- 事务协调者基于一阶段的报告来判断下一步操作
- 如果一阶段都成功，则通知所有事务参与者，提交事务
- 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务
流程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vYJ3mNSJ-1676986676259)(assets/image-20210724174424070.png)]
RM一阶段的工作：
① 注册分支事务到TC
② 执行分支业务sql但不提交
③ 报告执行状态到TC
TC二阶段的工作：
TC检测各分支事务执行状态
a.如果都成功，通知所有RM提交事务
b.如果有失败，通知所有RM回滚事务
RM二阶段的工作：
- 接收TC指令，提交或回滚事务
优缺点
XA模式的优点是什么？
- 事务的强一致性，满足ACID原则。
- 常用数据库都支持，实现简单，并且没有代码侵入
XA模式的缺点是什么？
- 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
- 依赖关系型数据库实现事务
AT模式
基本流程图：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NJ17xmQF-1676986676260)(assets/image-20210724175327511.png)]
阶段一RM的工作：
- 注册分支事务
- 记录undo-log（数据快照）
- 执行业务sql并提交
- 报告事务状态
阶段二提交时RM的工作：
- 删除undo-log即可
阶段二回滚时RM的工作：
- 根据undo-log恢复数据到更新前
流程
AT模式下，当前分支事务执行流程如下：
一阶段：
1）TM发起并注册全局事务到TC
2）TM调用分支事务
3）分支事务准备执行业务SQL
4）RM拦截业务SQL，根据where条件查询原始数据，形成快照。
{"id": 1, "money": 100
}
5）RM执行业务SQL，提交本地事务，释放数据库锁。此时 money = 90
6）RM报告本地事务状态给TC
二阶段：
1）TM通知TC事务结束
2）TC检查分支事务状态
a）如果都成功，则立即删除快照
b）如果有分支事务失败，需要回滚。读取快照数据（{"id": 1, "money": 100}），将快照恢复到数据库。此时数据库再次恢复为100
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OVdlrGqV-1676986676260)(assets/image-20210724180722921.png)]
优缺点
AT模式的优点：
- 一阶段完成直接提交事务，释放数据库资源，性能比较好
- 利用全局锁实现读写隔离
- 没有代码侵入，框架自动完成回滚和提交
AT模式的缺点：
- 两阶段之间属于软状态，属于最终一致
- 框架的快照功能会影响性能，但比XA模式要好很多
TCC模式
TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：
Try：资源的检测和预留；
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0zZcGWun-1676986676261)(assets/image-20210724182937713.png)]
优缺点
TCC模式的每个阶段是做什么的？
- Try：资源检查和预留
- Confirm：业务执行和提交
- Cancel：预留资源的释放
TCC的优点是什么？
- 一阶段完成直接提交事务，释放数据库资源，性能好
- 相比AT模型，无需生成快照，无需使用全局锁，性能最强
- 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
TCC的缺点是什么？
- 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
- 软状态，事务是最终一致
- 需要考虑Confirm和Cancel的失败情况，做好幂等处理
事务悬挂和空回滚
空回滚
当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NMZ0wImJ-1676986676262)(assets/image-20210724183426891.png)]
执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则应该空回滚。
业务悬挂
对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是业务悬挂。
执行try操作时，应当判断cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的try操作，避免悬挂
SAGA模式
在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。
分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
Saga也分为两个阶段：
- 一阶段：直接提交本地事务
- 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yMvahAGF-1676986676262)(assets/image-20210724184846396.png)]
优缺点
优点：
- 事务参与者可以基于事件驱动实现异步调用，吞吐高
- 一阶段直接提交事务，无锁，性能好
- 不用编写TCC中的三个阶段，实现简单
缺点：
- 软状态持续时间不确定，时效性差
- 没有锁，没有事务隔离，会有脏写
AT与XA的区别
简述AT模式与XA模式最大的区别是什么？
- XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
- XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
- XA模式强一致；AT模式最终一致
四种模式对比
我们从以下几个方面来对比四种实现：
- 一致性：能否保证事务的一致性？强一致还是最终一致？
- 隔离性：事务之间的隔离性如何？
- 代码侵入：是否需要对业务代码改造？
- 性能：有无性能损耗？
- 场景：常见的业务场景
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UxhDY2VX-1676986676263)(assets/image-20210724185021819.png)]
执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
Saga也分为两个阶段：
- 一阶段：直接提交本地事务
- 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
[外链图片转存中…(img-yMvahAGF-1676986676262)]
优缺点
优点：
- 事务参与者可以基于事件驱动实现异步调用，吞吐高
- 一阶段直接提交事务，无锁，性能好
- 不用编写TCC中的三个阶段，实现简单
缺点：
- 软状态持续时间不确定，时效性差
- 没有锁，没有事务隔离，会有脏写
AT与XA的区别
简述AT模式与XA模式最大的区别是什么？
- XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
- XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
- XA模式强一致；AT模式最终一致
四种模式对比
我们从以下几个方面来对比四种实现：
- 一致性：能否保证事务的一致性？强一致还是最终一致？
- 隔离性：事务之间的隔离性如何？
- 代码侵入：是否需要对业务代码改造？
- 性能：有无性能损耗？
- 场景：常见的业务场景
[外链图片转存中…(img-UxhDY2VX-1676986676263)]
11.SpringCloud相关推荐
- 11.springcloud的springconfig配置
分为2个步骤 示例代码: github地址 一.配置类服务器的搭建 1.登录github.com,创建一个自己的账号和仓库,并获取仓库地址: debugggcloud_config_demo 2.从本 ...
- JAVA Cloud微服务项目实战课程 SpringBoot 2.x +SpringCloud 微服务课程
课程目录 第1章 课程介绍 课程导学和学习建议 1-1 SpringCloud导学 1-2 获取源码说明 1-3 提问建议 1-4 点餐项目演示说明 第2章 微服务介绍 什么是微服务, 单体架构优缺点 ...
- 白话SpringCloud | 第八章：分布式配置中心的服务化及动态刷新
前言 上一章节,简单介绍了分布式配置中心Spring Cloud Config的使用.同时,我们也遗漏了一些问题,比如如何配置实时生效,当服务端地址变更或者集群部署时,如何指定服务端地址?回想,在服务 ...
- springcloud 03_SpringCloud概述
微服务概述? 业界大牛马丁.福勒(Martin Fowler) 这样描述微服务: 论文网址: https://martinfowler.com/articles/microservices.html ...
- 查漏补缺：2020年搞定SpringCloud面试（含答案和思维导图）
前言 Spring Cloud是一系列框架的有序集合.它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册.配置中心.消息总线.负载均衡.断路器.数据监控等,都 ...
- SpringCloud+SpringCloudAlibaba
版本选择: SpringBoot:2.6.11 SpringCloud:2021.0.4(由SpringCloud决定SpringBoot的版本) SpringCloudAlibaba:2021.0. ...
- SpringCloud分布式架构详解
SpringCloud分布式架构详解 1. SpringCloud架构概述 1.1 SpringCloud架构简介 1.2 SpringBoot与SpringCloud依赖关系 1.3 SpringC ...
- SpringCloud微服务治理技术入门
1.集群.分布式.微服务 首先先理解三个感念 什么是集群?: 同一个业务,部署在多个服务器上,目的是实现高可用,保证节点可用! 什么是分布式?: 一个业务分拆成多个子业务,部署在不同的服务器上,每个子 ...
- Springcloud、分布式和微服务经典面试题
1.什么是分布式 根据功能进行拆分,分散压力. 2.什么是微服务 根据业务进行拆分,分散能力 3.分布式和微服务的区别 架构不同:微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务.微服 ...
最新文章
- Node.js Express 框架 Express
- 两个链表的第一个公共节点分析
- MATLAB语法基础
- 项目上线，php的错误信息必须不让其在页面中显示给客户，
- P1334 瑞瑞的木板
- day32 并发编程之锁
- 深挖Kubernetes存储为何如此难及其解决方案
- Hexo 入门指南（一） - 简介 准备
- “反催收”渐成黑灰产业 专家呼吁协同治理“债闹”黑灰产
- R语言-数据清洗-缺失值处理
- 自己实现的数值到大写人民币的实现
- docker改变镜像源
- 《回话的技术》阅读笔记
- 京东放大镜效果实现 + 原理分析
- linux离线日志分析工具,loganalyzer——日志分析工具
- Python结巴中文分词工具使用过程中遇到的问题及解决方法
- Uploadifive上传
- SAP中文档管理用户需求与简要分析笔记
- iOS 18位社会信用代码验证
- `Caché/IRIS` 代码优化效率提升十一条 - 持续更新