养殖企业网站模板,免费浏览器加速器,制作网页的颜色模式为,赣州58同城网招聘找工作目录
目录
SpringCloud
Spring Cloud 的5大组件
服务注册
Eureka Nacos
Eureka和Nacos的对比
负载均衡
负载均衡流程
Ribbon负载均衡策略
自定义负载均衡策略
熔断、降级
服务雪崩
服务降级
服务熔断
服务监控
为什么需要监控
服务监控的组件
skywalking 业务…目录
目录
SpringCloud
Spring Cloud 的5大组件
服务注册
Eureka Nacos
Eureka和Nacos的对比
负载均衡
负载均衡流程
Ribbon负载均衡策略
自定义负载均衡策略
熔断、降级
服务雪崩
服务降级
服务熔断
服务监控
为什么需要监控
服务监控的组件
skywalking 业务相关
限流
为什么要限流
QPS
TPS
QPS 与 TPS 区别
限流的实现方式
Nginx限流漏桶算法
网关限流令牌桶算法
分布式事务
CAP定理
CAP定理- Consistency
CAP定理- Availability
CAP定理-Partition tolerance
BASE理论
Seata框架
Seata架构
编辑
seata的XA模式
seata的AT模式
seata的TCC模式
MQ模式实现分布式事务
分布式服务接口幂等
接口幂等
tokenredis解决接口幂等问题
分布式锁解决接口幂等问题
分布式任务调度
xxl-job
解决的问题
路由策略
解决任务执行失败
大数据量任务需同时执行
常见面试题 SpringCloud
Spring Cloud 的5大组件 通常情况下 Eureka : 注册中心Ribbon : 负载均衡Feign : 远程调用Hystrix : 服务熔断Zuul/Gateway : 网关 随着SpringCloudAlibba在国内兴起 , 我们项目中使用了一些阿里巴巴的组件 注册中心/配置中心 Nacos负载均衡 Ribbon服务调用 Feign服务保护 sentinel服务网关 Gateway 服务注册
常见的注册中心eureka、nocas、zookeeper
先解释一下几个专有名词
服务注册服务提供者需要把自己的信息注册到eureka由eureka来保存这些信息比如服务名称、ip、端口等等。
服务发现消费者向eureka拉取服务列表信息如果服务提供者有集群则消费者会利用负载均衡算法选择一个发起调用。
服务监控服务提供者会每隔30秒向eureka发送心跳报告健康状态如果eureka服务90秒没接收到心跳从eureka中剔除。
Eureka Nacos Eureka和Nacos的对比
Nacos与eureka的共同点注册中心 都支持服务注册和服务拉取都支持服务提供者心跳方式做健康检测 Nacos与Eureka的区别注册中心 Nacos支持服务端主动检测提供者状态临时实例采用心跳模式非临时实例采用主动检测模式。 临时实例心跳不正常会被剔除非临时实例则不会被剔除。Nacos支持服务列表变更的消息推送模式服务列表更新更及时。Nacos集群默认采用AP方式当集群中存在非临时实例时采用CP模式Eureka采用AP方式。 Nacos与Eureka的区别配置中心
Nacos还支持了配置中心eureka则只有注册中心也是选择使用nacos的一个重要原因
负载均衡
负载均衡流程 Ribbon负载均衡策略 RoundRobinRule简单轮询服务列表来选择服务器WeightedResponseTimeRule按照权重来选择服务器响应时间越长权重越小RandomRule随机选择一个可用的服务器BestAvailableRule忽略那些短路的服务器并选择并发数较低的服务器RetryRule重试机制的选择逻辑AvailabilityFilteringRule可用性敏感策略先过滤非健康的再选择连接数较小的实例 ZoneAvoidanceRule以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询 自定义负载均衡策略
方法一创建类实现IRule接口可以指定负载均衡策略全局。 方法二在客户端的配置文件中可以配置某一个服务调用的负载均衡策略局部 熔断、降级
服务雪崩
一个服务失败导致整条链路的服务都失败的情形。 服务降级
服务降级是服务自我保护的一种方式或者保护下游服务的一种方式用于确保服务不会受请求突增影响变得不可用确保服务不会崩溃。 代码实现
通过feign进行远程调用并规定服务降级逻辑。 服务降级逻辑 如果降级太多则会触发熔断机制。
服务熔断 Hystrix 熔断机制用于监控微服务调用情况 默认是关闭的如果需要开启需要在引导类上添加注解EnableCircuitBreaker 如果检测到 10 秒内请求的失败率超过 50%就触发熔断机制。之后每隔 5 秒重新尝试请求微服务如果微服务不能响应继续走熔断机制。如果微服务可达则关闭熔断机制恢复正常请求。 服务监控
为什么需要监控 问题定位性能分析服务关系服务告警 服务监控的组件 Springboot-adminprometheusGrafanazipkin 链路追踪工具skywalking 链路追踪工具 skywalking
一个分布式系统的应用程序性能监控工具 Application Performance Managment 提供了完善的链路追踪能力 apache的顶级项目前华为产品经理吴晟主导开源。 1skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢我们可以针对性的分析和优化。 2我们还在skywalking设置了告警规则特别是在项目上线以后如果报错我们分别设置了可以给相关负责人发短信和发邮件第一时间知道项目的bug情况第一时间修复。 业务相关
限流
为什么要限流 并发量大突发流量防止用户恶意刷接口 下面解释一下几个专有名词QPS、TPS
QPS
Queries Per Second每秒查询数。每秒能够响应的查询次数。
QPS 是一台服务器每秒能够相应的查询次数即1秒内完成的请求数量是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准
QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准在因特网上作为域名系统服务器的机器的性能经常用每秒查询率来衡量。每秒的响应请求数也即是最大吞吐能力。
TPS
Transactions Per Second 的缩写每秒处理的事务数目。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时收到服务器响应后结束计时以此来计算使用的时间和完成的事务个数最终利用这些信息作出的评估分。
TPS 的过程包括客户端请求服务端、服务端内部处理、服务端返回客户端。
例如访问一个 Index 页面会请求服务器 3 次包括一次 html一次 css一次 js那么访问这一个页面就会产生一个“T”产生三个“Q”。
QPS 与 TPS 区别
QPS基本类似于TPS但是不同的是对于一个Web页面的一次访问形成一个TPS就做一件事儿打开Web网页但一次Web页面请求可能产生多次对服务器的请求html、css、js、images、files等服务器对这些请求就可计入QPS之中。每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时收到服务器响应后结束计时以此来计算使用的时间和完成的事务个数。
如果是对一个接口单场景压测且这个接口内部不会再去请求其它接口那么TPS等于QPS否则若这个接口内部还会再去请求其它接口下载图片、文件等服务器接口那么 TPS不等于QPS通常是 QPS会大于TPS因为此时一个事务通常包含多次查询请求。
限流的实现方式 Tomcat可以设置最大连接数Nginx漏桶算法网关令牌桶算法自定义拦截器 Nginx限流漏桶算法
控制速率突发流量 语法limit_req_zone key zone rate key:定义限流对象binary_remote_addr就是一种key基于客户端ip限流Zone定义共享存储区来存储访问信息10m可以存储16wip地址访问信息Rate最大访问速率rate10r/s 表示每秒最多请求10个请求burst20相当于桶的大小Nodelay快速处理 控制并发连接数 limit_conn perip 20对应的key是 $binary_remote_addr表示限制单个IP同时最多能持有20个连接。limit_conn perserver 100对应的key是 $server_name表示虚拟主机(server) 同时能处理并发连接的总数。 网关限流令牌桶算法
yml配置文件中微服务路由设置添加局部过滤器RequestRateLimiter key-resolver 定义限流对象 ip 、路径、参数需代码实现使用spel表达式获取replenishRate 令牌桶每秒填充平均速率。brstCapacity 令牌桶总容量。 分布式事务
CAP定理
1998年加州大学的计算机科学家 Eric Brewer 提出分布式系统有三个指标 Consistency一致性 Availability可用性 Partition tolerance 分区容错性 Eric Brewer 说分布式系统无法同时满足这三个指标。 这个结论就叫做 CAP 定理。 CAP定理- Consistency
Consistency一致性用户访问分布式系统中的任意节点得到的数据必须一致。 CAP定理- Availability
Availability 可用性用户访问集群中的任意健康节点必须能得到响应而不是超时或拒绝。 CAP定理-Partition tolerance
Partition分区因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接形成独立分区。
Tolerance容错在集群出现分区时整个系统也要持续对外提供服务。 结论 分布式系统节点之间肯定是需要网络连接的分区P是必然存在的如果保证访问的高可用性A,可以持续对外提供服务但不能保证数据的强一致性--AP如果保证访问的数据强一致性C,就要放弃高可用性 -- CP BASE理论
BASE理论是对CAP的一种解决思路包含三个思想 Basically Available 基本可用分布式系统在出现故障时允许损失部分可用性即保证核心可用。Soft State软状态在一定时间内允许出现中间状态比如临时的不一致状态。Eventually Consistent最终一致性虽然无法保证强一致性但是在软状态结束后最终达到数据一致。 Seata框架
Seata架构
Seata事务管理中有三个重要的角色 TC (Transaction Coordinator) - 事务协调者维护全局和分支事务的状态协调全局事务提交或回滚。TM (Transaction Manager) - 事务管理器定义全局事务的范围、开始全局事务、提交或回滚全局事务。RM (Resource Manager) - 资源管理器管理分支事务处理的资源与TC交谈以注册分支事务和报告分支事务的状态并驱动分支事务提交或回滚。 seata的XA模式
该模式满足CAP定理中的CP保证了强一致性但是性能不强。
RM一阶段的工作 注册分支事务到TC执行分支业务sql但不提交报告执行状态到TC TC二阶段的工作 TC检测各分支事务执行状态如果都成功通知所有RM提交事务如果有失败通知所有RM回滚事务 RM二阶段的工作 接收TC指令提交或回滚事务 seata的AT模式
该模式满足CAP定理中的AP性能强但是无法保证强一致性。
AT模式同样是分阶段提交的事务模型不过缺弥补了XA模型中资源锁定周期过长的缺陷。
阶段一RM的工作 注册分支事务记录undo-log数据快照执行业务sql并提交报告事务状态 阶段二提交时RM的工作 删除undo-log即可 阶段二回滚时RM的工作 根据undo-log恢复数据到更新前 seata的TCC模式
该模式满足CAP定理中的AP性能强但是无法保证强一致性。 Try资源的检测和预留。Confirm完成资源操作业务要求 Try 成功 Confirm 一定要能成功。Cancel预留资源释放可以理解为try的反向操作。 MQ模式实现分布式事务
在A服务写数据的时候需要在同一个事务内发送消息到另外一个事务异步性能最好但是一致性很差。 分布式服务接口幂等
幂等: 多次调用方法或者接口不会改变业务状态可以保证重复调用的结果和单次调用的结果一致。
需要幂等场景 用户重复点击(网络波动)MQ消息重复应用使用失败或超时重试机制 接口幂等
基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析
请求方式说明GET查询操作天然幂等POST新增操作请求一次与请求多次造成的结果不同不是幂等的PUT更新操作如果是以绝对值更新则是幂等的。如果是通过增量的方式更新则不是幂等的DELETE删除操作根据唯一值删除是幂等的
tokenredis解决接口幂等问题
应用场景创建商品、提交订单、转账、支付等操作。 在查看商品的页面生成token 在提交订单的页面进行token验证 分布式锁解决接口幂等问题
需要注意的是要让请求快速失败抢不到锁的线程控制锁的粒度。
public void saveOrder(Item item) throws InterruptedException {//获取锁重入锁执行锁的名称RLock lock redissonClient.getLock(heimalock);//尝试获取锁参数分别是获取锁的最大等待时间期间会重试锁自动释放时
//间时间单位boolean isLock lock.tryLock(10, TimeUnit.SECONDS);try {//判断是否获取成功if (!isLock) {log.info(下单操作获取锁失败,order:{},item);throw new RuntimeException(新增或修改失败);}//下单操作} finally {//释放锁lock.unlock();}
}分布式任务调度
xxl-job
解决的问题 解决集群任务的重复执行问题cron表达式定义灵活定时任务失败了重试和统计任务量大分片执行 路由策略
路由策略就是指的以某种规则将任务交给执行器微服务去执行。
下面是常见的路由策略 FIRST第一个固定选择第一个机器LAST最后一个固定选择最后一个机器ROUND轮询RANDOM随机随机选择在线的机器CONSISTENT_HASH一致性HASH每个任务按照Hash算法固定选择某一台机器且所有任务均匀散列在不同机器上。LEAST_FREQUENTLY_USED最不经常使用使用频率最低的机器优先被选举LEAST_RECENTLY_USED最近最久未使用最久未使用的机器优先被选举FAILOVER故障转移按照顺序依次进行心跳检测第一个心跳检测成功的机器选定为目标执行器并发起调度BUSYOVER忙碌转移按照顺序依次进行空闲检测第一个空闲检测成功的机器选定为目标执行器并发起调度SHARDING_BROADCAST(分片广播)广播触发对应集群中所有机器执行一次任务同时系统自动传递分片参数可根据分片参数开发分片任务 解决任务执行失败
将路由规则设置为故障转移并且设置失败重试 查看日志分析 邮件告警 大数据量任务需同时执行
执行器集群部署时任务路由策略选择分片广播情况下一次任务调度将会广播触发对应集群中所有执行器执行一次任务。 执行器需要定义的任务代码
分片参数 index当前分片序号(从0开始)执行器集群列表中当前执行器的序号total总分片数执行器集群的总机器数量 XxlJob(shadingSample)
public void shardingJobHandler() throws Exception {// 分片参数int shardIndex XxlJobHelper.getShardIndex();int shardTotal XxlJobHelper.getShardTotal();XxlJobHelper.log(分片参数当前分片序号 {}, 总分片数 {}, shardIndex, shardTotal);// 业务逻辑ListInteger list getList();for (Integer integer : list) {if(integer % shardTotal shardIndex){System.out.println(第shardIndex分片执行执行数据为integer);}}
}常见面试题 面试官Spring Cloud 5大组件有哪些 候选人 早期我们一般认为的Spring Cloud五大组件是 Eureka : 注册中心 Ribbon : 负载均衡 Feign : 远程调用 Hystrix : 服务熔断 Zuul/Gateway : 网关 随着SpringCloudAlibba在国内兴起 , 我们项目中使用了一些阿里巴巴的组件 注册中心/配置中心 Nacos 负载均衡 Ribbon 服务调用 Feign 服务保护 sentinel 服务网关 Gateway 面试官服务注册和发现是什么意思Spring Cloud 如何实现服务注册发现 候选人 我理解的是主要三块大功能分别是服务注册 、服务发现、服务状态监控 我们当时项目采用的eureka作为注册中心这个也是spring cloud体系中的一个核心组件 服务注册服务提供者需要把自己的信息注册到eureka由eureka来保存这些信息比如服务名称、ip、端口等等 服务发现消费者向eureka拉取服务列表信息如果服务提供者有集群则消费者会利用负载均衡算法选择一个发起调用 服务监控服务提供者会每隔30秒向eureka发送心跳报告健康状态如果eureka服务90秒没接收到心跳从eureka中剔除 面试官我看你之前也用过nacos、你能说下nacos与eureka的区别 候选人 我们当时xx项目就是采用的nacos作为注册中心选择nacos还要一个重要原因就是它支持配置中心不过nacos作为注册中心也比eureka要方便好用一些主要相同不同点在于几点 共同点 Nacos与eureka都支持服务注册和服务拉取都支持服务提供者心跳方式做健康检测 Nacos与Eureka的区别 ①Nacos支持服务端主动检测提供者状态临时实例采用心跳模式非临时实例采用主动检测模式 ②临时实例心跳不正常会被剔除非临时实例则不会被剔除 ③Nacos支持服务列表变更的消息推送模式服务列表更新更及时 ④Nacos集群默认采用AP方式当集群中存在非临时实例时采用CP模式Eureka采用AP方式 面试官你们项目负载均衡如何实现的 ? 候选人 是这样~~ 在服务调用过程中的负载均衡一般使用SpringCloud的Ribbon 组件实现 , Feign的底层已经自动集成了Ribbon , 使用起来非常简单 当发起远程调用时ribbon先从注册中心拉取服务地址列表然后按照一定的路由策略选择一个发起远程调用一般的调用策略是轮询 面试官Ribbon负载均衡策略有哪些 ? 候选人 我想想啊有很多种我记得几个 RoundRobinRule简单轮询服务列表来选择服务器 WeightedResponseTimeRule按照权重来选择服务器响应时间越长权重越小 RandomRule随机选择一个可用的服务器 ZoneAvoidanceRule区域敏感策略以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认) 面试官如果想自定义负载均衡策略如何实现 ? 候选人 提供了两种方式 1创建类实现IRule接口可以指定负载均衡策略这个是全局的对所有的远程调用都起作用 2在客户端的配置文件中可以配置某一个服务调用的负载均衡策略只是对配置的这个服务生效远程调用 面试官什么是服务雪崩怎么解决这个问题 候选人 服务雪崩是指一个服务失败导致整条链路的服务都失败的情形一般我们在项目解决的话就是两种方案第一个是服务降级第二个是服务熔断如果流量太大的话可以考虑限流 服务降级服务自我保护的一种方式或者保护下游服务的一种方式用于确保服务不会受请求突增影响变得不可用确保服务不会崩溃一般在实际开发中与feign接口整合编写降级逻辑 服务熔断默认关闭需要手动打开如果检测到 10 秒内请求的失败率超过 50%就触发熔断机制。之后每隔 5 秒重新尝试请求微服务如果微服务不能响应继续走熔断机制。如果微服务可达则关闭熔断机制恢复正常请求 面试官你们的微服务是怎么监控的 候选人 我们项目中采用的skywalking进行监控的 1skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢我们可以针对性的分析和优化。 2我们还在skywalking设置了告警规则特别是在项目上线以后如果报错我们分别设置了可以给相关负责人发短信和发邮件第一时间知道项目的bug情况第一时间修复 面试官你们项目中有没有做过限流 ? 怎么做的 ? 候选人 我当时做的xx项目采用就是微服务的架构因为xx因为应该会有突发流量最大QPS可以达到2000但是服务支撑不住我们项目都通过压测最多可以支撑1200QPS。因为我们平时的QPS也就不到100为了解决这些突发流量所以采用了限流。 【版本1】 我们当时采用的nginx限流操作nginx使用的漏桶算法来实现过滤让请求以固定的速率处理请求可以应对突发流量我们控制的速率是按照ip进行限流限制的流量是每秒20 【版本2】 我们当时采用的是spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流使用的是令牌桶算法可以根据ip或路径进行限流可以设置每秒填充平均速率和令牌桶总容量 面试官限流常见的算法有哪些呢 候选人 比较常见的限流算法有漏桶算法和令牌桶算法 漏桶算法是把请求存入到桶中以固定速率从桶中流出可以让我们的服务做到绝对的平均起到很好的限流效果 令牌桶算法在桶中存储的是令牌按照一定的速率生成令牌每个请求都要先申请令牌申请到令牌以后才能正常请求也可以起到很好的限流作用 它们的区别是漏桶和令牌桶都可以处理突发流量其中漏桶可以做到绝对的平滑令牌桶有可能会产生突发大量请求的情况一般nginx限流采用的漏桶spring cloud gateway中可以支持令牌桶算法 面试官什么是CAP理论 候选人 CAP主要是在分布式项目下的一个理论。包含了三项一致性、可用性、分区容错性 一致性(Consistency)是指更新操作成功并返回客户端完成后所有节点在同一时间的数据完全一致(强一致性)不能存在中间状态。 可用性(Availability) 是指系统提供的服务必须一直处于可用的状态对于用户的每一个操作请求总是能够在有限的时间内返回结果。 分区容错性(Partition tolerance) 是指分布式系统在遇到任何网络分区故障时仍然需要能够保证对外提供满足一致性和可用性的服务除非是整个网络环境都发生了故障。 面试官为什么分布式系统中无法同时保证一致性和可用性 候选人 嗯是这样的~~ 首先一个前提对于分布式系统而言分区容错性是一个最基本的要求因此基本上我们在设计分布式系统的时候只能从一致性C和可用性A之间进行取舍。 如果保证了一致性C对于节点N1和N2当往N1里写数据时N2上的操作必须被暂停只有当N1同步数据到N2时才能对N2进行读写请求在N2被暂停操作期间客户端提交的请求会收到失败或超时。显然这与可用性是相悖的。 如果保证了可用性A那就不能暂停N2的读写操作但同时N1在写数据的话这就违背了一致性的要求。 面试官什么是BASE理论 候选人 嗯这个也是CAP分布式系统设计理论 BASE是CAP理论中AP方案的延伸核心思想是即使无法做到强一致性StrongConsistencyCAP的一致性就是强一致性但应用可以采用适合的方式达到最终一致性Eventual Consitency。它的思想包含三方面 1、Basically Available基本可用基本可用是指分布式系统在出现不可预知的故障的时候允许损失部分可用性但不等于系统不可用。 2、Soft state软状态即是指允许系统中的数据存在中间状态并认为该中间状态的存在不会影响系统的整体可用性即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。 3、Eventually consistent最终一致性强调系统中所有的数据副本在经过一段时间的同步后最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致而不需要实时保证系统数据的强一致性。 面试官你们采用哪种分布式事务解决方案 候选人 我们当时是xx项目主要使用到的seata的at模式解决的分布式事务 seata的AT模型分为两个阶段 1、阶段一RM的工作① 注册分支事务 ② 记录undo-log数据快照③ 执行业务sql并提交 ④报告事务状态 2、阶段二提交时RM的工作删除undo-log即可 3、阶段二回滚时RM的工作根据undo-log恢复数据到更新前 at模式牺牲了一致性保证了可用性不过它保证的是最终一致性 面试官分布式服务的接口幂等性如何设计 候选人 嗯我们当时有一个xx项目的下单操作采用的tokenredis实现的流程是这样的 第一次请求也就是用户打开了商品详情页面我们会发起一个请求在后台生成一个唯一token存入rediskey就是用户的idvalue就是这个token同时把这个token返回前端 第二次请求当用户点击了下单操作会后会携带之前的token后台先到redis进行验证如果存在token可以执行业务同时删除token如果不存在则直接返回不处理业务就保证了同一个token只处理一次业务就保证了幂等性 面试官xxl-job路由策略有哪些 候选人 xxl-job提供了很多的路由策略我们平时用的较多就是轮询、故障转移、分片广播… 面试官xxl-job任务执行失败怎么解决 候选人 有这么几个操作 第一路由策略选择故障转移优先使用健康的实例来执行任务 第二如果还有失败的我们在创建任务时可以设置重试次数 第三如果还有失败的就可以查看日志或者配置邮件告警来通知相关负责人解决 面试官如果有大数据量的任务同时都需要执行怎么解决 候选人 我们会让部署多个实例共同去执行这些批量的任务其中任务的路由策略是分片广播 在任务执行的代码中可以获取分片总数和当前分片按照取模的方式分摊到各个实例执行就可以了
