ES等待任务——是master节点上的task任务

在一些 <code>罕见</code> 的集群里，元数据变动的次数比主节点能处理的还快。这会导致等待中的操作会累积成队列。

通常，响应都是像这样的：

这意味着没有等待中的任务。如果你有一个罕见的集群在主节点出现瓶颈了，等待中的任务列表可能会像这样：

可以看到任务都被指派了优先级（ 比如说 <code>URGENT</code> 要比 <code>HIGH</code> 更早的处理 ），任务插入的次序、操作进入队列多久，以及打算处理什么。在上面的列表中，有一个 <code>创建索引(create-index)</code> 和两个 <code>启动分片(shard-started)</code> 的操作在等待。

什么时候应该担心等待中的任务？

就像曾经提到过的，主节点很少会成为集群的瓶颈。唯一可能成为瓶颈的是集群状态非常大 而且更新频繁。

例如，如果你允许客户按照他们的意愿创建任意的动态字段，而且每个客户每天都有一个独立索引，那么你的集群状态会变得非常大。集群状态包括 ( 但不限于 ) 所有索引及其类型，以及每个索引的全部字段。

所以如果你有 100000 客户，然后每个客户平均有 1000 个字段，而且数据有 90 天的保留期—这就有九十亿个字段需要保存在集群状态中。不管它何时发生变更，所有的节点都需要被通知。

主节点必须处理这些变动，这需要不小的 CPU 开销，加上推送更新的集群状态到所有节点的网络开销。

这就是那些可以看到集群状态操作队列上涨的集群。没有简单的办法可以解决这个问题，不过你有三个选择：

使用一个更强大的主节点。不幸的是，这种垂直扩展只是延迟这种必然结果出现而已。

通过某些方式限定文档的动态性质来限制集群状态的大小。

到达某个阈值后组建另外一个集群。

本文转自张昺华-sky博客园博客，原文链接：http://www.cnblogs.com/bonelee/p/7285792.html，如需转载请自行联系原作者