8.3 近实时检索：refresh、translog 与段合并

8.3 近实时检索：refresh、translog 与段合并

本节摘要：写入成功的文档要等 refresh 才能被搜索——这是第 2 章埋下的一秒之惑，本节正式揭开：内存缓冲区攒文档、refresh 把缓冲生成只读段（可搜索）、translog 保不丢、flush 落盘并清日志、后台段合并回收墓碑。四个组件合成"近实时"（NRT）：秒级可见、掉电不丢、代价可控。这是全册写路径的最后一章拼图。

为什么搜不到刚写入的文档

一、四个组件的分工

回看 4.1 的写路径图，其中三块当时一笔带过，现在放大。内存缓冲区：文档写入后先在这里排队，此刻不可搜索。事务日志 translog：写入应答前先追加一条日志，掉电后靠它重放恢复——不丢的承诺由它兑现。只读段 segment：refresh 动作把缓冲区里的文档生成一个新段，段是倒排索引的物理载体，一旦生成就不再修改；可搜索从此开始。段合并：段越攒越多，后台线程把小段并成大段，顺带把打了删除标记的文档物理清除。

从内存到磁盘的全程

两个动词别混：refresh 让文档可搜索（内存到段的身份转变），flush 让段真正同步磁盘并清空 translog（持久化的最终章）。日常调的是 refresh 间隔，flush 引擎自己管。

二、refresh 的调音台

默认一秒一拍适合交互场景，写入密集时一秒一个新段，段数暴涨、合并疲于奔命。调音台就一个旋钮：

PUT logs-2026-08-28/_settings
{
  "index.refresh_interval": "30s"
}
​

间隔放宽到三十秒，段的生成频率降三十倍，写入吞吐显著上升——代价是可搜索延迟拉长。日志场景常见"三十秒可见"，工单场景维持一秒。设为负一可以彻底关掉自动刷新，批量导入时配合手动刷新：导完一口气 refresh，导入期间的搜索可见性为零。这就是 4.3 八十万条迁移能跑出高吞吐的幕后机制之一（另一个是批量分组）。

三、translog 的持久化档位

不丢的成色也分档位。每次写入请求后 translog 何时刷盘，有策略可选：

PUT logs-2026-08-28/_settings
{
  "index.translog.durability": "async",
  "index.translog.sync_interval": "5s"
}
​

默认档位是请求级同步——每条写入都等日志落盘才应答，最稳最慢。async 档改为每五秒批量刷，吞吐再上一档，代价是极端故障可能丢最后几秒的日志——日志分析场景通常可接受，工单系统别用。调优的诚实性在此：每换一档吞吐，都在抵押一份可见延迟或丢失窗口，参数表背后是业务对数据的价值判断。

段合并与墓碑回收

段的只读设计是搜索快的根基（不可变结构可以被操作系统缓存、可以压缩、可以并发读），代价是删除与更新只能打墓碑。段合并按大小策略挑选相邻小段合成大段：新段写好后原子替换旧段，墓碑文档不进新段——4.2 那个"删了几百万条磁盘不动"的谜底在此。合并是 IO 大户，与查询抢磁盘：大合并期间延迟抬升属正常，可以调合并线程数与策略带宽，但更根本的是让冷索引少产生碎段（refresh 已放宽）。

一次写入高峰的调优过程

背景：日志集群每晚十点到十二点写入洪峰，节点 CPU 飙到九成，查询延迟翻倍，日志里段数告警频出。操作：第一步把热索引 refresh 间隔从一秒放宽到三十秒；第二步 translog 改 async 档五秒；第三步确认批量请求尺寸在十兆上下（4.3 的甜区）；第四步观察一夜。结果：CPU 回落到六成，段数稳住，查询延迟回基线；可搜索延迟从一秒变三十秒，日志平台的产品预期同步调整了说明文案。解读：三个动作都指向同一件事——少生成碎段、少刷盘次数，让 IO 花在刀刃上；代价（可见延迟、丢失窗口）被产品侧知情接受。变式：洪峰极端时再把部分索引的自动 refresh 关闭、洪峰后手动刷新；或把写入分级的思路做进管道（重要日志同步档、可丢日志 async 档）。

常见坑：把 refresh 间隔调成一秒之内的"更实时"——段碎片化雪崩，搜索反而变慢。近实时的"近"有一秒量级的天然节奏，逆着节奏拧旋钮是自伤。

关键直觉：refresh 是身份转变（可搜索），flush 是物理落盘（真持久），translog 是两者之间的保险单。分清三个动词，写路径的一切调优都可以自行推导。

考核与自测

考核知识点清单

易错点补充

• 把 refresh 理解为落盘：它只是身份转变，段还在文件系统缓存里，真持久靠 flush 与事务日志兜底。
• 关了自动刷新忘了手动刷：批量导入提速明显，但导完不手动刷新，数据一直搜不到。
• 把段数告警当噪音：碎段过多直接拖慢搜索，它是刷新节奏失衡的第一信号。
• 事务日志只顾吞吐不看保留策略：日志滚动的代数与大小有上限，超出后早期日志被清，崩溃恢复的依据变薄，档位与保留要一起定。
• 手动刷新接口当定时任务用：高频率手动刷新与缩短间隔同罪，碎段照旧雪崩，节奏交给引擎、例外才手动。