16、Elasticsearch集群脑裂问题?
- “脑裂”问题可能的成因:
- 网络问题:集群间的网络延迟导致一些节点访问不到master,认为master挂掉了从而选举出新的master,并对master上的分片和副本标红,分配新的主分片
- 节点负载:主节点的角色既为master又为data,访问量较大时可能会导致ES停止响应造成大面积延迟,此时其他节点得不到主节点的响应认为主节点挂掉了,会重新选取主节点。
- 内存回收:data节点上的ES进程占用的内存较大,引发JVM的大规模内存回收,造成ES进程失去响应。
- 脑裂问题解决方案:
-
***减少误判:***discovery.zen.ping_timeout节点状态的响应时间,默认为3s,可以适当调大,如果master在该响应时间的范围内没有做出响应应答,判断该节点已经挂掉了。调大参数(如6s,discovery.zen.ping_timeout:6),可适当减少误判。
-
选举触发: discovery.zen.minimum_master_nodes:1
- 7.x之前版本:
该参数是用于控制选举行为发生的最小集群主节点数量。当备选主节点的个数大于等于该参数的值,且备选主节点中有该参数个节点认为主节点挂了,进行选举。官方建议为(n/2)+1,n为主节点个数 (即有资格成为主节点的节点个数)
-
7.x之后版本:
不需要手动配置,系统自己会维护最小集群节点数
-
- 角色分离:即master节点与data节点分离,限制角色
- 主节点配置为:
- node.master: true
- node.data: false
- 从节点配置为:
- node.master: false
- node.data: true
- 主节点配置为:
17、Elasticsearch索引文档(写)的流程?
-
协调节点默认使用文档ID参与计算(也支持通过routing),以便为路由提供合适的分片:
shard = hash(document_id) % (num_of_primary_shards)
-
当分片所在的节点接收到来自协调节点的请求后,会将请求写入到Memory Buffer,然后定时(默认是每隔1秒)写入到Filesystem Cache,这个从Memory Buffer到Filesystem Cache的过程就叫做refresh;
-
当然在某些情况下,存在Momery Buffer和Filesystem Cache的数据可能会丢失,ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后,同时也会写入到translog中,当Filesystem cache中的数据写入到磁盘中时,才会清除掉,这个过程叫做flush;
-
在flush过程中,内存中的缓冲将被清除,内容被写入一个新段,段的fsync将创建一个新的提交点,并将内容刷新到磁盘,旧的translog将被删除并开始一个新的translog。
-
flush触发的时机是定时触发(默认30分钟)或者translog变得太大(默认为512M)时;
18、RPC原理是什么?
-
服务消费方(client)调用以本地调用方式调用服务;
-
client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体;
-
client stub找到服务地址,并将消息发送到服务端;
-
server stub收到消息后进行解码;
-
server stub根据解码结果调用本地的服务;
-
本地服务执行并将结果返回给server stub;
-
server stub将返回结果打包成消息并发送至消费方;
-
client stub接收到消息,并进行解码;
-
服务消费方得到最终结果。
19、Springboot和springCloud开发中常用注解
答案:
@EnableDiscoveryClient @SpringBootApplication @Configuration @RestController @EnableFeignClients @EnableDiscoveryClient @FeignClient @ServletComponentScan @MapperScan @EnableTransactionManagement @Bean … |
---|
20、SpringBoot和SpringCloud的区别?
SpringBoot专注于快速方便的开发单个个体微服务。
SpringCloud是关注全局的微服务协调整理治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来,为各个微服务之间提供,配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
SpringBoot可以离开SpringCloud独立使用开发项目, 但是SpringCloud离不开SpringBoot ,属于依赖的关系.
SpringBoot专注于快速、方便的开发单个微服务个体,SpringCloud关注全局的服务治理框架。
21、Spring Cloud 的核心组件有哪些?
Spring Cloud Netflix Eureka:服务注册于发现。
Spring Cloud Netflix Feign:基于动态代理机制,根据注解和选择的机器,拼接请求 url 地址,发起请求。实现服务之间的远程调用。
Spring Cloud Netflix Ribbon:实现负载均衡,从一个服务的多台机器中选择一台。
Spring Cloud Netflix Hystrix:提供线程池,不同的服务走不同的线程池,实现了不同服务调用的隔离,避免了服务雪崩的问题。
Spring Cloud Netflix Zuul:网关管理,由 Zuul 网关转发请求给对应的服务。
Spring Cloud Config:分布式统一配置管理
Spring Cloud Sleuth:实现服务的链路追踪
Spring Cloud Gateway:作为网关,作为分布式系统统一的出入口,进行服务路由,统一鉴权等
Spring Cloud Alibaba Nacos:作为注册中心和配置中心,实现服务注册发现和服务健康监测及配置信息统一管理
Spring Cloud Alibaba Sentinel:实现系统的熔断限流
22、什么是服务熔断?什么是服务降级?
熔断机制是应对雪崩效应的一种微服务链路保护机制。当某个微服务不可用或者响应时间太长时,会进行服务降级,进而熔断该节点微服务的调用,快速返回“错误”的响应信息。
当检测到该节点微服务调用响应正常后恢复调用链路。在Spring Cloud框架里熔断机制通过Hystrix实现,Hystrix会监控微服务间调用的状况,当失败的调用到一定阈值,缺省是5秒内调用20次,如果50%失败,就会启动熔断机制。
服务降级,一般是从整体负荷考虑。就是当某个服务熔断之后,服务器将不再被调用,此时客户端可以自己准备一个本地的fallback回调,返回一个缺省值。这样做,虽然水平下降,但好歹可用,比直接挂掉强。
Hystrix相关注解@EnableHystrix:开启熔断 @HystrixCommand(fallbackMethod=”XXX”),声明一个失败回滚处理函数XXX,当被注解的方法执行超时(默认是1000毫秒),就会执行fallback函数,返回错误提示。
23、Dubbo执行流程是什么样的?各个组件作用
它的架构主要有五个角色/核心组件,分为是Container(容器)、Provider(服务的提供方)、Registry(注册中心)、Consumer(服务的消费方)、Monitor(监控中心)。
- 容器主要负责启动、加载、运行服务提供者;
- 同时服务提供者在启动时,向注册中心注册自己提供的服务;
- 消费者向注册中心订阅自己的服务;
- 注册中心返回服务提供者列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者;
- 对于服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另外一台调用;
- 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心;
注册中心:
-
注册中心只负责地址的注册和查找,相当于我们的目录服务,只有在容器启动时,服务提供者和调用者与注册中心交互,整个过程,注册中心不参与数据传输,不转发请求,压力较小 (“两不一小”);
-
注册中心宕机问题:(Dubbo挂了怎么办?)
注册中心全部宕机之后,服务提供者和服务消费者仍能通过本地缓存通讯;注册中心仍能通过缓存提供服务列表查询,但不能注册新服务;
监控中心:
- 监控中心负责统计各服务调用次数、调用时间等,统计先在内存汇总后每分钟一次发送到监控中心服务器,并以报表展示
- 监控中心宕机不影响使用,只是丢失部分的采样数据;
- dubbo-admin可以通过监控中心的可视化界面,进行禁止服务和截止消费者(大量恶意访问的ip);
24、Nacos作用以及注册中心的原理
Nacos英文全称Dynamic Naming and Configuration Service,Na为naming/nameServer即注册中心,co为configuration即注册中心,service是指该注册/配置中心都是以服务为核心。
Nacos注册中心分为server与client,server采用Java编写,为client提供注册发现服务与配置服务。而client可以用多语言实现,client与微服务嵌套在一起,nacos提供sdk和openApi,如果没有sdk也可以根据openApi手动写服务注册与发现和配置拉取的逻辑。
服务注册原理
服务注册方法:以Java nacos client v1.0.1 为例子,服务注册的策略的是每5秒向nacos server发送一次心跳,心跳带上了服务名,服务ip,服务端口等信息。
同时 nacos server也会向client 主动发起健康检查,支持tcp/http检查。如果15秒内无心跳且健康检查失败则认为实例不健康,如果30秒内健康检查失败则剔除实例。
25、网关三大核心概念
-
Route(路由)
路由是构建网关的基本模块,它由ID,目标URI,一系列的断言和过滤器组成,如果断言为true则匹配**该路由**
-
Predicate(断言)
匹配HTTP请求中的所有内容(例如请求头或请求参数或请求路径等),如果请求与断言相匹配则进行路由
-
Filter(过滤)
指的是Spring框架中GatewayFilter的实例,使用过滤器,可以在请求被路由前或者之后对请求进行修改。
-
总体
Web请求,通过一些匹配条件,定位到真正的服务节点。并在这个转发过程的前后,进行一些精细化控制。
Predicate就是我们的匹配条件: 而Filter,就是可以理解为一个无所不能的拦截器。有了这两个元素,再加上目标uri,就可以实现一个具体的路由了。
26、Spring Cloud Alibaba能干嘛
- 服务限流降级:默认支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ 限流降级功能的接入,可以在运行时通过控制台实时修改限流降级规则,还支持查看限流降级 Metrics 监控。
- 服务注册与发现:适配 Spring Cloud 服务注册与发现标准,默认集成了 Ribbon 的支持。
- 分布式配置管理:支持分布式系统中的外部化配置,配置更改时自动刷新。
- 消息驱动能力:基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。
- 分布式事务:使用 @GlobalTransactional 注解, 高效并且对业务零侵入地解决分布式事务问题。
- 阿里云对象存储:阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。
- 分布式任务调度:提供秒级、精准、高可靠、高可用的定时(基于 Cron 表达式)任务调度服务。同时提供分布式的任务执行模型,如网格任务。网格任务支持海量子任务均匀分配到所有 Worker(schedulerx-client)上执行。
- 阿里云短信服务:覆盖全球的短信服务,友好、高效、智能的互联化通讯能力,帮助企业迅速搭建客户触达通道。
27、什么是分布式事务
分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
指一次大的操作由不同的小操作组成的,这些小的操作分布在不同的服务器上,分布式事务需要保证这些小操作要么全部成功,要么全部失败。
本质上来说,分布式事务就是为了保证不同数据库的数据一致性。
28、分布式事务解决方案
1.XA两段提交(低效率)-分布式事务解决方案
2.TCC三段提交(2段,高效率[不推荐(补偿代码)])
3.本地消息(MQ+Table)
4.事务消息(RocketMQ[alibaba])
5.Seata(alibaba)
29、分布式事务的执行流程
- TM开启分布式事务(TM向TC注册全局事务记录)
- 换业务场景,编排数据库,服务等事务内资源(RM向TC汇报资源准备状态)
- TM结束分布式事务,事务一阶段结束(TM通知TC提交/回滚分布式事务)
- TC汇总事务信息,决定分布式事务是提交还是回滚
- TC通知所有RM提交/回滚资源,事务二阶段结束。
30、Docker组成部分
Docker是一个客户端-服务器(C/S)架构程序。
Docker客户端只需要向Docker服务器或者守护进程发出请求,服务器或者守护进程将完成所有工作并返回结果。
Docker提供了一个命令行工具Docker以及一整套RESTful API。
你可以在同一台宿主机上运行Docker守护进程和客户端,也可以从本地的Docker客户端连接到运行在另一台宿主机上的远程Docker守护进程。