6.4 Elasticsearch-线程模型：Netty4 transport、search & write thread_pool
6.4.1 总览：三条独立管道
Elasticsearch 7.0 之后彻底移除 transport-nio，统一使用 Netty4 作为网络层。一条 HTTP 请求或节点间 RPC 进入系统后，会先后经过
- Netty4 I/O 线程（boss→worker）
- 通用分派线程（ServerTransportInterceptor）
- 业务线程池（search / write / get / management …）
这三层彼此解耦，通过无界 MPSC 队列传递 Netty 的 ByteBuf，既保证“线程安全”又避免 I/O 线程被阻塞。下面按“收包→解码→派发到 search/write”这条最常被问到的路径展开。
6.4.2 Netty4 层：I/O 线程只干“轻活”
- bossGroup：仅做 accept，默认 size = 1，几乎不占 CPU。
- workerGroup：默认 size = min(2×CPU, 32)，负责 TLS 握手、拆包、粘包处理、HTTP 行/头解析。解析完成后封装成 Netty4HttpRequest 或 TransportRequest，丢给 ServerTransportDispatcher。
- 零拷贝：对 bulk 大报文使用 CompositeByteBuf，避免 4 MB 以上的数组拷贝；对搜索请求采用 PooledByteBufAllocator，减少 GC 压力。
- 背压：如果某个链路写入队列 > 1 MB，Netty 会将 channel 置为不可写，上游 REST 层收到“channel 不可写”信号后暂停读取，防止 OOM。
6.4.3 分派层：把“请求类型”映射到“线程池名称”
ServerTransportDispatcher 收到 request 后，根据 action name 选择线程池：
indices:data/read/search→ searchindices:data/write/indexing→ writeindices:admin/refresh→ managementcluster:monitor/nodes/stats→ management
action name 到线程池的映射表在 TransportService 启动时通过 ThreadPool.register 静态初始化，用户也可通过thread_pool.search.size: 100动态调整。
6.4.4 search thread_pool：CPU 密集，队列无界
- size：
int((#available_processors * 3) / 2) + 1，最大 128。 - queue：无界 LinkedTransferQueue，防止搜索高峰拒掉请求。
- 任务类型：DFS_QUERY_THEN_FETCH、QUERY_THEN_FETCH、scroll、can_match 等。
- 异常场景：如果单个查询命中 2 TB 索引且开启 fielddata，search 线程会 100 % CPU 并长时间占用，导致后续查询延迟飙升；此时只靠队列堆积，不会触发拒绝，但会出现“查询耗时 60 s+”的毛刺。
- 调优：对 SLA 要求高的集群，给 search 池单独绑核，配合
cpuset隔离，避免被 write 线程抢占。
6.4.5 write thread_pool：内存+磁盘混合，队列有界
- size：
#available_processors。 - queue_size：固定 200（硬编码），与 search 不同，这是为了防止 bulk 洪峰把内存打爆。
- 任务类型：index、delete、update、bulk shard 请求。
- 拒绝策略：队列满后直接抛 EsRejectedExecutionException，客户端收到 429，协调节点通过 RetryListener 自动指数退避重试（最大 3 次）。
- backlog 监控：
若 rejected 持续 > 0，说明磁盘已跟不上写入速度，需降速或扩容。GET /_cat/thread_pool/write?v&h=node_name,name,active,queue,rejected
6.4.6 跨层交互：Netty→search/write 全流程
- Client 发送 POST /index/_search
- Netty worker 线程读完 HTTP 报文，封装成 HttpRequest，投递到 ES 的 HttpServerTransport 处理队列。
- HttpServerTransport 把请求转给 RestController，解析出 indices 和 search source，生成 SearchRequest。
- TransportSearchAction 在本地节点执行 can_match 阶段，如果目标 shard 在当前节点，则把 shard request 序列化后投递到 search 线程池。
- search 线程调用 Lucene IndexSearcher，结果先写入 ReleasableBytesStreamOutput，再被 Netty4 的 ChannelHandler 异步刷回客户端。
- 若触发 refresh，则 refresh 任务由 management 线程执行，search/write 线程不参与，避免阻塞。
6.4.7 常见问题排查清单
- 搜索 RT 突增：先看 search 线程 CPU，再确认是否出现“long garbage collection”导致 Netty I/O 线程也卡住；最后检查 fielddata/global_ordinals 是否暴涨。
- 写入 429 暴涨：多数是 bulk size 过大或磁盘 util 100 %；临时调大
thread_pool.write.size并不能解决背压，正确姿势是降低客户端并发或升级磁盘。 - 节点离线后大量 reject：失联节点的 shard 会被重新分配到剩余节点，新节点瞬间涌入 recovery write，write 队列 200 很快被打满；可通过
cluster.routing.allocation.node_concurrent_recoveries: 2限制并发度。 - Netty 层 OOM：检查是否开启
http.compression: true且大报文未分块；Netty 的压缩缓冲区默认 64 KB，如果单条 bulk > 100 MB 会申请大量临时 direct memory，建议把 bulk 限制在 5 MB 以内。
6.4.8 小结
Netty4 仅负责“收发字节”，search 线程池负责“CPU 计算”，write 线程池负责“内存+磁盘写入”；三层通过队列解耦，拒绝策略只在 write 层触发。理解这一分工后，遇到 RT 抖动或 429 错误，就能快速定位是“网络→计算→存储”哪一环成为瓶颈，从而做出针对性扩容或限流决策。```
推荐阅读：
PyCharm 2018–2024使用指南
更多技术文章见公众号: 大城市小农民
