深入底层：ES 8.x 的读写原理与倒排索引

这篇文章的内容非常硬核，是面试中用来区分“调包侠”和“研发工程师”的分水岭。

面试题

ES 写入数据的工作原理是什么？查询数据的工作原理是什么？底层的 Lucene 和倒排索引了解吗？

这个问题是问 “黑盒” 里的东西。
平时我们只管调 API PUT 和 GET，但如果不懂底层，一旦遇到写入慢、数据丢了、搜索不准等问题，你就两眼一抹黑。面试官想知道你是否理解数据在内存和磁盘间是如何流转的，以及 ES 是如何保证高可用和近实时的。

在 ES 的分布式架构中，有一个铁律：同一个 Shard 的 Primary（主分片）和 Replica（副本分片）绝对不会存放于同一台机器（节点）上。

为什么？ 如果主分片和副本分片都在机器 A，那机器 A 一旦宕机，主副全没，数据就彻底丢失了。
怎么做？ ES 会自动实施“反亲和性（Anti-affinity）”策略，强制把副本分散到其他机器。如果集群只有 1 台机器，副本将无法分配（Unassigned），集群状态变黄。

场景：客户端发起请求，新增或修改一条数据。

协调节点（Coordinating Node）接收请求：
客户端可以向集群中任意节点发送请求，该节点就充当“协调节点”。
路由（Routing）：
协调节点根据 hash(_id) % primary_shard_num 计算出该数据属于哪个分片（比如 Shard 0）。
转发给主分片：
协调节点查表找到 Shard 0 的 Primary Shard 所在的节点，将请求转发过去。
主分片写入：
Primary Shard 处理写入请求，写入成功后。
并发同步副本：
Primary Shard 并行将数据发送给所有的 Replica Shard。
响应客户端：
当所有的（或者满足 wait_for_active_shards 配置的）Replica Shard 都报告写入成功，Primary Shard 向协调节点报告成功，协调节点再返回给客户端“写入成功”。

场景：客户端根据 ID 查询一条数据（GET /index/_doc/1）。

协调节点接收：客户端发请求到任意节点（协调节点）。
路由计算：协调节点计算 hash，知道数据在 Shard 0。
智能负载均衡（ARS）：
- 老版本：简单的随机轮询（Round-Robin）。
- ES 7/8 新特性：ARS (Adaptive Replica Selection)。协调节点会记录每个节点的健康状况和响应速度，智能选择一个响应最快、负载最低的副本（或者是主分片）来查询。
返回结果：持有数据的节点将文档返回给协调节点，协调节点转发给客户端。

场景：全文检索（比如搜索关键词 “Java”）。
这是一个两阶段过程：Query Then Fetch。

这是面试最爱问的细节，涉及数据会不会丢！

ES 的写入不是直接写硬盘，而是经过了复杂的内存缓冲。

写入 Buffer 和 Translog：
数据先写入 Memory Buffer，同时追加写入 Translog 文件（防止内存断电丢失）。此时数据搜索不到。
Refresh（默认 1秒）：
- 每隔 1 秒，ES 将 Buffer 里的数据刷新到 OS Cache 中，并生成一个新的 Segment。
- 关键点：一旦进入 OS Cache，数据就可以被搜索到了。
- 这就是为什么 ES 被称为“近实时（Near Realtime）”搜索，因为有 1 秒延迟。
- Refresh 后，清空 Memory Buffer，但 Translog 保留。
Flush（默认 30分钟或 Translog 过大）：
- 随着时间推移，Translog 越来越大。触发 Flush 操作。
- 执行 Commit：强行将 OS Cache 里的所有 Segment fsync（物理落盘）到磁盘。
- 清空 Translog：因为数据已经安全落盘，旧日志可以删了。

问：ES 会丢数据吗？
答：可能会，但只有 5 秒。
Translog 默认每 5 秒（异步）刷一次盘。如果机器在数据写入 Buffer 且 Translog 还没刷盘的那几秒宕机，内存里的数据就没了。
- 怎么解决？ 金融级业务可以把 Translog 设置为 request（同步），每次写入必须落盘才返回成功，但性能会由于频繁 IO 而下降。