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