java面试（微服务）

SpringCloud五大组件

1. Nacos：注册中心
2. Ribbon：负载均衡
3. Feign：远程调用
4. sentinel：服务熔断
5. Gateway：网关
   

注册中心

Eureka

Nacos

负载均衡

Ribbon负载均衡流程

Ribbon的负载均衡策略

1. RoundRobinRule：简单的轮询服务列表来选择服务器
2. WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
3. RandomRule：随机选择一个可用的服务器
4. BestAvailableRule：忽略那些短路的服务器，并选择并发数较低的服务器
5. RetryRule：重试机制的选择逻辑
6. AvailabilityFilteringRule：可用性敏感策略，先过滤非健康的，再选择连接数较少的实例
7. ZoneAvoidanceRule：以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房，一个机甲等。而后再对Zone内的多个服务做轮询

自定义负载均衡策略如何实现

可以自己创建IRule接口，然后再通过配置类或者配置文件即可，通过定义IRule实现可以修改负载均衡规则，有两种方式：

服务雪崩

服务降级

服务降级是服务自我保护的一种方式，或者保护下游服务的一种方式，用户确保服务不会受请求突增影响变得不可用，确保服务不会崩溃

如果降级太多则会触发熔断

服务熔断

Hystrix熔断机制，用于监控微服务调用情况，默认是关闭的，如果需要开启需要在引导类上添加注解：@EnableCircuitBreaker，如果检测到10秒内请求的失败率超过50%,就触发熔断机制。之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求。

微服务是怎么监控的

skywalking

一个分布式系统的应用程序性能监控工具（Application Performance Management），提供了完善的链路追踪能力，apache的顶级项目

微服务限流

为什么要限流

1. 并发大
2. 防止用户恶意刷接口

限流的实现方式

1. Tomcat：可以设置最大连接数
2. Ngnix：漏潼算法
3. 网关，令牌桶算法
4. 自定义拦截器

Nginx限流

1. 控制速率（突发流量）
   
   
2. 控制并发连接数
   

网关限流

配置文件中，微服务路由设置添加局部过滤器RequestRateLimiter

漏桶与令牌桶的区别：漏桶的速率绝对固定，令牌桶的速率会变化

CAP和BASE

CAP定理

分布式系统有三个指标：

1. Consistency（一致性）
2. Avaliability（可用性）
3. Partition tolerance（分区容错性）
   分布式系统无法同时满足这三个指标，这个结论就叫做CAP定理
   

Consistency

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须保持一致

Availability

Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝

Partition tolerance

Partition（分区）：因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立分区。
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

结论：

1. 分布式系统节点之间肯定是需要网络连接的，分区（P）是必然存在的
2. 如果保证访问的高可用性（A），可以持续对外提供服务，但不能保证数据的强一致性–>AP
3. 如果保证数据的强一致性（C），就要放弃高可用性–>CP

BASE理论

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

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

分布式事务解决方案

Seata架构

Seata事务管理中有三个重要的角色

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

Seata的XA模式

RM一阶段的工作：
1. 注册分治事务到TC
2. 执行分支业务sql但不提交
3. 报告执行状态到TC
TC二阶段的工作：
1. TC检测各分支事务执行状态
2. 如果都成功，通知所有RM提交事务
3. 如果有失败，通过所有RM回滚事务
RM二阶段的工作:
1. 接收TC指令，提交或回滚事务

Seata的AT模式

AT模式同样是分阶段提交的模型，不过却弥补了XA模型中资源锁定周期过长的缺陷
阶段一RM工作：
1. 注册分支事务
2. 记录undo-log（数据快照）
3. 执行业务sql并提交
4. 报告事务状态
阶段二提交时RM的工作
1. 删除undo-log
阶段二回滚时RM的工作
1. 根据undo-log恢复数据到更新之前

Seata的TCC模式

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

MQ分布式事务

接口幂等性

幂等：多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单词调用的结果一致。
需要幂等场景：

1. 用户重复点击
2. MQ消息重复
3. 应用使用失败或超时重试机制

接口幂等

基于RESTful API的角度对部分常见请求类型的幂等性特点进行分析：

请求方式	说明
GET	查询操作，天然幂等
POST	新增操作，请求一次与请求多次造成的结果不同，不是幂等的
PUT	更新操作，如果是以绝对值更新，则是幂等的。如果是通过增量的方式更新，不幂等
DELETE	删除操作，根据唯一值进行删除，是幂等的

token+redis

分布式锁