写入路径：为什么是"近实时"

写入路径上的每一个反直觉行为，根都扎在 01 章那条公理里：底层是一堆不可变的 Lucene segment。一段已经写出的 segment 永不被原地改写——这一条同时逼出了三个看似无关的现象：写完为什么搜不到（refresh）、崩溃为什么不丢数据（translog / flush）、删除为什么不立刻回收磁盘（merge）。本章四节顺着一条文档的旅程走：先看它被切成什么（倒排索引），再看它何时可见（refresh）、何时落盘（flush），最后看它被删时发生了什么（merge）。

2.1倒排索引：搜索为什么快

写入时把文本切成规范化的 term，每个 term 指向一个有序的文档 id 列表（postings）；搜索因此变成几个有序列表的归并，而不是全表扫描。

运行方式：analyzer 管线 → term → postings

一个 text 字段被写入时，它的内容先过一条 analyzer 管线，分三段：

• char filter：在分词之前对原始字符做替换，例如剥掉 HTML 标签、把 & 换成 and。
• tokenizer：按规则把字符流切成 token，最常见的 standard tokenizer 按词边界切，并丢掉大部分标点。
• token filters：对切出的 token 逐个规范化——小写化（lowercase）、去停用词（stop，如 the / a）、词干还原（stemmer，把 foxes 还原成 fox）。

管线的产物是一串规范化后的 term。索引之所以叫"倒排"，是因为它不存"文档 → 它含哪些词"，而是反过来存 每个 term → 一个 postings list：一个按文档 id 升序排列的列表，每个条目还附带词频（term frequency）和位置（position，供短语查询用）。所有 term 本身又被收进一个有序的 term 词典。

搜索时为什么快

查询 quick AND fox 时，查询词先过同一条 analyzer得到 term quick 和 fox，在有序 term 词典里二分定位到各自的 postings，然后两个已排序的 doc id 列表做归并求交集——两个指针各自只向前走，命中相同 id 的就是结果。整个过程不碰任何一篇原文，代价只与命中文档数相关，与索引里文档总数基本无关，这就是"亚线性"。行存数据库走的是相反路线：扫每一行、对字段做子串匹配，代价随行数线性增长。倒排索引把这份代价从"每次查询"挪到了"一次写入"。

带来的代价

预付不是免费的。写入时要跑完整条 analyzer 管线并构建索引结构，因此写比"直接落一行"重。更隐蔽的代价是一致性约束：查询分词器必须和索引分词器一致，否则查询词规范化出的 term 和存储的 term 对不上，结果就是"字段里明明有这个词却搜不到"。

2.2不可变的 segment 与 refresh：近实时从哪来

新文档先进内存 buffer；一次 refresh 把 buffer 写成一个新 segment 并重开 reader——"近实时"就是这个 reader 重开的节奏，默认约 1 秒，不是实时。

运行方式：buffer → refresh → 新 segment → reader 重开

一条文档被索引后，先落进一个 in-memory buffer（同时也写了 translog，见 2.3）。此时它还搜不到——搜索看的是已打开的 segment，而 buffer 不是 segment。直到一次 refresh 发生：buffer 里积攒的文档被写成一个新的磁盘 segment，并打开一个新的 reader，把这个新 segment 纳入可搜索集合。从此刻起，这批文档才能被搜到。

refresh 默认每 1 秒触发一次，但有个常被忽略的条件：自 ES 7.0 起，只有最近 30 秒内被搜索过的 index 才会自动周期 refresh；完全没有查询打进来的 index 不会空跑 refresh，避免给纯写入负载白白制造小 segment。这就是 near-real-time（近实时） 的全部含义——不是写完即可见的实时，而是"reader 按节奏重开"带来的、上限约 1 秒的可见延迟。

带来的代价

refresh 越频繁，单位时间内生成的小 segment 越多，而段越多越碎，后续 merge（2.4）要重写合并的负担就越重——代价不在 refresh 当下，而滞后到合并阶段。?refresh=true 能强制一次立即可见的 refresh，但每调一次就多新建一个小 segment；在高频写入路径上滥用，等于主动制造段爆炸、把成本压给 merge。

2.3持久化 ≠ 可见性：translog 与 flush

可见性（refresh）和持久化（durability）是两条独立的轴：每个写操作先追加 translog 保证崩溃不丢，flush 才把内存 segment fsync 落盘并清空 translog。

