保护协调节点
在Elasticsearch里，比较容易出问题的还有协调节点。协调节点类似分库分表代理，负责分发请求，处理结果集。如果一个查询需要消耗非常多的资源，就有可能把协调节点搞崩溃。如果有一个查询命中了10个分片，并且每个分片都返回了几万条数据，协调节点本身的资源使用量一下就会上去，甚至出现CPU100%或OOM问题。
因此要保证Elasticsearch高可用就要考虑防止突发大请求打崩协调节点问题。
整个面试思路是层层递进的。首先你可以指出如果公司内部资源比较多，那么可以考虑部署纯粹的协调节点。
要想提高 Elasticsearch 的可用性，就要想办法防止协调节点在遇到大请求的时候崩溃。最简单的做法就是使用纯粹的协调节点。比如说专门部署一批节点，只扮演协调节点的角色。
接着可以补充怎么用好这些协调节点，关键词就是隔离。
如果整个Elasticsearch除了这种纯粹的协调节点，还有一些兼任多个角色的协调节点，那么就可以考虑使用隔离策略。也就是说，如果客户端能够判定自己是大请求，就将请求发送到纯粹的协调节点上，否则发送到其他兼任的协调节点上。
这种做法的好处就是，大请求即使把协调节点打崩了，也只会影响到其他大请求。但是占据绝大多数的普通请求，并不会受到影响。
这种做法的好处是和隔离结合在了一起，因此你可以尝试把话题引导到隔离策略上。在一些技术实力很强的大厂，它们还会对 Elasticsearch 进行二次开发。可以修改协调节点的逻辑，让协调节点在资源快不足的时候，直接拒绝这种大请求。如果你在大厂，可以了解一下自己公司有没有在这方面做优化。
你可以在这个基础上进一步总结，就是只使用单一角色的节点以提高可用性。
在资源足够的情况下，我是建议所有的节点都只扮演单一角色。这样做不仅仅能够带来可用性的提升，也能带来性能的提升。
