hyperf 3.1 的 elasticsearch 协程客户端需自行构建协程安全的 bulk 请求，优化核心是“够大但不超载”的批量与“少刷新、少合并、少同步”的服务端调优。
Hyperf 3.1 的 Elasticsearch 协程客户端本身不原生支持 Bulk 批量写入（如官方 elasticsearch-php 那样的 _bulk 封装），需自行构建符合协议的协程安全批量请求。性能瓶颈往往不在协程调度，而在 Bulk 请求组织、ES 服务端配置和索引结构设计。优化核心是：**让每批请求“够大但不超载”，让 ES “少刷新、少合并、少同步”**。
批量请求构造与并发控制
协程环境下，并发数不是越多越好，需匹配 ES 节点 bulk 线程池容量和网络吞吐：
- 单次
_bulk请求体控制在 5–12 MB（非固定条数），按文档平均大小反推数量，例如平均 2KB/文档 → 每批约 2500–6000 条；超过 15MB 易触发超时或 OOM - 并发协程数建议设为 2–4 个（非线程数），避免大量协程同时争抢连接和响应解析资源；可配合
Semaphore实现背压，例如限制最多 3 个并发 bulk 请求在途 - 禁用客户端自动重试（如
guzzle的 retry middleware），由业务层统一处理失败项——协程中重试需保证幂等，推荐记录失败 ID + 异步重投 - 使用
Co\Http\Client并开启reuse和keep_alive，复用 TCP 连接，减少 handshake 开销
服务端索引级参数调优
写入前对目标索引执行一次设置，导入完成后恢复，能显著提升吞吐：
- 临时关闭自动刷新：
"refresh_interval": "-1"—— 避免每秒生成 segment 导致频繁 merge - 副本数设为 0：
"number_of_replicas": 0—— 写入阶段跳过跨节点同步，完成后再设回1 - 增大 translog 刷盘阈值：
"translog.flush_threshold_size": "512mb"—— 减少磁盘 I/O 次数 - 启用异步 translog：
"translog.durability": "async"—— 接受极小概率宕机丢失最近秒级数据，换写入速度
映射与字段设计精简
不必要的字段解析和存储会拖慢整个 bulk 处理链路：
- 所有仅用于过滤/聚合、不参与全文检索的字段（如
user_id、status、timestamp）全部声明为"type": "keyword"，禁用text分词 - 若无需
_source（如只做指标统计、不支持更新或 reindex），显式关闭："_source": { "enabled": false } - 禁用
doc_values（对不用于排序/聚合的字段）："doc_values": false，节省磁盘和内存 - 避免动态映射，提前定义 mapping，防止 bulk 中混入新字段触发 mapping update 阻塞
错误处理与监控闭环
Bulk 响应需逐项解析，不能只看整体 HTTP 状态码：
- 检查响应中的
"errors": true及每个子操作的"status"字段（如429、400、version_conflict） - 对
429 EsRejectedExecutionException类错误，立即降级并发数或暂停 100ms 后重试（指数退避），而非盲目重发 - 接入
metrics统计：每秒成功/失败文档数、bulk 平均耗时、rejected 计数 —— 这些比日志更能定位瓶颈 - 定期检查 ES
nodes.stats中thread_pool.bulk.rejected和indices.search.query_time_in_millis，确认是否协调节点或数据节点成为瓶颈
