ElasticSearch集群故障转移的最佳实践

Question

【以下的问题经过翻译处理】 一位客户目前正在使用AWS ElasticSearch作为其电子商务网站的主要搜索功能。目前，他们的查询经常运行较长的时间，这最终会对ES实例本身施加压力，迫使它们崩溃和重新启动。

这会导致他们的网站功能停止，直到AWS ElasticSearch服务重新启动节点。他们目前正在努力缩短查询时间，并已与高级支持联系。

理想情况下，我只是想建议他们在他们能够减少暴力查询请求之前可以实施的任何替代方案或故障转移解决方案。我想知道[跨集群](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/cross-cluster-search.html#cross-cluster-search-set-up-connection)功能是否也可以用作备份选项？或者另外实施Route 53健康检查解决方案。

Answer

【以下的回答经过翻译处理】 听起来客户已经在解决问题的根本原因（长查询），因此我建议进行以下改进/添加：

1. 查询缓存。将Redis放置在Elasticache前，以缓存查询结果。这可以简单地将完整的JSON查询对象进行base64编码，以用作键，结果作为值。 Redis可以根据查询有效性适当地使缓存的对象过期（即使TTL只有30秒，对于高流量的电子商务网站也可以大有裨益）。
2. 垂直扩展ES节点。ES需要内存，而大查询需要CPU。不确定他们的集群是什么样子，但听起来，较少的、更大的节点可能会有所帮助。
3. 建立一个热备份。可以使用Route53将其切换到热备份。但这显然是一种昂贵的选择。

ElasticSearch集群故障转移的最佳实践

相关内容