我们有一个弹性搜索集群，可以根据rabbitmq队列中的渗透消息计数动态调整大小。
我们的索引中有一个分片和~18K查询，我们在索引设置中使用auto_expand_replicas：“0-all”，当节点可用时，将单个分片复制到所有节点。
但是在重负载和群集重新调整大小期间，某些请求会产生意外的空匹配。
我们每天发送约1M的渗滤请求，我们失去了~1K的内容。我们为代码添加了一个集群状态控件，如果在percolate请求之前和之后集群状态不是绿色，我们正在等待绿色状态并重新发送percolate请求，我们能够将丢失的内容数量从1K减少到~100办法。我们不会在具有固定节点大小的群集中存在此问题。
不幸的是，在我们的场景中任何损失都是不可接受的，我们不想放弃自动缩放，我们需要找到解决此问题的方法。
要重复问题，您可以使用以下bash脚本：
https://gist.github.com/ekesken/de41598a1e7e54c6f33c
此脚本将在您当前的目录下载并安装elasticsearch 1.5.2，在您的本地创建一个包含10个节点的集群，并创建索引和渗透查询，并开始测试。
通常我们希望单个渗透请求的输出如下：
curl -XGET 'localhost:9200/my-index/my-type/_percolate' -d '{
"doc" : {
"message" : "A new bonsai tree in the office"
}
}'
{"took":95,"_shards":{"total":1,"successful":1,"failed":0},"total":1,"matches":[{"_index":"my-index","_id":"tree"}]}
运行脚本后，如果您看到所有节点中的所有分片都在http://localhost:9200/_cat/shards响应处启动且测试脚本仍在运行，则表示您无法重现问题，请尝试增加默认情况下为10的节点数：
./repeat_percolation_loss.sh 15 test-only
当您重现问题时，脚本将退出以下输出：
{"took":209,"_shards":{"total":1,"successful":1,"failed":0},"total":0,"matches":[]}
Problem repeated! Congratulations.
您可以使用以下命令关闭所有服务器并清除通过脚本创建的所有目录和文件：
./repeat_percolation_loss.sh 15 clean
使用您尝试过的最新节点数更改上面的节点数。