Elasticsearch 的“近实时”，兑现条件藏在 refresh、translog 和 merge 的三份条款里

Elasticsearch 的叙事通常由两个词支撑：近实时搜索和持久化。数据写入后一秒内可搜，durability=request 时确认即落盘。这两个承诺都是真的，但它们兑现的方式，和直觉之间隔着一组容易被跳过的条件。“一秒内可搜”不是写入触发的倒计时，而是一个惰性的周期检查；“持久”的丢失窗口大小，取决于你把 durability 设成了什么；而支撑这两者的段合并，本身是一笔需要被持续支付的写放大账单。把官方文档里散落在 refresh、translog 和 merge 三处的条款拼在一起，会看到一个一致的结论：Elasticsearch 的承诺不是无条件成立的属性，而是一组必须在每一次写入、每一次崩溃恢复、每一次后台合并中被重新兑现的条件。

1 秒可搜：一个惰性周期，不是一条对写入的保证

index.refresh_interval 的默认值在 Elastic Stack 中是 1 秒，在 Elastic Cloud Serverless 中是 5 秒，且 Serverless 环境有一个 5 秒的硬性下限[reference:0]。这个数字容易被读成“写入后最多 1 秒就能搜到”，但官方文档对 refresh 的定义指向了另一层含义：refresh 是把内存中的索引缓冲区写入一个新的 Lucene segment 并打开它，使自上次 refresh 以来的操作对搜索可见[reference:1]。它是一个周期性的批量动作，不是一个跟随每一条写入的即时触发器。

更关键的条件写在 Near real-time search 文档里：Elasticsearch 默认每秒 refresh 一次，但只对在过去 30 秒内收到过至少一次搜索请求的索引执行[reference:2]。一个没有搜索流量的索引，refresh 实际上处于惰性状态。这意味着“1 秒内可搜”这个承诺的兑现，绑定在一个外部条件上——索引正在被查询。如果写入之后没有搜索请求，那么“可搜”这件事的时钟根本没有开始走。

refresh=wait_for 常被当作精确控制可见性的手段，但它的语义同样值得精确阅读：它不强制立即 refresh，而是等待一次 refresh 发生[reference:3]。在默认 interval 下，等待上限大约是一个周期；如果把 interval 设为 -1（禁用自动 refresh），wait_for 会无限等待，直到某个外部动作触发 refresh[reference:4]。反过来，把 interval 缩短到 200 ms 确实能让 wait_for 更快返回，但代价是产生更多低效的小 segment，这些碎片最终需要在 merge 阶段被重新消化[reference:5]。可见性的“加速”不是免费的，它把成本转移到了后台合并的队列里。

durability=request 的“持久”，是一个关于丢失窗口的选择题

translog 的默认设置 index.translog.durability = request 给出的承诺很明确：只有在 translog 已经在主分片和每一个已分配副本上完成 fsync 和 commit 之后，Elasticsearch 才会向客户端报告成功[reference:6]。在这个设置下，硬件故障、操作系统崩溃或 JVM 崩溃都不会导致已经确认的写入丢失，因为确认的前提就是落盘。

但“持久”这个词在 Elasticsearch 里不是一个全局属性，而是一个由配置参数划定的丢失窗口。如果 durability 被改为 async，fsync 和 commit 就变成后台按 index.translog.sync_interval 执行，默认 5 秒，且不允许小于 100 ms[reference:7]。官方文档对这个选择的后果写得很直白：崩溃时，上一次 translog commit 之后的所有已确认写入都会被丢弃[reference:8]。

async 的存在本身就在声明：Elasticsearch 的持久化不是一个“有或没有”的开关，而是一条可以被拉宽的窗口。选择 async 的理由通常是降低每次写入的 fsync 延迟和 IOPS 消耗[reference:9]，但代价被精确地量化了——5 秒的窗口乘以当前的写入速率，就是崩溃时可能丢掉的数据量。这个量需要由使用方自己确认是否可以接受，而不是由 Elasticsearch 替你做决定。

还有一个容易被忽略的上界：translog 的大小永远不会超过磁盘容量的 1%[reference:10]。这是一条与 durability 设置无关的硬约束，它决定了 translog 在恢复时需要被重放的体量上限。持久性的兑现条件在这里又多了一层：即使 durability 保证了落盘，恢复的速度仍然被这个 1% 的容量天花板所约束。

merge：承诺的隐性账单，按写放大计价

