文章目录
Sentinal
1.了解过服务雪崩?
微服务中,服务间调用关系错综复杂,一个微服务往往依赖于多个其它微服务 ,
如果其中一个下游服务出现了问题 , 或者服务器负载比较高 , 处理缓慢,
这个时候就会导致上游服务等待 , 线程得不到释放 , 最后导致服务器资源耗尽宕机,
然后他的上游服务同样如此, 这样因为一个服务导致上游的所有服务都出现问题的线下称之为雪崩
2.如何解决雪崩问题
1 超时处理:设定超时时间,请求超过一定时间没有响应就返回错误信息,不会无休止等待
2 线程隔离/信号量隔离
3 熔断降级
3.你们项目中是如何使用Sentinal的?
sentinel使用非常简单
启动sentinel服务端
在项目找那个引入sentinel启动器
在application.yml中配置sentinel地址
在sentinel中配置各种控制规则
4.Sentinel:支撑的流控模式有哪些?
直接:统计当前资源的请求,触发阈值时对当前资源直接限流,也是默认的模式
关联:统计与当前资源相关的另一个资源,触发阈值时,对当前资源限流
链路:统计从指定链路访问到本资源的请求,触发阈值时,对指定链路限流
5.Sentinel支持的流控效果有哪些?
流控效果是指请求达到流控阈值时应该采取的措施,包括三种:
1 快速失败:达到阈值后,新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
2 warm up:预热模式,对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化,从一个较小值逐渐增加到最大阈值。
3 排队等待:让所有的请求按照先后次序排队执行,两个请求的间隔不能小于指定时长
6 Sentinel是否可以实现对指定热点数据访问限流?
可以, sentinel支持热点参数限流 , 具体就是分别统计参数值相同的请求,判断是否超过QPS阈值。
具体就是需要在控制面板配置热点参数和阈值
7.Sentinel中如何对一个普通的方法限流?
想要使用sentinel限流 , 必须把方法标注为一个sentinel资源,
通过@SentinalResource注解来标注方法即可
8.Sentinel断路器知道嘛?他是怎么工作的
状态机包括三个状态:
- closed:关闭状态,断路器放行所有请求,并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
- open:打开状态,服务调用被熔断,访问被熔断服务的请求会被拒绝,快速失败,直接走降级逻辑。Open状态5秒后会进入half-open状态
half-open:半开状态,放行一次请求,根据执行结果来判断接下来的操作。请求成功:则切换到closed状态请求失败:则切换到open状态
9.Sentinel什么情况下会触发熔断降级?
断路器熔断策略有三种:慢调用、异常比例、异常数 , 可以在sentinel控制台中配置
10.Sentinel限流底层是通过什么机,制实现的
线程池隔离:给每个服务调用业务分配一个线程池,利用线程池本身实现隔离效果
信号量隔离(默认使用):不创建线程池,而是计数器模式,记录业务使用的线程数量,达到信号量上限时,禁止新的请求。
11.Sentinel如何实现对访问来源的控制?
白名单:来源(origin)在白名单内的调用者允许访问
黑名单:来源(origin)在黑名单内的调用者不允许访问
主要做法就是 :
实现RequestOriginParser接口 , 从request对象中,获取请求者的origin值并返回
12.Sentinel中配置的规则是如何保存的?重启之后还生效嘛
现在,sentinel的所有规则都是内存存储,重启后所有规则都会丢失。在生产环境下,我们必须确保这些规则的持久化,避免丢失。
规则是否能持久化,取决于规则管理模式,sentinel支持三种规则管理模式:
原始模式:Sentinel的默认模式,将规则保存在内存,重启服务会丢失。
pull模式 : 控制台将配置的规则推送到Sentinel客户端,而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询,更新本地规则
push模式 :控制台将配置规则推送到远程配置中心,例如Nacos。Sentinel客户端监听Nacos,获取配置变更的推送消息,完成本地配置更新。
开源的sentinel版本中不支持push模式, 需要修改源码实现
ElasticSearch
1什么是ElasticSearch
Elasticsearch 是基于 Lucene 的 Restful 的分布式实时全文搜索引擎,
每个字段都被索引并可被搜索,可以快速存储、搜索、分析海量的数据。
2 ElasticsSearch的基本慨念
(1)index 索引:索引类似于mysql 中的数据库,Elasticesearch 中的索引是存在数据的地方,包含了一堆有相似结构的文档数据。
(2)type 类型:类型是用来定义数据结构,可以认为是 mysql 中的一张表,type 是 index 中的一个逻辑数据分类
(3)document 文档:类似于 MySQL 中的一行,不同之处在于 ES 中的每个文档可以有不同的字段,但是对于通用字段应该具有相同的数据类型,文档是es中的最小数据单元,可以认为一个文档就是一条记录。
(4)Field 字段:Field是Elasticsearch的最小单位,一个document里面有多个field
(5)shard 分片:单台机器无法存储大量数据,es可以将一个索引中的数据切分为多个shard,分布在多台服务器上存储。有了shard就可以横向扩展,存储更多数据,让搜索和分析等操作分布到多台服务器上去执行,提升吞吐量和性能。
(6)replica 副本:任何一个服务器随时可能故障或宕机,此时 shard 可能会丢失,因此可以为每个 shard 创建多个 replica 副本。replica可以在shard故障时提供备用服务,保证数据不丢失,多个replica还可以提升搜索操作的吞吐量和性能。primary shard(建立索引时一次设置,不能修改,默认5个),replica shard(随时修改数量,默认1个),默认每个索引10个 shard,5个primary shard,5个replica shard,最小的高可用配置,是2台服务器。
3倒排索引和正排索引
- 正向索引是最传统的,根据id索引的方式。
但根据词条查询时,必须先逐条获取每个文档,
然后判断文档中是否包含所需要的词条,是根据文档找词条的过程。 - 而倒排索引则相反,是先找到用户要搜索的词条,
根据词条得到保护词条的文档的id,然后根据id获取文档。是根据词条找文档的过程。
正向索引: - 优点:
- 可以给多个字段创建索引
- 根据索引字段搜索、排序速度非常快
- 缺点:
- 根据非索引字段,或者索引字段中的部分词条查找时,只能全表扫描。
倒排索引:
- 根据非索引字段,或者索引字段中的部分词条查找时,只能全表扫描。
- 优点:
- 根据词条搜索、模糊搜索时,速度非常快
- 缺点:
- 只能给词条创建索引,而不是字段
- 无法根据字段做排序
4text和keyword类型的区别
两个的区别主要分词的区别:keyword 类型是不会分词的,
直接根据字符串内容建立倒排索引,keyword类型的字段只能通过精确值搜索到;
Text 类型在存入 Elasticsearch 的时候,会先分词,然后根据分词后的内容建立倒排索引
5 query和filter的区别?
**(1)query:**查询操作不仅仅会进行查询,还会计算分值,用于确定相关度;
**(2)filter:**查询操作仅判断是否满足查询条件,不会计算任何分值,
也不会关心返回的排序问题,同时,filter 查询的结果可以被缓存,提高性能。
6es写数据的过程(ES的写入流程:)
(1)客户端选择一个 node 发送请求过去,这个 node 就是 coordinating node (协调节点)
(2)coordinating node 对 document 进行路由,将请求转发给对应的 node(有 primary shard)
(3)实际的 node 上的 primary shard 处理请求,然后将数据同步到 replica node
(4)coordinating node 等到 primary node 和所有 replica node 都执行成功之后,就返回响应结果给客户端。
7(ES的更新和删除流程)写数据的底层原理:
1)数据
删除和更新都是写操作,但是由于 Elasticsearch 中的文档是不可变的,因此不能被删除或者改动以展示其变更;所以 ES 利用 .del 文件 标记文档是否被删除,磁盘上的每个段都有一个相应的.del 文件
(1)如果是删除操作,文档其实并没有真的被删除,而是在 .del 文件中被标记为 deleted 状态。该文档依然能匹配查询,但是会在结果中被过滤掉。
(2)如果是更新操作,就是将旧的 doc 标识为 deleted 状态,然后创建一个新的 doc。
8ES在高并发下如何保证读写一致性?
(1)对于更新操作:可以通过版本号使用乐观并发控制,以确保新版本不会被旧版本覆盖
(2)对于写操作,一致性级别支持 quorum/one/all,默认为 quorum,即只有当大多数分片可用时才允许写操作。
(3)对于读操作,可以设置 replication 为 sync(默认),这使得操作在主分片和副本分片都完成后才会返回
9 Elasticsearch的分布式原理(ES如问选举 Master节点)
Elasticsearch 会对存储的数据进行切分,将数据划分到不同的分片上,
同时每一个分片会保存多个副本,主要是为了保证分布式环境的高可用。
在 Elasticsearch 中,节点是对等的,节点间会选取集群的 Master,
由 Master 会负责集群状态信息的改变,并同步给其他节点。
10E1asticSearch是如问避免脑裂现象:
(1)当集群中 master 候选节点数量不小于3个时(node.master: true
),
可以通过设置最少投票通过数量(discovery.zen.minimum_master_nodes
),
设置超过所有候选节点一半以上来解决脑裂问题,即设置为 (N/2)+1
;
(2)当集群 master 候选节点只有两个时,这种情况是不合理的,
最好把另外一个node.master
改成false。
如果我们不改节点设置,还是套上面的(N/2)+1
公式,此时discovery.zen.minimum_master_nodes
应该设置为2。
这就出现一个问题,两个master备选节点,只要有一个挂,就选不出master了
11ES的深度分页与滚动搜索scroll
1)深度分页:
深度分页其实就是搜索的深浅度,(比如第1页,第2页,第10页,第20页,是比较浅的;第10000页,第20000页就是很深了。)
搜索得太深,就会造成性能问题,会耗费内存和占用cpu。
而且es为了性能,他不支持超过一万条数据以上的分页查询。
(2)滚动搜索:
一次性查询1万+数据,往往会造成性能影响,因为数据量太多了。
这个时候可以使用滚动搜索,也就是 scroll。
滚动搜索可以先查询出一些数据,然后再紧接着依次往下查询。
在第一次查询的时候会有一个滚动id,相当于一个锚标记 ,随后再次滚动搜索会需要上一次搜索滚动id
每次搜索都是基于一个历史的数据快照,查询数据的期间,如果有数据变更,那么和搜索是没有关系的。