5.9 Elasticsearch-多租户资源隔离：queue_size、search indexing thread

5.9 Elasticsearch-多租户资源隔离：queue_size、search & indexing thread_pool

在 Elasticsearch 多租户（multi-tenancy）场景下，不同业务方共享同一套物理集群时，最隐蔽也最容易被忽视的风险点是线程池（thread pool）与队列（queue）的“侧漏”——一个租户的突发流量可能瞬间打满 search 或 write 线程池，导致其他租户请求被无情拒绝，整个集群出现 429（EsRejectedExecutionException）。本节从线程池模型、队列大小、拒绝策略、动态隔离手段四个维度，给出可落地的资源隔离方案。

1. 线程池模型回顾：固定大小 + 无界队列的误区

Elasticsearch 7.x 之后，search、write、index 等关键线程池默认采用fixed类型，即：

thread_pool: search: size: 50 queue_size: 1000 write: size: 50 queue_size: 10000

size：线程数，CPU 核数 × 2 是经验值，但多租户场景下必须留余量。
queue_size：请求队列长度，无界队列（-1）在极端场景下会触发 OOM；而过大队列（如 10k）虽能缓冲突发，却会把延迟毛刺传递到所有租户。

结论：queue_size 不是越大越好，而是“可预测+可拒绝”。

2. 队列打满的现场还原

通过_nodes/stats/thread_pool可实时观察：

"write":{"threads":50,"queue":10000,"active":50,"rejected":1234567}

当 rejected 持续攀升，且 CPU 利用率却不高，即可判定线程池已饱和，请求在入口层被直接拒绝。多租户场景下，无法直观区分是哪个租户触发的拒绝，需要借助自定义拦截器或队列包装器埋点。

3. 队列拆分：物理隔离 vs 逻辑隔离

方案	实现方式	优点	缺点
物理隔离	为每个租户单独建集群	彻底	成本高、运维复杂
逻辑隔离	单集群内通过路由规则+独立 queue 实现	成本低	需要改内核

Elasticsearch 官方并不支持“单集群多队列”，但可以通过以下两种手段逼近目标：

Searchable Snapshot + Frozen Tier
把冷数据卸载到对象存储，查询走search_throttled线程池，天然低速，不影响热数据租户。
自定义ContextPreservingExecutor
在 Transport 层插入RunnableWrapper，根据请求头X-Tenant-Id路由到不同的ArrayBlockingQueue；拒绝时返回 429 并带上租户标签。
该方案已在 Elastic Cloud Enterprise 内部使用，开源侧需基于server/src/main/java/org/elasticsearch/common/util/concurrent/ThreadContext.java做二次开发，属于“改内核”级别，升级前需 rebase。

4. 动态限流：令牌桶 + 队列联动

如果不改内核，可在网关层（Nginx/Envoy）或 ** coordinating 节点插件** 做令牌桶限流：

令牌桶 Key：(tenant, thread_pool_type)
桶大小：与 Elasticsearch 侧 queue_size 成比例，例如queue_size * 0.8
拒绝策略：直接返回 429，不把请求放进 ES 队列，避免无意义堆积。

示例（Lua + Nginx）：

locallimit_req=require"resty.limit.req"locallim,err=limit_req.new("tenant_write_limit",8000,8000)localdelay,err=lim:incoming(tenant_id,true)ifdelaythenreturnngx.exit(429)end

5. 参数调优 checklist

参数	多租户建议值	备注
`thread_pool.search.size`	`min(50, cpu*2)`	留 20% 余量给系统线程
`thread_pool.search.queue_size`	`500~1000`	拒绝比堆积更可控
`thread_pool.write.size`	`min(50, cpu*2)`	写池与 search 分开
`thread_pool.write.queue_size`	`2000~5000`	写流量通常突发更高
`cluster.routing.allocation.awareness.force.*.values`	按租户标签强制分片分布	降低热点节点风险

6. 一键诊断脚本

把以下脚本放到 Kibana 的 Dev Tools，定时执行即可监控租户级拒绝量：

GET_nodes/stats/thread_pool?filter_path=nodes.*.thread_pool.write.rejected,nodes.*.thread_pool.search.rejected

结合 Metricbeat 采集，并在 Grafana 配置rate(rejected[5m]) > 0告警，告警维度增加 tenant hash，即可快速定位“肇事”租户。

7. 小结

queue_size 是最后一道闸，不是蓄水池；合理设上限 + 快速失败是多租户隔离的第一性原理。
官方线程池模型是“单队列多线程”，要想租户级隔离，要么在入口层提前限流，要么改内核做队列拆分。
拒绝率（rejected）是最直接的健康指标，没有 429 的集群不代表没超载，可能只是队列太长；把延迟和拒绝放在一起看，才能画出真正的“租户 SLA 边界”。```
推荐阅读：
PyCharm 2018–2024使用指南

更多技术文章见公众号: 大城市小农民