refresh 产生的小 segment，最终要通过 merge 被合并成更大的 segment。官方文档对 segment 的描述是“不可变的”，小 segment 被周期性合并以控制索引大小并清除已删除的文档[reference:11]。这个过程的代价不在写入延迟里直接体现，但它是一笔必须被持续支付的写放大账单。

写放大的量级在公开分析中被描述为：根据写入模式和数据量，Elasticsearch 的 segment 合并通常会产生几倍到十几倍的写放大，这里的定义是磁盘写入总量除以最终索引大小[reference:12]。换句话说，前台每写入 1 字节的逻辑数据，后台可能为了合并 segment 而写入数倍到十几倍的物理数据。这个比值决定了磁盘 I/O 带宽中必须为 merge 预留多少余量；如果写入负载是持续的、merge 又得不到足够的 I/O，积压就会发生。

merge 的调度方式进一步说明了它的“条件性”。merge 运行在专用的 merge 线程池上，每个分片的合并线程数默认是处理器数量的一半，最小为 1，对 SSD 而言这个默认值被描述为“工作良好”；如果底层是机械盘，官方建议将其降为 1[reference:13]。更重要的是自动限流的行为：merge 过程使用 auto-throttling 在合并和搜索等其他活动之间平衡硬件资源[reference:14]；但当合并积压到一定程度、且在完全解除磁盘 I/O 限流之后仍然落后时，该分片的索引操作本身会被限流，直到合并追上[reference:15]。

这就构成了一个与 ClickHouse 的 parts_to_delay_insert 结构相似的边界：写入路径的“不受惩罚”是有条件的，条件就是后台 merge 没有落后到需要触发索引限流的地步。merge 的写放大决定了这个条件在持续写入负载下有多容易被打破，而 max_thread_count 和磁盘类型决定了追赶的速度。

mapping 的 1000 个字段：另一条写进默认值的契约

在 refresh、translog 和 merge 之外，Elasticsearch 还有一条容易被当作“软限制”对待、但实际上直接拒绝写入的边界：index.mapping.total_fields.limit 默认为 1000[reference:16]。一旦某个索引的映射字段数触及这个阈值，任何会进一步引入新字段的写入请求都会被拒绝，错误信息是 Limit of total fields [...] has been exceeded while adding new fields [...][reference:17]。

这条限制的措辞不是“性能会下降”，而是写入被拒绝。它保护的是一组在 mapping 爆炸时会被严重拖累的资源：搜索延迟、JVM 堆压力、启动时间，以及协调节点上 put-mapping 任务的队列积压[reference:18][reference:19]。把动态映射打开、又不对字段增长设防的索引，最终会在字段数撞上阈值时经历一次写入路径的硬性中断，而不是一个渐进的性能退化。

1000 这个默认值被官方描述为“慷慨的”，但覆盖到 10000“可能仍然不够”[reference:20]。这说明字段限制和 durability 一样，是一个可移动的边界，移动它只是把拒绝发生的时点推迟，同时让爆炸发生时涉及的资源范围更大。它不消除问题，只改变问题以什么形式、在什么时候被感知。

承诺的兑现条件，写在这三份条款的交界处

把 refresh 的惰性周期、translog 的丢失窗口和 merge 的写放大放在一起，Elasticsearch 的持久性与可见性呈现出一种一致的结构：可见性承诺绑定在“索引正在被查询”和“refresh interval 没有被禁用或拉长”上；持久性承诺绑定在 durability 的取值和它所定义的丢失窗口上；而两者的长期可行性，绑定在 merge 能否用有限的 I/O 带宽消化掉 refresh 产生的小 segment 上。

这三者不是彼此独立的模块。缩短 refresh interval 会让 wait_for 更快返回，但产生更多碎片，加重 merge 的负担；把 durability 设为 async 会降低单次写入的 I/O 压力，但把持久性换成了一个 5 秒的赌注；merge 的写放大如果超过了磁盘的余量，最终会以索引限流的形式反过来拖慢写入。每一条“优化”都在移动边界，而不是消除边界。

判断 Elasticsearch 的承诺是否适合自己的负载，比调大某个阈值更有用的，是先确认三件事：写入之后是否真的有持续的搜索流量来触发 refresh；durability 如果被设为 async，5 秒窗口内可能丢失的数据量是否在可接受范围内；以及磁盘的写带宽在扣除 merge 的几倍到十几倍写放大之后，是否还有余量支撑当前的索引速率。边界不在“近实时”和“持久”这两个词里，在这三份条款是否同时被满足里。