.net - Elasticsearch.NET 故障转移似乎不排除死节点

Question

我正在使用 ElasticSearch.NET 和 NEST 来处理对 .NET 网络服务的调用。 ElasticClient 是一个单例，因此它的连接池和故障转移应该在服务调用之间保持不变。

ElasticClient 使用带有两个集群节点的 SniffingConnectionPool。两个节点之一挂了，根本不响应 http 流量。

我的理解是 SniffingConnectionPool 应该检测到这一点并从它使用的节点中排除死连接 - 也就是说，所有 Elasticsearch 流量都应该发送到唯一的事件节点。

可悲的是，ElasticClient 持续尝试使用死节点，给网络服务响应增加了长时间的超时延迟。有没有人成功使用 Elasticsearch.NET 故障转移池？有没有人知道我做错了什么，或者我还可以尝试什么？

我已经尝试切换到 StaticConnectionPool，但问题仍然存在。

我试过使用连接设置，但无法真正从 http://nest.azurewebsites.net/elasticsearch-net/cluster-failover.html 的 doco 那里获得足够有用的理解。 .

这是我用来创建带有连接池的客户端的代码:

    private static IElasticClient _MakeClient(string[] injectedUris, string defaultIndex)
    {
        var settings = new ConnectionSettings(_GetIConnectionPool(injectedUris), defaultIndex);
        var connection = new ConnectionWithBackoffStrategy(
            new HttpConnection(settings));
        var client = new ElasticClient(settings, connection);
        return client;
    }

    private static IConnectionPool _GetIConnectionPool(string[] injectedUris)
    {
        var uris = injectedUris ?? ConfigurationManager.AppSettings["elasticSearchUrls"].Split(',');
        return new SniffingConnectionPool(uris.Select(uri => new Uri(uri)));
    }

我使用的是 Nest 1.0.0-beta1。

Answer 1

ConnectionSettings 具有选择加入连接嗅探的方法，例如 SniffOnConnectionFault(true) 和 SniffOnStartup(true)。

如果您选择加入这些，ElasticSearch.net 将调用 http://localhost:9200/_nodes/_all/clear?timeout=50

我相信这是为了证明节点还活着，但是在 Elasticsearch 文档中没有关于 clear 操作的信息。

python 实现似乎暗示它只是对将快速返回的东西的调用；尽管在对“所有节点”的请求中看到 clear 有点“可怕”

use small timeout for the sniffing request, should be a fast api call

https://github.com/elasticsearch/elasticsearch-py/blob/master/elasticsearch/transport.py#L175