基本思路
业务开发面试Elasticsearch的时候基本问的是基础知识以及倒排索引。
Elasticsearch最基本的可用性保障就是分片,而且是主从分片,所以遇到Elasticsearch如何做到高可用这个问题的时候,首先要提到这一点。
接着要补充Translog的作用
接着尝试把话题引导到准备的高可用方案中
Elasticsearch高可用方案
限流保护节点
限流是一个治标的策略,但是它能够保证Elasticsearch不会因为突发大流量而直接崩溃。
可以通过Elasticsearch的插件机制来实现自定义的限流策略,注意Elasticsearch集群本身提供了限流的功能,也可以通过控制线程池大小和队列大小来间接实现限流的功能。
如果打算利用插件来实现限流功能的时候,就一定能够要有特殊之处。比如可以考虑结合Elasticsearch的内存使用率和CPU使用率设计限流策略。
这里面试官也会考察怎么确定限流的阈值,超过阈值多少才会触发限流,限流之后怎么恢复等问题。
当然,如果你会研发限流插件,你也可以用插件来实现熔断、降级。熔断比较好处理,就是直接拒绝新的查询请求,但是降级这个就要考虑怎么降级了。如果你能够知道不同查询的业务价值,那么你就可以考虑触发降级的时候优先保障核心业务的请求,但是把非核心的请求拒绝了。总而言之,你之前在微服务学习到的熔断、限流、降级的思想,在这里一样适用。
如果你从来没有研发过 Elasticsearch 插件,那么也可以考虑其他两种策略,一种是在 Elasticsearch 之前加一个网关,查询经过网关的时候会被限流、熔断或者降级。当然,引代理也可以。
目前市面上这方面的产品不多,比较成熟的是极限网关,可以用一种自己了解但是没有实践过的话术说。
另一种是在客户端这边限流各个业务方需要限制住自己的查询频率,防止把整个Elasticsearch打崩。相比之下,这种方式是最好落地的。
不过 Elasticsearch 设计之初就是为了支持高并发大数据的,所以最佳方式还是要考虑扩容。
利用消息队列
在一些对数据实时性要求不高的场景下,完全可以考虑在业务方和Elasticsearch中加入一个消息队列。可以抓住关键字 削峰和限流来回答。
在这个架构的基础上,还可以考虑引入降级,也就是在 Elasticsearch 真的有性能问题的时候,关闭一部分消费者。
如果在大促或秒杀这种活动中,可以把整个数据同步都停掉,让Elasticsearch只支持查询操作。如果业务是电商类的,可以考虑这个策略。
保护协调节点
在Elasticsearch里,比较容易出问题的还有协调节点。协调节点类似分库分表代理,负责分发请求,处理结果集。如果一个查询需要消耗非常多的资源,就有可能把协调节点搞崩溃。如果有一个查询命中了10个分片,并且每个分片都返回了几万条数据,协调节点本身的资源使用量一下就会上去,甚至出现CPU100%或OOM问题。
因此要保证Elasticsearch高可用就要考虑防止突发大请求打崩协调节点问题。
整个面试思路是层层递进的。首先你可以指出如果公司内部资源比较多,那么可以考虑部署纯粹的协调节点。
接着可以补充怎么用好这些协调节点,关键词就是隔离。
这种做法的好处是和隔离结合在了一起,因此你可以尝试把话题引导到隔离策略上。在一些技术实力很强的大厂,它们还会对 Elasticsearch 进行二次开发。可以修改协调节点的逻辑,让协调节点在资源快不足的时候,直接拒绝这种大请求。如果你在大厂,可以了解一下自己公司有没有在这方面做优化。
你可以在这个基础上进一步总结,就是只使用单一角色的节点以提高可用性。
双集群
双集群算是一个很高级、投入也很大的高可用方案。
最简单的方案就是直接使用付费的CCR跨集群复制,面试的时候简单提一下就可以。
在不使用这种付费功能的情况下,就只能考虑自己做了。这里有一个比较简单的方案,假如说有 A 和 B 两个集群,那么基本思路就是这样的:
-
使用消息队列来保持双写
-
在查询的时候,优先使用 A 集群,当确认 A 集群出了问题的时候,切换到 B 集群。
抓住关键词消息队列双写回答。
而怎么判断集群 A 是否已经出问题,可以参考微服务中判断节点是否健康的部分,思路都是类似的。
具体怎么切换,有两种思路。一种是你使用的客户端切换,一种是利用 DNS 机制切换。也就是说,正常情况下,你使用的 Elasticsearch 的连接信息,DNS 解析的时候返回的是集群 A 的 IP。但是当触发了容灾切换的时候,DNS 解析得到的是集群 B 的地址。
你在回答的时候可以选择其中任意一种,这里我以客户端为例来说一说。