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协议，强一致。
