这里面试官也会考察怎么确定限流的阈值，超过阈值多少才会触发限流，限流之后怎么恢复等问题。
当然，如果你会研发限流插件，你也可以用插件来实现熔断、降级。熔断比较好处理，就是直接拒绝新的查询请求，但是降级这个就要考虑怎么降级了。如果你能够知道不同查询的业务价值，那么你就可以考虑触发降级的时候优先保障核心业务的请求，但是把非核心的请求拒绝了。总而言之，你之前在微服务学习到的熔断、限流、降级的思想，在这里一样适用。
如果你从来没有研发过 Elasticsearch 插件，那么也可以考虑其他两种策略，一种是在 Elasticsearch 之前加一个网关，查询经过网关的时候会被限流、熔断或者降级。当然，引代理也可以。
目前市面上这方面的产品不多，比较成熟的是极限网关，可以用一种自己了解但是没有实践过的话术说。
我还了解过Elasticsearch网关或代理，希望能够借助这些产品来做Elasticsearch的治理。比如借助网关做熔断、限流、降级这些，但是市面上相关的产品较少，也担心引入网关后的性能损耗，所以最后并没有实施这个方案。
另一种是在客户端这边限流各个业务方需要限制住自己的查询频率，防止把整个Elasticsearch打崩。相比之下，这种方式是最好落地的。
为了保护Elasticsearch，在客户端这边做了限流。比如某个业务的查询都比较慢，对Elasticsearch的压力很大，那么限流的阈值就比较小。
不过 Elasticsearch 设计之初就是为了支持高并发大数据的，所以最佳方式还是要考虑扩容。
不管如何，限流都只能算是治标。如果经常触发限流，或者发现 Elasticsearch 有性能问题，那么还是要及时扩容的。
