我们的 ES 相当慢，我们还没有优化它(和查询)，但是根据 this link ，来自 Elastic 的请求拒绝是一种反馈形式，要求放慢速度并调整批量大小。
我们构建了一种背压形式，其中阻塞批量的大小(同时发送的单个请求的列表，我们还没有使用 MSearch)取决于前一个批量中拒绝了多少请求。在开始新的批量之前，我们等待当前批量完成。显然，所有被拒绝的请求都被重新注入(inject)到请求队列中(以构造查询所需的数据的形式)。例如，如果我们的 Elastic 可以同时处理 500 个请求，而我们发送 600 个请求，其中一些将被拒绝，新的大小将减少到 480 个(20% 折扣)。
我们发现 ES 为先前拒绝的请求返回不同的结果 .例如，它可能会返回类似于预期结果的结果，但偏移量为 2。我们还缺少地址应该有 1 个结果的结果，但由于这个错误而没有结果。
如果批量大小小于 ES 可以处理的阈值，那么一切都会按预期进行，我们会得到预期的结果。
看起来这不是图书馆的(elastic4s)问题。
弹性配置:
2 个节点，每个节点有 5 个分片
每个节点:
2 个 CPU，32 GB 内存，16 GB 堆。其他都是默认的
我在网上找不到任何信息，有人遇到过这个问题吗？解决方案是什么？
到目前为止，我们尝试了什么:
Thread.sleep正如上面的链接所暗示的那样，在批量之间。 更新:
什么the query像。
用于搜索的线程池:
"search" : {
"type" : "fixed",
"min" : 4,
"max" : 4,
"queue_size" : 1000
},
第二次更新:
我们还尝试为我们的查询设置首选项(认为这是分片的问题):
.preference(Preference.Primary)没有积极的结果(他们比以前更加随机)。使用此设置的两次连续运行会给出不同的“随机”结果，因此这是不一致的。
最佳答案
结果不一致的原因是 Elastic 回复 Success如果至少 1 个分片有结果。所以基本上，如果我们的 5 个分片中只有一个成功，那么请求将返回一个只有 20% 数据的成功结果。
如所见here和 here ，这不是错误，这是一个功能。 Elastic 更喜欢返回一些(尽管不一致的)结果，而不是不返回任何东西。
此问题的解决方案是仅使用一个分片或将超过 0 个失败的分片视为一般请求失败，使用每个 ES 响应具有的以下对象:
"_shards" : {
"total" : 5,
"successful" : 5,
"failed" : 0
},
关于elasticsearch - 弹性在压力下给出不一致的结果，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42346540/