检索分析服务 Batch Commit：对高并发小批量写入的优化

一、背景

·Part 文件数量激增，系统在短时间内生成大量细小的碎片文件；

·后台合并（Merge）压力上升，频繁的小文件合并严重消耗 I/O 和 CPU；

·写入性能抖动，前台写入受后台 Merge 任务拖累；

·存储资源浪费，过多小文件占用 inode，压缩比下降；

·系统稳定性下降，Merge 队列堆积时易产生请求排队和延迟波动。

为解决以上结构性瓶颈，我们引入了写入攒批能力，在引擎层新增写入缓冲逻辑，实现在内存中对数据进行按需积累、统一提交的策略。

写入攒批能力主要面向以下场景：

·高并发、小批量写入频繁的在线日志接入

·多分区散写场景，如设备 ID、用户 ID 为分区键

·对写入性能、Merge 成本、稳定性有更高要求的业务系统

该能力通过在内核中延迟生成 Part，控制写入节奏，主动将多个小写入合并为一个紧凑的落盘操作，有效提升系统在高并发接入下的整体写入质量和资源效率。

二、写入缓冲（攒批）机制详解

写入攒批的核心思路是在内存中暂存批量数据，满足特定条件后再统一生成 Part 落盘，从而以更少、更大、更紧凑的 Part 替代大量零散小 Part。该机制包括以下几个关键阶段：

三、1. 请求解析为 Block（延迟生成 Part）

当接收到一个 bulk 请求后，系统会对其中的文档进行解析，构造成内部的 Block 数据结构。每个 Block 相当于一个逻辑上的写入批次，但此时不会立即生成 Part 文件，即不会触发磁盘写入。此步骤的意义在于打破“请求即落盘”的链路，将写入节奏从请求驱动转为数据积累驱动，为后续缓冲与合并创造条件。

四、2. 写入 WAL（保证数据可靠性）

解析后的 Block 会首先写入到 WAL（Write-Ahead Log），这是一个顺序写入的日志文件，确保数据在内存攒批期间即使发生故障也不会丢失。WAL 写入具有以下特性：

·支持快速追加写，性能高

·后续落盘成功后即可被安全清理

·在系统异常恢复时可重放

该步骤确保攒批过程在保证性能的同时不牺牲可靠性。

五、3. 写入内存缓冲区（攒批）

Block 会写入引擎中的 MutableBuffer（可变缓冲区），这是内存中的临时数据结构，用于对多个请求的数据进行聚合缓冲。多个 bulk 请求的数据可以持续累积到这个缓冲区中，直到触发条件满足。这一步是核心的“攒批”行为，通过有序缓存数据，为后续生成更大、更连续的 Part 打下基础。

六、4. 提交触发机制（可配置）

为了控制攒批时长与写入时机，系统提供了灵活的触发策略，满足任一条件即可触发 Commit：

·数量阈值触发：缓冲区内数据达到预设的行数或字节数，

·时间阈值触发：距离本轮攒批的第一次写入时间已超过一定时长，可保证低频写入不会长时间滞留

该机制在写入吞吐与写入延迟之间实现动态平衡：高频写入以数据量触发，低频写入以时间触发，确保既能合并批次，又能保障响应性。

七、5. 批量生成 Part（统一落盘）

一旦触发条件满足，系统将当前缓冲区中的所有数据一次性转为一个或多个 紧凑型 Part 文件 并写入磁盘。这些 Part 比原始单个请求生成的小 Part 更大、更稠密、更适于后续合并和扫描。生成 Part 时的优化包括：

·对同一分区的多条数据批量处理，避免分散写入多个文件

·更好的数据局部性和列压缩比

·降低文件数量、目录层级与 inode 占用

八、6. 清理 WAL 与内存缓存（释放资源）

在 Part 落盘完成后，系统会：

·清理对应的 WAL 段，释放磁盘空间

·回收已写入的 MutableBuffer 区域

·为下一批次写入腾出空间

整个攒批流程至此完成一个闭环。整体设计图如下：

九、机制总结与优势对照

通过在引擎层引入攒批机制，不仅优化了写入链路的结构与节奏，更显著提升了系统对高并发、高频次、小体量数据写入的处理能力，是日志型、埋点型等写密集型场景的重要内核能力升级。

十、索引级配置

十一、配置示例

PUT /http_logs{ "settings": { "number_of_shards": 1, "number_of_replicas": 1, "index.tsearch.engine.batch_commit.enable": true, "index.tsearch.engine.batch_commit.refresh_buffer_size": "16MB", "index.tsearch.engine.batch_commit.refresh_interval": "30s", "index.tsearch.engine.batch_commit.refresh_rows_count": 0, "index.tsearch.engine.batch_commit.allow_back_off_native_write": true }, "mappings": { "properties": { "foo": { "type": "text" }, "myint": { "type": "long" } } } }

十二、集群级配置

十三、配置示例

PUT /_cluster/settings{ "persistent": { "cluster.tsearch.engine.batch_commit.enable": true }}

十四、使用限制

目前用于 Batch Commit 的全局内存限制为2GB。如果超过这个上限，则退化为直接写 Part 的逻辑或者返回错误，通过 allow_back_off_native_write 配置。