运行方式：两条轴各走各的

把图 2.2 的两条轴拆开看：

• 可见性轴（refresh）：buffer → 新 segment → reader 重开 → 可搜索。管"什么时候能搜到"。
• 持久化轴（durability）：每个 op → 追加 translog → flush 时 fsync segment 落盘并清空 translog。管"崩溃了丢不丢"。

两条轴由不同的触发条件驱动、互不等待。refresh 默认 1 秒一次；flush 则在 translog 达到阈值（默认 512MB）或周期到点时触发，把内存里的 segment fsync 到磁盘、然后清空已落盘部分对应的 translog。一次 flush 之后，那段 translog 的使命完成、可以丢弃。

PUT /logs/_settings
{
  "index.translog.durability": "request",
  "index.translog.flush_threshold_size": "512mb"
}
// durability=request（默认）：每个写请求返回前，translog 先 fsync
//   → 单条写确认即不丢，代价是每请求一次磁盘同步
// durability=async：translog 每 5s 才 fsync 一次
//   → 写吞吐更高，但崩溃可能丢掉最近 5s 的已确认写

带来的代价

translog 不是没有成本的。translog 攒得越大，崩溃后重启要重放的操作越多，恢复时间越长；这也是 flush 阈值不能设得过大的原因。反过来，flush 太频繁则把"攒批落盘"的优化吃掉了，每次 fsync 都是一次昂贵的磁盘同步，增加 I/O 压力。durability: request（默认）保证每条已确认的写都不丢，但代价是每个写请求都要等一次 translog fsync；改成 async 能换吞吐，但崩溃时会丢掉最近一个 fsync 间隔内的已确认写——这是一道明确的"持久化保证 vs 写吞吐"权衡。

2.4删除不真删、更新=删+插：merge

段不可变，所以删除只是在位图里打个标记（soft delete），被删文档的空间要等后台 merge 把若干段重写成新段时才真正回收；更新 = 旧文档标删 + 新文档进新段。

运行方式：标删 → 后台 merge 才真正回收

被 soft-delete 的文档一直躺在原 segment 里，直到后台的 merge 发生：merge 选若干个小 segment，把其中仍存活的文档重写进一个新的、更大的 segment，然后丢弃旧 segment。被标删的文档在重写时不会被带进新段——这一刻，它们的空间才真正释放。merge 因此身兼两职：把碎段合并成大段（减少段数、加快搜索），以及顺带清理掉积压的已删文档。

更新（包括用相同 _id 重新索引）在底层就是"删 + 插"：把旧版本文档 soft-delete，把新版本写进当前 buffer、等下次 refresh 进新 segment。所以高频更新同一批文档，会持续制造"标删的旧版本"，把回收压力堆给 merge。

带来的代价

merge 把"读到稳定快照、写走顺序追加"的好处，换成了一项后台开销：被删 / 被更新文档在 merge 前持续占用磁盘（空间回收滞后），而 merge 本身是重 I/O 的整段重写，与正常读写争抢磁盘带宽。ES 用一套策略限制并发 merge 数与速率来平摊这份成本，但它无法被消除——只能被调度。这也是为什么"段不可变"虽然让读路径干净，却必然附带一个永远在后台运转的 merge。

为什么是"不可变段 + 后台合并"，而不是原地更新

把前三节的代价摊开看，会自然冒出一个问题：既然不可变带来了近实时延迟、删除滞后、merge 重 I/O 这么多麻烦，为什么不干脆让 segment 可原地更新？下表对比三条路线，解释为什么 ES（及其底层 Lucene）选了不可变这条。

2.5把三件事拼回一条链路

refresh / flush / merge 是三件不同的事，触发条件、负责的轴、产出各不相同。混淆它们是写入困惑的总根源，所以单独列一张表钉死区别：

把一条文档的完整旅程串起来：被索引 → 同时进 buffer 和 translog（已持久化、未可见）→ 下次 refresh 写成新 segment、可被搜到（已可见、仍在文件缓存）→ 下次 flush 把 segment fsync 落盘、清 translog（已落盘）→ 若干次写入后，它所在的小段被 merge 进大段；若期间它被删 / 被更新，旧版本在这次 merge 里被真正丢弃。四段路、三件事，全是"segment 不可变"这一条公理的连续推论。