JAVA面试专题-微服务篇_微服务java问题

Spring cloud

Spring Cloud 5大组件有哪些

注册中心/配置中心：nacos
负载均衡：Ribbon
服务远程调用：Feign
服务保护：sentinel
服务网关：Gateway

微服务注册和发现

 nacos和eureka的区别

 负载均衡

        微服务向Ribbon发送请求，Ribbon从注册中心中拉取相应的微服务，返回微服务列表，最后选择一个微服务进行调用。

Ribbon负载均衡策略

 自定义负载均衡策略

自己创建类实现IRule接口，再通过配置类（全局生效）或者配置文件（局部生效）即可

服务雪崩

服务雪崩：一个服务失败，导致整条链路的服务都失败的情形。

服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑。

服务熔断：默认关闭，需要手动打开，如果检测到十秒内请求失败率超过百分之五十 ，就触发熔断机制，之后每个五秒重新尝试请求微服务，如果不能响应继续走熔断机制，如果微服务可达，则关闭熔断机制，恢复正常请求。

服务监控

采用skywalking进行监控：

1. skywalking主要可以监控接口、服务、物理实例的一些状态，特别是压测的时候可以看到众多服务中哪些服务的接口比较慢，可以针对性的分析和优化。

2. 在skywalking设置告警规则，当项目上线以后，设置给负责人发短信和邮件，第一时间知道bug修复。

业务相关

限流

限流的实现方式：

Tomcat：可以设置最大连接数
Nginx：漏桶算法

网关：令牌桶算法
自定义拦截器

CAP 和 BASE

CAP定理

Consistency：一致性        Availability：可用性        Partition tolerance：分区容错性

这三个指标无法同时满足，就叫做cap定理

BASE理论

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

解决分布式事务的思想和模型：

1. 最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据（AP）
2. 强一致思想：各分支事务执行完业务不要提交，等待彼此结果，而后统一提交或回滚（CP）

分布式事务解决方案

Seata架构

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

 XA模式：

         TM开启全局事务，调用分支RM，注册分支事务到TC，之后RM执行sql业务但是不提交，向TC报告事务状态。TC检测各分支事务执行状态，如果都成功，则提交，如果有失败则回滚，最后提交事务。

AT模式：

 TM开启全局事务，调用分支RM，向TC注册事务分支，RM执行sql并提交，同时记录更新前后快照undo log，向TC报告实物状态，TM申请提交或者回滚全局事务，TC检查事务分支状态，如果都成功则提交，同时删除undo log，如果有失败，则回顾log数据回滚。

TCC模式：

Try：资源的检测和预留        Confirm：完成资源操作业务        Cancel：预留资源释放

在注册分支事务以后，进行一次资源预留try，报告事务状态，在TC决定提交还是回滚时，如果提价，则confirm，如果回滚则cancel

MQ分布式事务

 

分布式服务接口幂等性

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

如果是新增数据，可以使用数据库唯一索引
如果是新增或者修改数据
        分布式锁，性能较低
        使用token+redis实现，性能较好：第一次请求，生成一个唯一token存入redis返回给前端，第二次请求，携带之前的token，到redis进行验证，如果存在执行业务，删除token，如果不存在，直接返回不处理业务

分布式任务调度

xxl-job路由策略：

大数据量的任务同时都需要执行

执行器集群部署时，任务路由策略选择分片广播，一次任务调度将会广播出发对应急群众所有执行器执行一次任务。

RabbitMQ

RabbitMQ如何保证数据不丢失

 三种情况数据丢失：消息未达到交换机或则消息未到达队列、队列中消息丢失、消费者未接收到消息。

生产者确认机制publisher confirm

消息发送到MQ后，会返回一个结果给发送者，表示消息是否成功。

如果传到给了消费者，就返回ack publish-confirm
如果没有传到MQ中，则返回ack publish-return
如果没传到交换机，则返回 nack publish-confirm

消息失败以后，可以回调方法即使重发，记录日志，或者保存到数据库然后定时重发，成功发送后删除表中数据。

消息持久化

 消费者确认

消息重复消费问题 

解决方案：每条消息设置一个唯一的标识Id

死信交换机

解决延迟队列=死信交换机+TTL（生存时间）

惰性队列

接收消息后存入磁盘而非内存，消费者要消费消息时才会从磁盘中读取并加载到内存，支持数百万条的消息存储。加入lazy（）

RabbitMQ高可用

普通集群

会在集群的各个节点共享部分数据，但不包含队列中的消息，访问集群某节点时，如果队列不在该节点，会从数据所在节点传递到当前节点并返回，队列所在节点宕机，队列中的消息就会消失。

镜像集群

本质是主从模式，交换机，队列，队列消息会在各个mq的镜像节点之间同步备份，创建队列的节点被称为主节点，备份到其他节点的叫镜像节点。所有操作都是主节点完成，然后同步给镜像节点，主宕机后，镜像节点取而代之。

仲裁队列

主从模式，支持主从数据同步，基于Raft协议，强一致。