SpringCloud常用组件

• 注册中心：Eureka、Nacos
• 负载均衡：Ribbon
• 远程调用：OpenFeign
• 网关组件：Zuul、Gateway
• 服务保护：Hystrix、Sentinel
• 服务配置管理组件：SpringCloudConfig、Nacos

微服务保护（Sentinel）

Sentinel默认监控SpringMVC下的Controller里的资源，其他资源如service需要被监控的话，需要加注解==@SentinelResource(“resourceName”)==，热点参数限流对默认的SpringMVC资源无效，使用热点参数限流是也需要在对应的资源上添加注解

雪崩问题及解决方案

• 雪崩：微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。

• 缓存雪崩：当缓存中有大量的key在同一时刻过期，或者Redis直接宕机了，导致大量的查询请求全部到达数据库，造成数据库查询压力骤增，甚至直接挂掉。

针对雪崩问题的解决方式：

• 超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待。只能起到缓解作用。
• 舱壁模式：限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。解决了雪崩问题，但在一定程度上浪费了服务器资源。
• 熔断降级：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。
• 流量控制：限制业务访问的QPS，避免服务因流量的突增而故障。预防雪崩的出现

缓存雪崩的解决方案：

• 针对大量key同时过期的情况，只需要将每个key的过期时间打散，使它们的失效点尽可能分布均匀
• 针对Redis发生故障，部署Redis时可以使用Redis的几种高可用方案：主从（masterslave）架构、哨兵（Sentinel）机制、Redis集群

1、流量控制

流控模式：

• 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
• 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流。例如有查询订单和修改订单两个业务，对查询订单添加关联规则，关联到修改订单，那么，当修改订单资源达到阈值时，对查询订单进行限流。满足“两个有竞争关系的资源”和“一个优先级高，一个优先级较低”这两个条件可以使用关联模式
• 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

流控效果

• 快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常429。默认处理方式
• warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式的阈值会动态变化，从一个较小的值逐渐增加到最大阈值。请求阈值初始值是threshold/coldFactor，持续指定时长后，逐渐提高到threshold值。而codeFactor的默认值为3
• 排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长。

2、线程隔离

• 信号量隔离：基于计数器模式，简单，开销小，适合高扇出场景，如gateway网关
• 线程池隔离：基于线程池隔离，有额外开销，但隔离控制更强，适合低扇出场景

3、熔断降级

降级规则主要通过熔断策略实现

• 慢调用：业务的响应时长（RT）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断。
• 异常比例或异常数：统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常比例达到设定的比例阈值（或超过指定异常数），则触发熔断。

4、配置管理模式

• 原始模式：保存在内存，重启服务会丢失
• pull模式：保存在本地文件或数据库，定时去读取，时效性差
• push模式：保存在nacos，监听变更实时更新

CAP原理

• Consistency（一致性）：用户访问分布式系统中的任意结点，得到的数据必须一致
• Availability（可用性）：用户访问集群中的任意健康节点，必须得到响应，而不是超时或拒绝
• Partition tolerance（分区容错）：因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立分区。在集群出现分区时，整个系统也要持续对外提供服务。

分布式系统节点通过网络连接，一定会出现分布问题（p)，当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足。

ES集群出现分区时，故障节点会被剔除集群，数据分片会重新分配到其他节点，保证数据一致。因此是低可用性，高一致性，属于CP。

BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

• Basically Available（基本可用）：分布式系统出现故障时，允许损失部分可用性，即保证核心可用。
• Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
• Eventually Consistent（最终一致性）：虽然无法保证一致性，但是在软状态结束后，最终达到数据一致。

Seata架构

事务管理中的三个角色：

• TC（Transaction Coordinator）事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
• TM（Transaction Manager）事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
• RM（Resource Manager）资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

四种不同的分布式事务解决方案：

XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入。

• 优点：（1）事务的强一致性，满足ACID原则 （2）常用数据库都支持，实现简单且没有代码侵入
• 缺点：（1）一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差。（2）依赖关系型数据库实现事务

AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式

AT模式由于一阶段执行SQL语句后直接提交事务，释放数据库资源，性能比较好，但由此可能会造成脏读问题。为此引用了全局锁来实现读写隔离

$\textcolor{RED}{AT模式与XA模式最大的区别是什么？}$

• XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源
• XA模式依赖数据库机制实现回滚；AT 模式利用快照实现数据回滚
• XA模式强一致，AT模式最终一致

TCC模式：最终一致的分阶段事务模式，有业务侵入

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

• Try：资源的检测和预留
• Confirm：完成资源操作业务，要求Try成功Confirm一定要能成功
• Cancel：预留资源释放，可以理解为try的反向操作

• 优点：（1）一阶段直接提交事务，释放数据库资源，性能好；（2）相比AT模型，无须生成快照，无须使用全局锁，性能最强；（3）不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

• 缺点：（1）有代码侵入，try、confirm和cancel三个接口都需要认为编写；（2）软状态，最终一致；（3）需要考虑confirm和cancel的失败情况，做好==幂等==处理

SAGA模式：长事务模式，有业务侵入

一阶段：直接提交本地事务

二阶段：成功则什么都不做，失败则通过编写补偿业务来回滚

• 优点：（1）事务参与者可以基于事件驱动实现异步调用，吞吐高。（2）一阶段直接提交事务，无锁，性能好。（3）不用编写TCC中的三个阶段，实现简单
• 缺点：（1）软状态持续时间不确定，时效性差。（2）没有锁，没有事务隔离，会有脏写