Elasticsearch（搜索引擎）分片副本、写入查询与一致性

项目版本：待现场核对。学习基线版本：待现场核对。本文不作“最新版”断言；默认值、确认条件、缓存资格、磁盘水位、选主与恢复行为均以版本核对卡、现场配置和最小实验为准。

1. 逻辑模型、路由与分片成本

1.1 cluster（集群）、node（节点）、index（索引）、shard（分片）与 Lucene（全文检索库）分段

Elasticsearch（搜索引擎）把面向业务的 index（索引）拆成固定数量的 primary shard（主分片），每个 primary shard（主分片）可拥有若干 replica shard（副本分片）。primary shard（主分片）与 replica shard（副本分片）本质上都是可被 node（节点）承载的 shard（分片）副本；每个 shard（分片）又是一个独立的 Lucene（全文检索库）索引，由不可变 segment（分段）、提交点和相关元数据组成。document（文档）通过 routing（路由）只归属于一个 primary shard（主分片），副本保存该分片的冗余拷贝。cluster state（集群状态）记录索引元数据、映射、路由表和分片分配等全局事实，必须由集群管理路径发布到各 node（节点），它不是业务文档的数据面。

表 1：逻辑到物理责任边界

flowchart TB
  C["cluster 集群"] --> N1["node A 节点"]
  C --> N2["node B 节点"]
  C --> N3["node C 节点"]
  I["index shipments 索引"] --> P0["primary shard 0 主分片"]
  I --> P1["primary shard 1 主分片"]
  P0 --> R0["replica shard 0 副本分片"]
  P1 --> R1["replica shard 1 副本分片"]
  P0 --> L0["Lucene index"]
  L0 --> S1["segment s1 分段"]
  L0 --> S2["segment s2 分段"]
  CS["cluster state 集群状态"] --> I
  CS --> N1
  CS --> N2
  N1 -.失联.-> F["重新分配与提升"]

图 1 说明。 节点表示 cluster（集群）、node（节点）、index（索引）、主副 shard（分片）和 Lucene（全文检索库）segment（分段）的包含与分配关系；实线箭头是正常元数据或数据归属，虚线箭头是节点失联后的失败分支。前提是 cluster state（集群状态）可形成一致路由视图；正常路径由索引路由到一个主分片并复制；失败路径触发提升和重新分配。业务结论是分片是容量、并行和恢复单位，而索引只是逻辑入口。

数据演绎 1：20 个主分片与 1 个副本。 一个跨境物流 index（索引）配置 20 个 primary shard（主分片）和每主分片 1 个 replica shard（副本分片），逻辑上共有 40 个分片副本。若主数据为 2 TB（太字节），暂不计段合并临时空间和 translog（事务日志），平均每个主分片约 100 GB（吉字节），主副合计基础数据约 4 TB（太字节）。10 个数据 node（节点）理想均衡时每节点承载约 4 个分片副本；节点失联后，受影响分片的提升和 100 GB（吉字节）级恢复可并行，但会争用网络、磁盘和文件系统缓存。若预先建立 200 个主分片，单分片变小却使分片元数据、线程调度、小段和未来搬迁对象数量增加；若只有 2 个主分片，则最大写入与查询并行度、扩容迁移粒度都受限。验证必须同时看分片大小分布、热点、恢复时长与堆占用，不能只看平均数。

热门面试题

1. 问题（基础题）：index（索引）与 shard（分片）是什么关系？
   • 考点：逻辑入口与物理执行单元。
   • 回答思路：先说索引定义，再落到 Lucene（全文检索库）实例。
   • 详细答案：index（索引）保存映射、主分片数与副本策略等逻辑定义；一个 index（索引）拆成多个 primary shard（主分片），每个 shard（分片）是独立 Lucene（全文检索库）索引，document（文档）只属于其中一个主分片及其副本。
   • 进阶追问：查询一个索引是否只访问一个分片？
   • 进阶回答：未提供有效 routing（路由）时通常要扇出到该索引的目标分片；提供与写入一致的路由值时才可缩小范围。
2. 问题（原理题）：为什么 segment（分段）设计成不可变？
   • 考点：并发读写、缓存与后台合并。
   • 回答思路：说明新写产生新结构，旧读保持稳定。
   • 详细答案：不可变 segment（分段）允许搜索线程稳定读取既有结构，新文档先进入缓冲并在 refresh（刷新）时形成新分段；删除和更新通过标记与新版本表达，后台 merge（合并）再整理，从而把并发修改复杂度换成写放大和合并成本。
   • 进阶追问：不可变是否意味着没有更新？
   • 进阶回答：业务上可以更新，但底层通常删除旧文档并索引新文档，旧分段不会原地改写。
3. 问题（场景题）：20 个主分片是否一定比 5 个更好？
   • 考点：容量、并行、恢复与元数据权衡。
   • 回答思路：用单分片规模、节点数、热点和迁移说明。
   • 详细答案：不一定。更多主分片能增加并行和迁移粒度，却增加分片固定成本、协调扇出和小段压力；更少主分片管理简单，却可能限制吞吐、扩容和恢复并行。应以目标数据量、增长、节点拓扑、查询形状和恢复时间实测。
   • 进阶追问：主分片数选错如何处理？
   • 进阶回答：通常通过新索引重建、重新索引和别名切换调整，具体缩分片或拆分能力按现场版本核对，不能假定零成本在线修改。

1.2 routing（路由）、主分片数、热点与未来迁移

routing（路由）把 document（文档）的路由值稳定映射到某个 primary shard（主分片）；未显式指定时通常以文档标识参与计算，显式指定运单号则同一运单文档进入同一分片。主分片数参与映射空间，决定写入局部性、无路由查询的扇出上限和扩容时需要搬运或重建的颗粒度。路由不是“让数据平均”的魔法：大客户、热门线路或单一设备的文档量远高于平均值时，按这些键路由会形成热点。写入与查询必须使用一致的 routing（路由），否则更新可能找不到旧文档，查询也会漏数。

表 2：路由策略与代价

flowchart LR
  D["document 文档"] --> K["routing 运单号"]
  K --> H["稳定散列与路由空间"]
  H --> P0["primary shard 0"]
  H --> P1["primary shard 1"]
  H --> P19["primary shard 19"]
  P0 --> R0["replica shard 0"]
  Q["携带相同 routing 的查询"] --> P0
  Q2["未携带 routing 的查询"] --> FAN["扇出 20 个主分片"]
  BIG["大租户占 45%"] -.热点.-> P1
  P1 -.迁移或重建.-> NEW["新索引与新路由规则"]

图 2 说明。 节点表示文档、路由值、稳定映射、20 个主分片与查询入口；实线箭头是按相同路由写查的正常路径，虚线箭头表示大租户热点和重建迁移。前提是路由算法、主分片数和业务键在索引生命周期内稳定；正常路径把同运单查询收敛到一个主分片；失败路径因数据倾斜打满单分片。业务结论是路由用局部性换均衡与变更灵活性，必须提前设计退出路径。

数据演绎 2：按运单号路由。 1 亿条跨境轨迹属于 1000 万个运单，平均每单 10 条。20 个 primary shard（主分片）理想平均各 500 万条；使用运单号 routing（路由）后，查询 shipment-9001 只访问一个主分片并读取约 10 条轨迹，而不带路由的相同查询会向 20 个主分片发起请求。若某批次错误地把 5000 万条扫描事件都写在同一个“总运单号”下，该路由值对应分片承受约一半数据，平均模型立即失效。止血是暂停异常生产者、隔离该键和限制查询；修复是调整业务粒度或为超大实体引入受控分桶，并通过新索引回放。回归要比较每分片文档数、写入耗时、查询扇出和路由命中率。

热门面试题

1. 问题（基础题）：routing（路由）解决什么问题？
   • 考点：文档归属与查询局部性。
   • 回答思路：从写入映射和读取缩小范围回答。
   • 详细答案：routing（路由）将文档稳定映射到一个主分片；查询携带相同值时可只访问目标分片，减少协调扇出。它不保证均匀，键分布不均会把业务热点直接映射成分片热点。
   • 进阶追问：显式路由后能否只用文档标识更新？
   • 进阶回答：不能依赖这种做法；更新、删除和读取应携带与首次写入一致的 routing（路由），否则可能定位到不同分片。
2. 问题（原理题）：主分片数为何影响未来迁移成本？
   • 考点：固定映射空间与物理搬运。
   • 回答思路：说明分片既是路由单位也是恢复单位。
   • 详细答案：主分片数参与文档归属，改变后必须让文档进入新的路由空间，通常需要新索引、全量扫描、增量追平、校验和切换；分片过大使搬运恢复慢，过多则使元数据、调度和扇出昂贵。
   • 进阶追问：增加节点会自动增加主分片数吗？
   • 进阶回答：不会。增加节点只能重新分配既有分片，不能凭空提高该索引的主分片并行上限。
3. 问题（场景题）：大租户路由热点怎样治理？
   • 考点：倾斜识别、止血和重建。
   • 回答思路：先证明确是单路由热点，再设计分桶。
   • 详细答案：先比较各分片写入率、文档数、段数、队列与磁盘，确认大租户键集中；止血可限流和隔离重查询，长期按租户加稳定桶拆分，并让查询显式访问桶集合，通过可回放事件重建新索引。
   • 进阶追问：随机路由能否快速解决？
   • 进阶回答：随机会破坏幂等定位与查询局部性；必须保存可重算的确定性桶规则，并处理历史数据迁移。

2. 写入、确认、可见与持久化

2.1 协调节点、primary shard（主分片）、translog（事务日志）与 replica shard（副本分片）

客户端请求可到任意可接收请求的 node（节点），该节点作为 coordinating node（协调节点）解析 index（索引）与 routing（路由），再把写入转发到目标 primary shard（主分片）。主分片校验映射与并发条件，分配 seq_no（序列号），把变更加入 in-memory indexing buffer（内存索引缓冲）并追加 translog（事务日志），随后向处于当前同步集合的 replica shard（副本分片）复制操作。客户端确认条件、translog（事务日志）刷盘策略与副本等待边界属于版本和配置敏感行为，必须现场核对；不能把“收到成功”自动翻译为所有副本磁盘已稳定，也不能把副本成功翻译为搜索已经可见。

表 3：写入链路的四个判断点

sequenceDiagram
  participant C as 客户端
  participant O as 协调节点
  participant P as 主分片
  participant B as 内存缓冲与事务日志
  participant R as 副本分片
  C->>O: 写入文档与路由值
  O->>P: 转发到目标主分片
  P->>P: 校验并分配序列号
  P->>B: 写缓冲并追加事务日志
  P->>R: 复制操作
  alt 副本成功且满足确认条件
    R-->>P: 操作成功
    P-->>O: 主分片阶段完成
    O-->>C: 返回成功
  else 副本失败或超时
    R--xP: 未知或失败
    P-->>O: 返回失败或未知结果
    O-->>C: 客户端必须查证后重试
  end

图 3 说明。 参与者是客户端、协调节点、主分片、内存缓冲与事务日志、副本分片；箭头按写入时序展示转发、排序、复制和响应。前提是 cluster state（集群状态）中的路由仍有效；正常路径满足现场确认条件后返回；失败路径在副本或网络超时时留下未知结果。业务结论是重试必须携带业务幂等键并查证结果，不能把超时直接当作未写入。

热门面试题

1. 问题（基础题）：coordinating node（协调节点）在写入中做什么？
   • 考点：路由与请求转发。
   • 回答思路：区分协调职责和主分片职责。
   • 详细答案：协调节点解析目标 index（索引）和 routing（路由），根据 cluster state（集群状态）把请求发给目标 primary shard（主分片），并向客户端汇总结果；真正分配 seq_no（序列号）和排序复制的是主分片。
   • 进阶追问：协调节点是否必须是专用角色？
   • 进阶回答：任意可处理请求的节点都可能承担协调工作；是否设置专用协调节点要按查询扇出、堆与网络压力现场设计。
2. 问题（原理题）：translog（事务日志）与 segment（分段）各负责什么？
   • 考点：恢复日志与搜索结构。
   • 回答思路：按写入恢复和搜索读取区分。
   • 详细答案：translog（事务日志）记录尚未完全落入持久提交点的操作，用于故障恢复；segment（分段）是 Lucene（全文检索库）搜索结构，refresh（刷新）后可被搜索器打开。两者生命周期和目的不同。
   • 进阶追问：有事务日志是否无需 flush（冲刷）？
   • 进阶回答：不能这样理解。flush（冲刷）建立新的持久提交点并滚动事务日志代际，触发条件与成本需按现场版本和配置核对。
3. 问题（场景题）：副本超时后能否立即重复写？
   • 考点：未知结果与幂等。
   • 回答思路：先查业务键和版本，再决定重试。
   • 详细答案：不能把超时等同于失败。主分片可能已接受甚至副本已执行，只是响应丢失；应以稳定文档标识、业务幂等键和版本查证，重试时保留相同语义，避免生成重复文档或覆盖新状态。
   • 进阶追问：随机生成新文档标识重试有什么后果？
   • 进阶回答：同一业务操作会形成多份文档，后续搜索、聚合和删除都可能重复，且难以对账。

2.2 refresh（刷新）、flush（冲刷）、merge（合并）与三种时间边界

refresh（刷新）把 in-memory indexing buffer（内存索引缓冲）中的内容写成新 segment（分段）并打开新的搜索视图，使文档近实时可见；它不是业务事务提交，也不等价于持久化快照。flush（冲刷）建立 Lucene（全文检索库）提交点并滚动 translog（事务日志）代际，面向恢复边界。merge（合并）后台读取多个不可变 segment（分段），写出更大分段并清理可回收删除，以降低段数量和读放大；提交新分段前旧分段仍要保留，因此产生额外处理器、磁盘输入输出和临时空间。三者不能按“刷新、冲刷、合并就是依次提交”的单一事务理解。

表 4：refresh（刷新）、flush（冲刷）与 merge（合并）

sequenceDiagram
  participant C as 客户端
  participant P as 主分片
  participant B as 索引缓冲
  participant T as 事务日志
  participant S as 分段与搜索器
  C->>P: 写入文档
  P->>B: 加入内存索引缓冲
  P->>T: 追加事务日志
  P-->>C: 满足配置后确认
  C->>S: 立即搜索
  S-->>C: 可能尚不可见
  P->>S: refresh 生成并打开新分段
  C->>S: 再次搜索
  S-->>C: 可见
  P->>S: flush 建立提交点
  P->>S: merge 合并多个分段
  alt 合并空间不足
    S-->>P: 合并退避或失败
  end

图 4 说明。 参与者是客户端、主分片、索引缓冲、事务日志与分段搜索器；箭头把写入确认、首次搜索、刷新可见、冲刷提交和后台合并放在同一时间线。前提是具体刷新周期、日志策略和合并策略已现场核对；正常路径在确认后经过刷新才可搜索；失败路径是合并因空间不足退避。业务结论是确认、持久化和可见性必须分别监控和承诺。

数据演绎 3：1 秒刷新与 100 个小段合并。 某异步任务日志 index（索引）每秒写 2 万条，refresh interval（刷新间隔）设为 1 秒，10 个活跃 primary shard（主分片）理想情况下每秒都可能产生新 segment（分段），10 秒便约有 100 个小段，副本还会形成对应结构。假设 100 个小段各 80 MB（兆字节），合并读取约 8 GB（吉字节）并写出 6 GB（吉字节）新分段，提交前旧段仍占空间，瞬时至少增加约 6 GB（吉字节）临时占用，且与前台索引和查询争用磁盘。把刷新间隔拉长可减少小段和提高写吞吐，却增加搜索可见延迟；是否调整必须以业务新鲜度、段数、合并时间和查询尾延迟共同验证。

热门面试题

1. 问题（基础题）：refresh（刷新）后能说明什么？
   • 考点：近实时搜索可见性。
   • 回答思路：只承诺新搜索视图，不扩大到业务事务。
   • 详细答案：refresh（刷新）后，新生成的 segment（分段）被搜索器打开，后续搜索有机会看到该文档；它不证明业务主库事务已提交，也不证明独立 snapshot（快照）存在。
   • 进阶追问：为什么写成功后立即搜索可能查不到？
   • 进阶回答：写入确认可早于下一次 refresh（刷新），当时新文档仍在缓冲或尚未被当前搜索器打开。
2. 问题（原理题）：merge（合并）为什么会造成写放大？
   • 考点：不可变分段的后台重写。
   • 回答思路：说明读旧、写新、提交后删旧。
   • 详细答案：merge（合并）不能原地拼接不可变 segment（分段），需要读取多个旧段、过滤删除并写出新段，提交后才释放旧段；同一文档生命周期内可能被多轮重写，因此产生额外磁盘和处理器成本。
   • 进阶追问：能否永久关闭合并？
   • 进阶回答：不应。段数会持续增长，查询要访问更多结构并保留删除垃圾；应治理写入和刷新节奏并保障合并资源。
3. 问题（场景题）：日志要求 1 秒可见但小段过多怎么办？
   • 考点：新鲜度与吞吐取舍。
   • 回答思路：先分流高低优先级，再按证据调整。
   • 详细答案：先确认是否所有日志都需要 1 秒可见，可把关键任务状态与普通明细分索引或分层；同时聚批写入、控制刷新、限制低价值查询并观察段数和合并。不能只加合并线程扩大输入输出竞争。
   • 进阶追问：调整后如何回归？
   • 进阶回答：同时验证写入吞吐、可见延迟、段数、合并字节、查询高分位延迟和磁盘余量。

2.3 mapping（映射）、更新重建、多字段与写放大

mapping（映射）决定字段类型及其索引、存储、doc values（列式值）和分析方式。text（全文字段）面向分词召回，keyword（精确字段）面向精确过滤、排序和 aggregation（聚合）；multi-field（多字段）可让同一原始值建立两套或更多结构，但每套结构都增加写入、磁盘和合并成本。nested（嵌套字段）常以额外隐藏文档维护对象数组的关联，更新父对象可能放大成多个底层文档。动态 mapping（映射）若吸收任意键，会造成 mapping explosion（映射爆炸）和 cluster state（集群状态）膨胀。Lucene（全文检索库）不可变 segment（分段）使更新通常表现为旧文档删除加整文档重新索引，而不是只改一个字段。

表 5：字段模型与写放大来源

flowchart LR
  D["原始 document 文档"] --> T["text 全文字段"]
  D --> K["keyword 精确字段"]
  D --> M["multi-field 多字段"]
  D --> N["nested 嵌套字段"]
  T --> I1["倒排结构"]
  K --> I2["倒排与 doc values"]
  M --> I3["多套索引结构"]
  N --> I4["父文档加隐藏文档"]
  U["更新一个字段"] --> DEL["标记旧文档删除"]
  U --> NEW["重建整文档"]
  NEW --> SEG["新 segment 分段"]
  DY["任意动态键"] -.字段爆炸.-> CS["cluster state 压力"]

图 5 说明。 节点表示原始文档、五类字段建模、底层索引结构和更新重建；实线箭头是正常索引与更新路径，虚线箭头是动态键导致映射和集群状态膨胀。前提是查询需求与字段生命周期已知；正常路径只建立必要结构；失败路径把业务属性键直接变成无限字段。业务结论是搜索读取速度来自预付写放大，映射必须按查询价值受控。

数据演绎 4：1000 万文档更新。 WMS（仓储管理系统）商品索引有 1000 万个 document（文档），每个原始文档平均 2 KB（千字节），其中商品名同时建立 text（全文字段）与 keyword（精确字段），另有 20 个可过滤字段和 1 个 5 项 nested（嵌套字段）数组。若价格变化触发全量 1000 万文档更新，单看原始文档就要重新处理约 20 GB（吉字节）；主分片加 1 个副本至少复制两份写入，旧文档删除、新倒排结构、doc values（列式值）、嵌套隐藏文档和后续 merge（合并）还会继续放大，实际输入输出远高于 40 GB（吉字节）。正确方案是先判断价格是否必须进入搜索文档，采用增量事件、稳定文档标识和节流重放；全量重建时用新索引、断点水位、校验和别名切换，避免在原索引上制造不可控删除垃圾。

热门面试题

1. 问题（基础题）：text（全文字段）与 keyword（精确字段）怎样选择？
   • 考点：召回、过滤、排序和聚合。
   • 回答思路：按查询意图而不是字段外观选择。
   • 详细答案：需要分词、相关性召回的内容用 text（全文字段）；需要精确匹配、去重、排序或 aggregation（聚合）的值用 keyword（精确字段）。同一值确有两类查询才使用 multi-field（多字段）。
   • 进阶追问：所有字符串都建双字段可以吗？
   • 进阶回答：会增加索引、列式值、合并和堆外缓存压力；应以查询日志证明每套结构有价值。
2. 问题（原理题）：为什么更新一个字段仍可能重建整文档？
   • 考点：不可变分段与文档索引单元。
   • 回答思路：说明旧版本删除和新版本索引。
   • 详细答案：Lucene（全文检索库）segment（分段）不可原地修改，更新通常将旧文档标为删除，再按完整来源构造新文档并建立相关字段结构；嵌套模型还会放大到底层隐藏文档。
   • 进阶追问：频繁变化字段如何设计？
   • 进阶回答：先评估是否应留在权威库、缓存或独立小文档，避免让大文档因高频小字段反复重建。
3. 问题（场景题）：动态字段爆炸怎样止血？
   • 考点：映射控制与集群状态。
   • 回答思路：先阻断新字段，再修正数据模型。
   • 详细答案：立即限制异常生产者和动态映射，按模板白名单接收字段；把任意属性改为键值数组或受控对象，新建索引重放有效字段。回归检查映射数量、集群状态发布耗时和主节点堆压力。
   • 进阶追问：删除映射中的旧字段能否立即恢复？
   • 进阶回答：不能假设可原地删除历史字段结构，通常要通过新索引重建清理，并按现场版本核对具体能力。

3. 并发控制、任期与故障一致性

3.1 seq_no（序列号）、primary_term（主分片任期）、乐观并发与未知结果

primary shard（主分片）为接受的变更分配单调推进的 seq_no（序列号），primary_term（主分片任期）在主分片代际切换时推进，两者共同标识“哪个主分片代际中的哪次操作”。客户端可在读取文档后携带观察到的序列号与任期做 optimistic concurrency control（乐观并发控制）：只有当前版本仍匹配才允许更新，避免旧读覆盖新写。它解决单文档并发覆盖，不自动提供跨文档业务事务。网络超时会制造 unknown outcome（未知结果）：服务端可能未处理、已经处理但响应丢失，或主分片处理后故障切换；此时必须用稳定业务键查证，不能盲目重复副作用。

表 6：并发与重试边界

sequenceDiagram
  participant A as 客户端甲
  participant B as 客户端乙
  participant P as 主分片
  A->>P: 读取版本 序列号 40 任期 7
  B->>P: 读取版本 序列号 40 任期 7
  A->>P: 条件更新为运输中
  P-->>A: 成功 序列号 41 任期 7
  B->>P: 条件更新为已揽收
  P--xB: 条件冲突
  B->>P: 重新读取并执行领域合并
  alt 网络在响应前超时
    A-xP: 响应丢失
    A->>P: 按稳定业务键查证
    P-->>A: 返回当前序列号与业务状态
  end

图 6 说明。 参与者是两个并发客户端和当前主分片，箭头显示同版本读取、一个成功、一个冲突以及响应丢失后的查证。前提是客户端保存读到的 seq_no（序列号）与 primary_term（主分片任期），且文档标识稳定；正常路径通过条件写阻止丢失更新；失败路径是超时后结果未知。业务结论是并发条件保护文档版本，业务幂等保护重复副作用，两者不可互换。

数据演绎 5：写入超时的未知结果。 跨境物流消费者准备把运单 S9001 的投影版本从 87 更新为 88，请求携带稳定文档标识与业务版本 88。主分片已分配 seq_no（序列号）1042，并向副本发送操作，但客户端在 2 秒时超时。三种可能分别是未到主分片、主分片已写但响应丢失、主分片切换后新主已保留该操作。消费者不能改用随机标识再次插入，而应读取 S9001：若业务版本已是 88，则把事件标为完成；若仍为 87，则用同一业务版本重试；若已是 89，则拒绝旧事件并记录乱序。验证以权威事件版本、索引版本和失败队列三方对齐为准，不能以 HTTP（超文本传输协议）超时次数估算丢失数。

热门面试题

1. 问题（基础题）：seq_no（序列号）与 primary_term（主分片任期）分别表达什么？
   • 考点：操作顺序与主分片代际。
   • 回答思路：一个定位任期内顺序，一个区分故障切换代际。
   • 详细答案：seq_no（序列号）标识分片操作顺序，primary_term（主分片任期）区分主分片代际；组合后可判断客户端依据的版本是否仍属于当前有效写入历史。
   • 进阶追问：它们能替代业务版本吗？
   • 进阶回答：不能。它们是索引内部并发坐标，物流状态、库存事件仍需业务版本表达跨系统顺序和回放规则。
2. 问题（原理题）：乐观并发为什么能防止丢失更新？
   • 考点：比较后写入。
   • 回答思路：用两个客户端读同一版本的例子回答。
   • 详细答案：客户端更新时声明“仅当当前序列号与任期仍等于我读取的值才写”；第一个成功后坐标变化，第二个条件不再成立而冲突，从而阻止旧状态无声覆盖新状态。
   • 进阶追问：冲突后自动重试就可以吗？
   • 进阶回答：只有更新函数可安全重算时才可受控重试；状态机冲突可能需要领域规则或回源，不能机械覆盖。
3. 问题（场景题）：超时重试如何避免重复？
   • 考点：未知结果、稳定标识与查证。
   • 回答思路：先读当前业务版本，再决定完成、重试或丢弃。
   • 详细答案：使用稳定文档标识和业务事件版本；超时后查询同一键，版本相同视为已完成，版本较低才重试，版本更高则拒绝旧事件。外部副作用仍在权威系统独立幂等。
   • 进阶追问：查询也超时怎么办？
   • 进阶回答：保留事件与断点，指数退避并进入可观测重试队列，不能用新键绕过不确定状态。

3.2 主分片切换、旧主拒写、副本确认与 snapshot（快照）边界

节点失联后，集群管理路径依据可用分片副本与已知同步状态选择提升候选，发布新的 cluster state（集群状态）并推进 primary_term（主分片任期）。旧 primary shard（主分片）即使稍后恢复，也必须接受新任期和新路由，不能继续以旧代际处理写入；这构成 split brain（脑裂）防护的重要部分，但选举资格、发现配置和发布确认属于版本敏感行为，必须按现场拓扑核对。replica shard（副本分片）用于当前数据冗余、读扩展和提升，可能与主分片一起遭遇误删、映射错误或集群级损坏，因此不能替代独立 snapshot（快照）。snapshot（快照）也有开始、结束与索引变化边界，必须通过恢复演练验证，而不是只看任务成功。

表 7：故障与保护机制的责任

sequenceDiagram
  participant M as 集群管理节点
  participant P as 旧主分片
  participant R as 副本分片
  participant N as 新副本目标
  P-xM: 节点失联
  M->>M: 形成并发布新集群状态
  M->>R: 提升并推进主分片任期
  R-->>M: 新主可服务
  P->>R: 旧主恢复后尝试旧任期写入
  R--xP: 拒绝旧任期
  M->>N: 分配新的副本
  R->>N: 复制分段并追赶操作
  N-->>M: 校验完成并加入同步集合
  alt 恢复资源过载
    M-->>N: 限速或延迟承载查询
  end

图 7 说明。 参与者是集群管理节点、旧主、副本和新副本目标；箭头展示节点失联、任期推进、旧主拒写与副本追赶。前提是至少存在可被确认的有效副本；正常路径提升后补回冗余；失败路径是恢复流量过载而被限速。业务结论是故障恢复先恢复唯一写入代际，再恢复副本数量，最后才逐步恢复读流量。

flowchart LR
  P["primary shard 主分片"] --> R["replica shard 副本分片"]
  P --> S["snapshot 快照仓库"]
  R --> HA["在线提升与读扩展"]
  S --> DR["独立恢复点"]
  BAD["错误删除或错误映射"] --> P
  BAD --> R
  BAD -.不能自动污染既有快照.-> S
  S -.恢复演练失败.-> FIX["修复范围、权限与仓库"]

图 8 说明。 节点表示主分片、副本、快照仓库、在线高可用和灾难恢复；实线箭头是复制与快照的正常保护路径，虚线箭头说明同一错误会传播到主副分片而既有独立快照仍需恢复验证。前提是仓库与生产故障域隔离；正常路径副本处理在线故障、快照处理历史恢复；失败路径是快照无法恢复。业务结论是副本和快照保护不同风险，二者都不能证明业务主库事实正确。

数据演绎 6：节点失联与主分片提升。 10 个 node（节点）承载 20 个 primary shard（主分片）和 20 个 replica shard（副本分片），节点 A 失联时其上 2 个主分片与 2 个副本不可用。若两个主分片的对应副本分别在节点 B、C 且具备提升资格，集群先推进任期并恢复写入；原 A 上的两个副本对应主分片仍在线，所以数据可读但冗余降低。此时 cluster health（集群健康）可能处于 yellow（黄色）而非 red（红色），具体要看是否所有主分片可分配。若立即全速重建 4 个副本，每个 100 GB（吉字节），至少搬运约 400 GB（吉字节），还会与前台查询竞争。应按恢复限速和业务优先级追赶，验证新主任期、未分配原因、恢复字节和抽样业务版本，再重新开放大查询。

热门面试题

1. 问题（基础题）：副本为什么不能当 snapshot（快照）？
   • 考点：在线冗余与独立恢复点。
   • 回答思路：比较故障传播范围。
   • 详细答案：replica shard（副本分片）持续接收主分片操作，错误删除、错误更新和映射问题也会传播；snapshot（快照）保留独立时间点恢复材料，仍需隔离仓库和恢复演练。
   • 进阶追问：有快照是否无需副本？
   • 进阶回答：不能。快照恢复通常无法承担秒级在线提升，副本用于在线可用性，快照用于历史恢复。
2. 问题（原理题）：旧主为何必须拒写？
   • 考点：单一有效写入代际。
   • 回答思路：用任期解释网络分区后的冲突历史。
   • 详细答案：新主提升后 primary_term（主分片任期）推进，旧主若继续写会形成两条分叉历史；恢复节点必须接受新 cluster state（集群状态），旧任期操作不再有效，才能维持单一主分片代际。
   • 进阶追问：仅靠客户端连接新主够吗？
   • 进阶回答：不够。网络与缓存路由可能陈旧，服务端任期检查必须成为最终防线。
3. 问题（场景题）：节点失联后为什么不立即把恢复并发开满？
   • 考点：恢复风暴与前台保护。
   • 回答思路：量化网络、磁盘和缓存竞争。
   • 详细答案：副本恢复会复制大量分段并追赶变更，全速并发可能打满磁盘和网络、驱逐文件系统缓存，使剩余健康节点查询恶化；应按恢复目标、容量余量和前台高分位延迟限速。
   • 进阶追问：何时算恢复完成？
   • 进阶回答：分片进入正确状态只是一步，还要核对同步水位、业务样本、查询延迟和冗余分布，并执行后续快照验证。

3.3 cluster health（集群健康）、近实时可见与业务一致性边界

green（绿色）、yellow（黄色）、red（红色）首先描述分片分配：通常 green（绿色）表示主副分片均已分配，yellow（黄色）表示主分片可用但部分副本未分配，red（红色）表示至少存在未分配主分片；精确状态与索引范围必须以现场接口核对。它不证明数据内容正确、事件投影追平、搜索刚写文档已 refresh（刷新），也不证明权威数据库事务与搜索索引一致。搜索系统应被视为可重建 projection（投影）：业务主库或可回放事件日志保存权威事实，索引消费者处理幂等、顺序、删除、断点、校验和回放；搜索不可用时可以降级回源或限制功能，但不得反向裁决库存、支付或任务执行。

表 8：六种“正常”的不同含义

flowchart LR
  DB["数据库或事件日志 权威源"] --> E["带业务键与版本的事件"]
  E --> ES["Elasticsearch 搜索投影"]
  ES --> Q["检索与聚合"]
  V["水位与校验任务"] --> DB
  V --> ES
  DEL["删除事件"] --> ES
  ES -.不可用或滞后.-> DEG["受限查询或降级回源"]
  Q -.禁止反向裁决.-> DB
  V -.发现差异.-> E

图 9 说明。 节点表示权威数据库或事件日志、版本化事件、搜索投影、查询、校验和降级路径；实线箭头是正常投影、删除与校验，虚线箭头是滞后回源、禁止反向裁决和差异回放。前提是事件可重放且业务键稳定；正常路径在可接受窗口内收敛；失败路径限制搜索能力并回放缺口。业务结论是集群健康是基础设施指标，投影一致性必须由业务水位和对账证明。

数据演绎 7：集群绿色但业务漏单。 运单权威库已提交事件版本 900 万，索引消费者水位停在 899 万，搜索 cluster health（集群健康）仍为 green（绿色），因为所有主副分片都已分配。客服按最新运单号查询时漏掉约 1 万个事件对应的文档，这不是分片分配故障，而是投影积压。止血先在客服入口对精确运单号启用受限回源，并保留搜索模糊查询；修复消费者毒事件或下游拒绝后，从 899 万断点幂等重放。回归同时检查水位差归零、删除传播、关键状态聚合和抽样详情，证明“绿色”与“业务收敛”分别恢复。

热门面试题

1. 问题（基础题）：yellow（黄色）一定不能提供查询吗？
   • 考点：主分片可用与副本不足。
   • 回答思路：先看目标主分片，再看风险窗口。
   • 详细答案：通常 yellow（黄色）表示主分片仍已分配而部分副本缺失，查询可能继续服务；但冗余降低、恢复负载和下一次故障风险上升，必须查明未分配原因，不能长期忽略。
   • 进阶追问：单节点集群长期黄色可以接受吗？
   • 进阶回答：需核对副本配置和用途；即使开发环境可接受，也不能把该状态的风险结论直接带到生产。
2. 问题（原理题）：为什么搜索近实时不等于业务最终一致已完成？
   • 考点：系统内刷新与跨系统投影。
   • 回答思路：分开主库提交、事件消费和搜索刷新。
   • 详细答案：refresh（刷新）只让已进入分片的文档对搜索可见；若权威事件尚未投递、消费者积压、映射错误或删除漏传，搜索仍与业务事实不一致。必须用事件水位和对账验证跨系统收敛。
   • 进阶追问：强制刷新能解决消费者积压吗？
   • 进阶回答：不能。它只刷新已经写入的内容，还可能制造更多小段，无法补回未消费事件。
3. 问题（场景题）：搜索漏单时何时降级回源？
   • 考点：查询形状与权威边界。
   • 回答思路：精确键可回源，复杂全文查询受限。
   • 详细答案：按运单号、任务标识等精确键可在限流和权限控制下回权威库；全文召回和大聚合不应直接压向主库，可提示数据更新中、缩小条件或暂停低优先级功能。
   • 进阶追问：恢复后怎样取消降级？
   • 进阶回答：水位追平、关键校验通过且搜索高分位延迟稳定后灰度关闭回源，并观察差异是否复发。

4. 查询、分页、排序与聚合

4.1 query phase（查询阶段）、局部 Top-K（最高 K 个结果）、归并与 fetch phase（取回阶段）

无有效 routing（路由）的搜索由 coordinating node（协调节点）向目标 shard（分片）的一个可用副本扇出 query phase（查询阶段）。每个分片执行局部匹配、评分或排序，保留本地 Top-K（最高 K 个结果），只返回文档标识、分数、排序值等轻量候选。协调节点把各分片候选做全局归并，选出最终窗口后再进入 fetch phase（取回阶段），向实际持有命中文档的分片取回 _source 等内容。排序或过滤常依赖 doc values（列式值），全文评分依赖倒排结构；最慢分片、候选窗口和命中文档大小共同决定尾延迟与协调节点内存。

表 9：查询两阶段成本

sequenceDiagram
  participant C as 客户端
  participant O as 查询协调节点
  participant S0 as 分片零
  participant S1 as 分片一
  participant S19 as 分片十九
  C->>O: 查询 size 等于 20
  par 查询阶段扇出
    O->>S0: 局部匹配评分与最高 K
    O->>S1: 局部匹配评分与最高 K
    O->>S19: 局部匹配评分与最高 K
  end
  S0-->>O: 标识 分数 排序值
  S1-->>O: 标识 分数 排序值
  S19-->>O: 标识 分数 排序值
  O->>O: 全局归并前 20
  O->>S0: 取回命中文档
  O->>S1: 取回命中文档
  S0-->>O: 文档内容
  S1-->>O: 文档内容
  O-->>C: 返回全局结果
  alt 一个分片变慢
    S19--xO: 超时拖慢整体
  end

图 10 说明。 参与者是客户端、协调节点和多个分片，箭头按查询阶段并行扇出、局部候选返回、全局归并与取回阶段排列。前提是目标分片可用且排序定义一致；正常路径只取回最终命中文档；失败路径是单个慢分片拖住整体。业务结论是最终只返回 20 条不代表只处理 20 条，分片数和候选窗口决定中间成本。

数据演绎 8：20 分片的局部与全局 Top-K（最高 K 个结果）。 查询最近异常运单并取 20 条，20 个 primary shard（主分片）各自在局部候选中保留 20 条，协调节点最多接收约 400 个轻量候选，再归并为全局 20 条并执行 fetch phase（取回阶段）。若某分片因热点需要扫描 500 万候选并耗时 2 秒，其余 19 个分片各 80 毫秒，整体仍受 2 秒尾部拖累。若错误地把返回窗口扩大到 1 万，每分片可能返回 1 万候选，协调节点需处理约 20 万项。优化先用 routing（路由）、时间和状态过滤缩小分片及候选，再检查慢分片段数、缓存与磁盘，而不是只增加协调节点堆。

热门面试题

1. 问题（基础题）：为什么搜索要分 query phase（查询阶段）和 fetch phase（取回阶段）？
   • 考点：候选筛选与文档取回分离。
   • 回答思路：先传轻量排序信息，确定最终结果后再取正文。
   • 详细答案：分片先返回轻量候选，协调节点确定全局顺序后只取回最终命中文档，避免为所有局部候选搬运完整 _source，降低网络和读取放大。
   • 进阶追问：只返回标识是否可以省略取回阶段？
   • 进阶回答：若接口确实只需要可由查询阶段直接提供的标识与排序值，可减少正文取回；具体字段可用性仍需按查询设计核对。
2. 问题（原理题）：为什么最慢分片决定尾延迟？
   • 考点：分布式屏障与长尾。
   • 回答思路：协调节点要等目标分片结果才能完成全局排序。
   • 详细答案：全局 Top-K（最高 K 个结果）依赖所有目标分片候选，协调节点通常需要等待或按失败策略处理每个响应；任一热点、合并或磁盘抖动分片都会延长整体时间。
   • 进阶追问：副本能自动消除慢分片吗？
   • 进阶回答：副本增加选择机会但也可能共享节点或磁盘瓶颈，且副本恢复会加压；必须定位资源与数据倾斜。
3. 问题（场景题）：协调节点堆压力高怎样排查？
   • 考点：扇出、窗口、聚合与响应体。
   • 回答思路：按请求形状和并发量拆中间结果。
   • 详细答案：查看目标分片数、from 与 size、排序字段、聚合桶数、命中文档大小和并发请求；限制大窗口和大聚合，缩小路由与时间范围，并将低优先级导出隔离。
   • 进阶追问：增加专用协调节点是否足够？
   • 进阶回答：只能增加资源隔离，不能消除每请求的候选和桶放大；查询约束仍是根治手段。

4.2 from + size（偏移分页）、search_after（游标式分页）与 PIT（时间点视图）

from + size（偏移分页）要求每个目标 shard（分片）保留至少 from + size 个局部候选，协调节点再丢弃前 from 条；页越深，中间结果越大。search_after（游标式分页）携带上一页最后一条的完整排序值，从该位置继续，不需要为历史偏移重复保留全部候选，但要求稳定、唯一的排序组合。PIT（时间点视图）在分页期间固定一个一致搜索视图，避免 refresh（刷新）和 merge（合并）导致页面重复或漏项；它会延长旧 segment（分段）的保留和资源占用，生命周期、限制与故障行为必须现场核对。跳页、总命中精确计数与交互式游标之间应按业务取舍。

表 10：分页方案比较

sequenceDiagram
  participant C as 客户端
  participant O as 协调节点
  participant S as 二十个目标分片
  C->>O: from 100000 size 20
  O->>S: 每分片收集前 100020 个
  S-->>O: 最多约 2000400 个候选
  O-->>C: 丢弃前 100000 后返回 20 个
  C->>O: 创建时间点视图
  O-->>C: 返回视图标识
  C->>O: size 20 加上一页排序值
  O->>S: 在固定视图中继续
  S-->>O: 每分片返回下一页候选
  O-->>C: 返回 20 个与新排序游标
  alt 视图过期
    O--xC: 失败并要求按业务断点重启
  end

图 11 说明。 参与者是客户端、协调节点和 20 个目标分片；上半段展示深偏移在每分片放大候选，下半段展示 PIT（时间点视图）配合 search_after（游标式分页）的连续读取。前提是排序字段稳定且包含唯一决胜字段；正常路径按游标逐页前进；失败路径是视图过期后从业务断点重启。业务结论是深分页成本来自分布式候选保留，大导出应任务化而不是伪装成交互翻页。

数据演绎 9：深分页与游标式分页。 20 个 primary shard（主分片）执行 from=100000&size=20，每分片理论需保留前 100020 个候选，最坏向协调逻辑贡献约 20×100020=2000400 个候选，最终却只返回 20 条。若每个候选的文档标识、分数与排序值按教学估算 64 B（字节），仅候选信息就约 122 MB（兆字节），还未计对象开销和并发。改用 PIT（时间点视图）配合 search_after（游标式分页），每页只推进上一页最后的 (event_time,shipment_id) 排序值，候选窗口接近每分片 20 条。代价是不能任意跳到第 5001 页，并需控制时间点视图存活时间；异步导出应保存最后排序值、已写文件偏移和任务幂等键，视图失效后可从明确断点重启并做去重校验。

热门面试题

1. 问题（基础题）：from + size（偏移分页）为什么越深越慢？
   • 考点：每分片候选放大。
   • 回答思路：用偏移加页大小乘分片数回答。
   • 详细答案：分片不知道哪些候选会在全局归并后被丢弃，所以各自需保留至少偏移加页大小的局部结果；协调节点再合并并丢弃前项，深度和分片数共同放大内存与处理器成本。
   • 进阶追问：只把协调节点堆调大可以吗？
   • 进阶回答：会推迟故障但保留更大中间结果和暂停风险，根治应限制深页并改用游标或任务化导出。
2. 问题（原理题）：search_after（游标式分页）为何需要唯一排序？
   • 考点：稳定续读位置。
   • 回答思路：说明相同排序值无法确定边界。
   • 详细答案：若多条文档排序值完全相同，下一页无法唯一判断哪些已经返回，可能重复或漏项；应加入稳定且唯一的决胜字段，并在各页沿用完全相同的排序定义。
   • 进阶追问：只用时间戳排序有什么风险？
   • 进阶回答：同一毫秒可能有大量事件，必须再加运单标识或事件标识作为稳定决胜值。
3. 问题（场景题）：大批量导出如何断点续传？
   • 考点：视图、游标、文件与幂等。
   • 回答思路：保存查询快照语义和最后成功位置。
   • 详细答案：任务记录查询条件、PIT（时间点视图）标识、最后排序值、输出分片和校验摘要；每批原子更新断点。视图过期时按业务规则重建视图并用稳定键去重，完成后核对总数与抽样。
   • 进阶追问：导出期间能否一直保持同一视图？
   • 进阶回答：要受控评估存活时间和旧分段占用；超长任务应分区间处理并设计可验证重启，而不是无限续期。

4.3 doc values（列式值）、filter cache（过滤缓存）、request cache（请求缓存）与 aggregation（聚合）

doc values（列式值）通常为排序、aggregation（聚合）和脚本访问提供面向列的磁盘结构，避免把所有字段值长期放在 Java heap（Java 堆）对象中，但执行仍会消耗文件系统缓存、堆、直接内存与处理器。filter cache（过滤缓存）复用可缓存过滤结果，是否准入和淘汰属于版本敏感策略；request cache（请求缓存）复用满足条件的整个分片级请求结果，其资格、失效和默认行为必须现场核对。高 cardinality（基数）字段聚合会在各分片创建大量 bucket（桶）或中间状态，协调节点再归并；最终只展示前 10 项也不代表中间状态只有 10 项。circuit breaker（断路器）是风险限制器，不是容量规划替代品。

flowchart LR
  Q["aggregation 聚合请求"] --> F["filter 过滤候选"]
  F --> DV["doc values 列式值"]
  DV --> B0["分片零 bucket 桶"]
  DV --> B1["分片一 bucket 桶"]
  DV --> B19["分片十九 bucket 桶"]
  B0 --> C["协调节点归并"]
  B1 --> C
  B19 --> C
  FC["filter cache 过滤缓存"] --> F
  RC["request cache 请求缓存"] --> Q
  HC["千万级 shipment_id"] -.高基数.-> MEM["堆与断路器压力"]
  MEM -.拒绝或降级.-> Q

图 12 说明。 节点表示聚合请求、过滤、列式值、分片桶、协调归并和两类缓存；实线箭头是正常局部聚合与归并，虚线箭头是高基数触发内存压力和拒绝。前提是字段已正确建立 doc values（列式值）且请求具备可控范围；正常路径过滤后局部缩减；失败路径产生海量桶。业务结论是列式结构降低取值成本，却不能消除高基数中间状态。

数据演绎 10：高基数字段聚合。 对最近 30 天 1 亿条轨迹按 5000 万个 shipment_id 做 aggregation（聚合），20 个 primary shard（主分片）平均各遇到约 500 万个局部键。即使每个局部桶按教学估算只占 80 B（字节），单分片也约 381 MB（兆字节），20 分片理论中间状态可达数 GB（吉字节），协调节点还要归并重复键；最终返回前 10 个运单无法抵消这个过程。止血是缩小时间和租户范围、停止交互式全量聚合、限制并发并保护断路器；修复是按业务问题改为低基数维度、分页复合聚合、离线汇总或权威分析系统。回归查看每请求桶数、峰值内存、断路器拒绝、查询高分位与结果校验。

热门面试题

1. 问题（基础题）：doc values（列式值）主要服务什么？
   • 考点：排序、聚合与字段取值。
   • 回答思路：和全文倒排召回区分。
   • 详细答案：doc values（列式值）按字段组织值，主要供排序、aggregation（聚合）和脚本等列式访问；全文匹配仍主要依赖倒排结构。它减少某些堆内驻留，不代表查询零内存成本。
   • 进阶追问：text（全文字段）适合直接高基数聚合吗？
   • 进阶回答：通常应使用受控 keyword（精确字段）或专门维度，并验证基数与内存；不能为方便临时开启高风险字段加载。
2. 问题（原理题）：filter cache（过滤缓存）与 request cache（请求缓存）有什么差别？
   • 考点：结果粒度与失效边界。
   • 回答思路：一个复用过滤结果，一个复用分片级请求结果。
   • 详细答案：filter cache（过滤缓存）面向可复用过滤集合，request cache（请求缓存）面向满足资格的整个分片级请求结果；两者的准入、淘汰和刷新失效行为均需按现场版本核对。
   • 进阶追问：命中率低就应该扩大缓存吗？
   • 进阶回答：不一定。查询参数高离散时扩大只会挤占资源，应先识别稳定过滤、降低随机查询并观察文件系统缓存。
3. 问题（场景题）：高基数聚合触发断路器如何处理？
   • 考点：止血、查询改造与容量回归。
   • 回答思路：先拒绝危险请求，再减少中间状态。
   • 详细答案：立即限制该查询和并发，缩小时间、租户与维度；长期改为可分页聚合、预聚合或分析副本，并设置业务上限。不能简单提高断路器阈值把失败变成进程失稳。
   • 进阶追问：怎样证明修复有效？
   • 进阶回答：用同分布压测比较桶数、协调内存、拒绝率、文件系统缓存命中与结果准确性，并覆盖峰值并发。

5. 集群故障、生产排障与项目闭环

5.1 分片分配、磁盘水位、恢复限速与 cluster state（集群状态）压力

分片分配要同时满足节点可用、磁盘、分配规则、故障域与主副隔离等条件；某 node（节点）离线后，先判断 primary shard（主分片）是否仍有可提升副本，再决定是否创建新的 replica shard（副本分片）。恢复会复制 segment（分段）并追赶操作，过高并发可能形成 recovery storm（恢复风暴）。磁盘 watermarks（磁盘水位）用于限制分配、迁移或写入的具体阈值、计算口径与解除行为，属于版本和配置敏感事实，本文只登记核对卡；生产上应把合并临时空间、恢复复制、translog（事务日志）、快照缓存和前台增长同时纳入余量。大量分片、字段和频繁映射变更会放大 cluster state（集群状态）发布压力，集群管理节点堆与发布延迟必须独立观察。

表 11：red/yellow/green（红/黄/绿）与处置优先级

表 12：容量与恢复证据

sequenceDiagram
  participant M as 集群管理节点
  participant H as 健康主分片
  participant L as 离线节点
  participant N as 新副本节点
  L-xM: 节点失联
  M->>M: 判断主分片是否齐全
  M->>N: 分配副本恢复任务
  H->>N: 复制可复用分段
  H->>N: 追赶缺失操作
  N-->>M: 上报恢复进度与校验
  alt 前台延迟超过阈值
    M-->>N: 降低恢复并发与带宽
  else 恢复并校验完成
    M->>N: 加入同步集合并逐步承载查询
  end

图 13 说明。 参与者是集群管理节点、健康主分片、离线节点和新副本节点；箭头展示失联、分配、分段复制、缺口追赶和加入同步集合。前提是存在可信数据源且目标磁盘充足；正常路径完成校验后再承载查询；失败路径在前台延迟超阈值时限速。业务结论是恢复速度必须服从剩余健康容量，不能以牺牲在线服务换取表面绿色。

flowchart TB
  W["持续写入"] --> D["磁盘已用增长"]
  M["merge 合并临时空间"] --> D
  R["replica recovery 副本恢复"] --> D
  S["snapshot 快照缓存"] --> D
  D --> WM["watermarks 磁盘水位"]
  WM --> A["限制分配或迁移"]
  WM --> B["写入受限风险"]
  B -.重试放大.-> Q["线程池队列与超时"]
  Q -.继续写入.-> D
  STOP["暂停回填 导出和低优先级写"] --> REC["释放空间与受控恢复"]
  REC --> WM

图 14 说明。 节点表示前台写入、段合并、副本恢复、快照缓存、磁盘水位、分配限制和线程池重试；实线箭头是资源消耗到保护动作的正常因果，虚线箭头是超时重试继续放大的失败环。前提是水位与业务优先级已按现场配置核对；正常路径提前预警并保留临时空间；失败路径进入写拒绝和恢复风暴。业务结论是磁盘事故先停止新增放大源，再恢复空间和分片，不能只清理随机文件。

数据演绎 11：副本重建与恢复限速。 某 node（节点）故障后需在新节点重建 4 个各 100 GB（吉字节）的 replica shard（副本分片），总量约 400 GB（吉字节）。若健康源和目标盘可持续提供 200 MB/s（兆字节每秒），忽略协议、校验与前台竞争的纯传输下限约 400×1024/200=2048 秒，即约 34 分钟；实际还需复制许多 segment（分段）、追赶持续写入并校验，可能超过 1 小时。若同时开 8 路恢复把磁盘打到 95% 忙碌，搜索高分位从 300 毫秒升到 4 秒，恢复反而拖累业务。应把前台延迟、写拒绝和恢复完成时间作为联合约束，限速后分批加入查询，并抽样核对运单版本和段校验。

数据演绎 12：磁盘水位与写入拒绝。 5 个数据 node（节点）各有 4 TB（太字节）磁盘，节点 D 已用 3.6 TB（太字节），剩余约 400 GB（吉字节）。待合并 100 个小 segment（分段）合计 300 GB（吉字节），预计写出 240 GB（吉字节）新段；一个副本恢复还需 180 GB（吉字节），异步日志回填每小时新增 60 GB（吉字节），并发峰值已超过余量。现场 watermarks（磁盘水位）可能触发迁移或写入保护，客户端出现超时和拒绝后若无界重试，会进一步堆满线程池。止血暂停回填、批量导出和非关键索引，限制重试并扩容；修复生命周期、分片分布和容量预算。回归要求可用空间覆盖最大合并、恢复与增长并发窗口，写拒绝归零且分片不再往返迁移。

热门面试题

1. 问题（基础题）：red（红色）与 yellow（黄色）最核心的区别是什么？
   • 考点：主分片可达性与副本冗余。
   • 回答思路：先看是否有未分配主分片。
   • 详细答案：通常 red（红色）表示至少有主分片未分配，相关数据不可完整访问；yellow（黄色）表示主分片可用但部分副本未分配，仍可服务却处于冗余下降窗口。精确范围需按目标索引核对。
   • 进阶追问：集群红色是否应该立刻创建空主分片？
   • 进阶回答：不能盲目操作。先确认可用副本、节点、快照和数据损失风险，任何接受数据丢失的动作都需审批与校验。
2. 问题（原理题）：为什么磁盘高水位会形成连锁故障？
   • 考点：合并、恢复、分配与重试耦合。
   • 回答思路：从临时空间不足到写拒绝和重试放大回答。
   • 详细答案：空间不足会阻碍合并和副本恢复，段数与未分配分片继续增加；写入被限制后客户端重试堆积，查询又因小段和缓存抖动变慢，最终形成资源正反馈。
   • 进阶追问：可以直接删除 segment（分段）文件止血吗？
   • 进阶回答：不可以，绕过引擎删除会破坏分片一致性；应暂停放大源、按受支持生命周期清理或扩容，并保留恢复证据。
3. 问题（场景题）：恢复风暴怎样控制？
   • 考点：限速、优先级和回归。
   • 回答思路：先保可用主分片与关键查询，再分批恢复。
   • 详细答案：限制并发恢复和带宽，暂停低优先级回填与大聚合，按业务重要性恢复分片；持续观察前台高分位、磁盘队列、网络和恢复水位，完成校验后逐步增加读流量。
   • 进阶追问：什么时候可以解除限速？
   • 进阶回答：健康节点有明确余量、前台指标稳定、恢复不会触及磁盘保护且故障目标仍可满足时灰度解除。

5.2 线上排障、设计思想、项目投影闭环与版本核对卡

线上排障遵循“业务影响与时间线 -> 请求与线程池 -> 分片与段 -> 堆、断路器与文件系统缓存 -> 磁盘网络 -> 权威源校验”的证据链。write rejection（写入拒绝）既可能来自线程池队列，也可能是磁盘保护、主分片不可用或映射压力的结果；slow query（慢查询）既可能来自深分页、高基数 aggregation（聚合）和热点分片，也可能来自小段、merge（合并）、恢复和文件系统缓存被驱逐。每个事故必须至少保留一类集群证据和一类主机证据，再给出止血、根因修复和同分布回归。设计上，倒排索引用写放大换召回，不可变 segment（分段）用后台合并换并发读写，refresh（刷新）用可见延迟换吞吐，shard（分片）用固定成本换容量和并行；这些取舍共同说明索引应是可重建投影，而不是交易权威源。

表 13：生产故障五段式排障矩阵

表 14：项目投影与版本核对卡

sequenceDiagram
  participant DB as 权威数据库或事件日志
  participant E as 事件通道
  participant P as 幂等投影消费者
  participant ES as 搜索索引
  participant V as 校验与重建任务
  DB->>E: 提交业务键 版本 删除语义
  E->>P: 至少一次投递
  P->>ES: 按业务版本条件更新
  ES-->>P: 成功 冲突或未知结果
  P->>P: 查证并保存断点
  V->>DB: 读取权威水位与摘要
  V->>ES: 比较版本 数量 删除与查询
  alt 发现缺口
    V->>E: 回放缺失区间
  else 需要全量重建
    V->>ES: 新建索引 全量导入 增量追平
    V->>ES: 校验后切换别名 保留回滚窗口
  end

图 15 说明。 参与者是权威源、事件通道、幂等消费者、搜索索引和校验重建任务；箭头覆盖正常投影、未知结果查证、水位校验、缺口回放和全量重建。前提是业务键、版本、删除和断点都可持久记录；正常路径增量收敛；失败路径从事件回放或新索引重建。业务结论是能重建不等于随时重建，必须预先具备事件保留、容量、校验与回滚窗口。

flowchart TB
  A["业务影响与时间线"] --> B["请求 线程池 队列 拒绝"]
  B --> C["routing 路由 shard 分片 segment 分段"]
  C --> D["heap 堆 断路器 文件系统缓存"]
  D --> E["磁盘 网络 恢复与合并"]
  E --> F["权威源 水位 删除与抽样校验"]
  X["库存或任务裁决受影响"] -.立即回源与限流.-> A
  Y["磁盘水位或恢复风暴"] -.暂停放大源.-> E
  Z["修复后结果不一致"] -.回放或重建.-> F
  F --> R["同分布压测 故障演练 业务签收"]

图 16 说明。 节点表示从业务影响到请求、分片、内存、存储、权威校验和回归签收的排障层次；实线箭头是逐层收敛证据，虚线箭头是交易风险、磁盘风险与结果差异的止血路径。前提是请求标识、业务键和时间线可关联；正常路径用两类证据定位后回归；失败路径优先回源、限流、暂停放大源或重建。业务结论是先保权威事实和恢复能力，再恢复搜索吞吐，最后由业务校验签收。

图 17 说明。 PlantUML（开源建模工具）源文件的参与者包括业务客户端、协调节点、主分片、内存缓冲与 translog（事务日志）、副本、Lucene（全文检索库）segment（分段）、集群管理节点、查询协调节点和其他目标分片；箭头在同一正式时序中串联写入确认、refresh（刷新）可见、query phase（查询阶段）扇出、Top-K（最高 K 个结果）归并、fetch phase（取回阶段）、主分片提升、旧主拒写与副本恢复。前提是路由、任期和配置已现场核对；正常路径从确认到可见再到查询；失败路径在旧主恢复和资源恢复处受控。业务结论是搜索生命周期有多个独立确认点，任何一个都不能替代权威业务提交和独立 snapshot（快照）。

项目口述模板。 “在跨境物流、WMS（仓储管理系统）、IoT（物联网）报警和异步任务项目中，我把 Elasticsearch（搜索引擎）定位为可重建读模型。权威数据库或事件日志先提交业务事实，事件携带稳定键、版本、删除语义和来源水位；消费者按版本幂等更新，超时先查证，积压从断点续传。查询端按运单号或商品键优化局部路由，复杂全文搜索留在索引，库存提交、任务领取和告警裁决始终回权威源。我们持续比较水位、数量、删除、关键聚合和抽样详情；差异可按区间回放，严重故障可新建索引、全量导入、增量追平、校验并切换别名。索引不可用时精确键限流回源，复杂搜索降级，避免搜索故障反向拖垮交易。”

热门面试题

1. 问题（基础题）：为什么说倒排索引用写放大换查询召回？
   • 考点：预计算结构与资源成本。
   • 回答思路：从一个字段写出多种搜索结构回答。
   • 详细答案：文档写入时要分词并建立词项、文档关联、位置、列式值和多字段等结构，副本与 merge（合并）还会重复处理；这些预付成本使查询能快速召回和过滤，而不是扫描全部原文。
   • 进阶追问：写放大是否越高查询越快？
   • 进阶回答：不是。无用多字段和索引只增加写入与磁盘，查询收益必须由真实召回、排序和聚合需求证明。
2. 问题（原理题）：不可变 segment（分段）和 refresh（刷新）体现什么设计取舍？
   • 考点：并发读写、可见延迟与吞吐。
   • 回答思路：说明新段发布和后台整理。
   • 详细答案：不可变分段让并发搜索读取稳定视图，新写通过新段发布，后台再合并；refresh（刷新）越频繁可见越快但小段越多、吞吐越低，因此要用业务新鲜度换取资源效率。
   • 进阶追问：搜索索引为何不适合做交易权威源？
   • 进阶回答：这些机制优化检索可见与恢复，不表达库存、资金、租约等跨记录业务不变量；索引应由权威事实投影并可删除重建。
3. 问题（场景题）：如何完整讲一次搜索索引重建？
   • 考点：全量、增量、校验、切换与回滚。
   • 回答思路：从冻结映射到业务签收按状态机回答。
   • 详细答案：先冻结字段和业务版本语义，记录事件起始水位；新建索引并全量导入，再从水位幂等追增量，比较文档数、删除、版本、聚合和关键查询；影子读通过后灰度切换别名，保留旧索引与回滚窗口，最后做快照和恢复验证。
   • 进阶追问：重建完成只看文档数够吗？
   • 进阶回答：不够，还要校验业务版本、删除传播、关键字段、查询排序、聚合与事件水位，并覆盖重试未知结果。

题库边界

本节只用于结束上一知识节的题目扫描范围；以下综合题不计入 13 个知识型三级标题与 39 道章节六字段题。

6. 综合口述题库

1. 问题：请从逻辑到物理完整解释 Elasticsearch（搜索引擎）的索引、分片、副本与分段。

   • 口述答案：我会先把 Elasticsearch（搜索引擎）分成逻辑入口、分布式执行和单分片存储三层。cluster（集群）由多个 node（节点）组成，cluster state（集群状态）保存 index（索引）元数据、mapping（映射）、routing（路由）表和分片分配。业务看到的 index（索引）不是一个大文件，它在创建时确定 primary shard（主分片）数量，每个主分片可以配置 replica shard（副本分片）；document（文档）经过 routing（路由）只进入一个主分片，再复制到对应副本。每个 shard（分片）本质上是独立 Lucene（全文检索库）索引，内部由不可变 segment（分段）、提交点和 translog（事务日志）恢复边界共同支撑读写。segment（分段）不可变使搜索线程能稳定读取旧视图，新写先进入内存缓冲，refresh（刷新）后发布新分段，后台 merge（合并）再减少段数并回收删除。以 20 个主分片、1 个副本为例，共有 40 个分片副本；如果主数据 2 TB（太字节），平均主分片约 100 GB（吉字节），还要另算副本、日志、合并临时空间和快照。主分片数影响路由空间、写查并行、单次恢复颗粒度和未来重建成本，分片过多会增加固定开销、协调扇出和小段，过少会限制扩展与恢复并行。最后我会强调副本解决在线冗余和读扩展，snapshot（快照）解决独立恢复点，cluster health（集群健康）只描述分片分配，三者都不能证明业务内容正确。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
   • 追问：增加 node（节点）会自动增加主分片吗？
   • 直接回答：不会，只会重新分配既有分片，主分片数量与路由空间不会凭扩容自动改变。
   • 追问：副本与主分片是否保存不同数据？
   • 直接回答：对应副本保存同一分片的数据历史，用于冗余、读取和故障提升，不是业务分片扩容。
   • 追问：segment（分段）为何不能当业务记录理解？
   • 直接回答：它是大量文档的不可变搜索结构集合，一个文档还可能因更新在新旧分段间经历删除与重建。
   • 详情：逻辑到物理模型

2. 问题：主分片数和 routing（路由）应如何设计，为什么它会影响未来迁移？

   • 口述答案：routing（路由）的本质是用稳定路由值把 document（文档）映射到一个 primary shard（主分片），所以我会同时评估数据分布和查询局部性。跨境物流按运单号路由时，同一运单的轨迹进入同一分片，客服按相同 routing（路由）查询只访问一个分片；不带路由则要向全部目标分片扇出。假设 1 亿条轨迹、1000 万个运单、20 个主分片，平均每分片约 500 万条，但平均数不能掩盖热点。如果错误地用一个“总运单号”承载 5000 万条扫描事件，该键会把一半数据压到单分片，写入、段数、合并、磁盘和查询都倾斜。主分片数还参与文档归属空间，一旦需要改变，不能简单加 node（节点）完成；通常要新建 index（索引），用权威库或事件日志全量导入，再从断点追增量，校验版本、删除、数量和查询后切换别名。分片太大使恢复和搬运时间长，分片太多使元数据、调度、协调和小段成本上升。大租户治理不能随机路由，因为随机会破坏幂等定位和局部查询；可采用租户加确定性桶，但必须保存桶规则、查询桶集合和历史重建方案。我的结论是路由用查询局部性换均衡和变更灵活性，设计时要同时给出热点证据、扩容上限、重建时间与退出路径。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
   • 追问：写入用了显式 routing（路由），更新能省略吗？
   • 直接回答：不能，更新、删除和点查都应携带相同路由，否则可能定位到另一分片而漏读或重复写。
   • 追问：租户标识作为路由键的最大风险是什么？
   • 直接回答：大租户全部集中到单分片，平均均衡但尾部租户形成热点。
   • 追问：怎样验证路由设计？
   • 直接回答：比较分片文档数、写入率、段数、磁盘、热点键占比、带路由与不带路由的查询扇出和高分位延迟。
   • 详情：路由与迁移成本

3. 问题：一次写入从协调节点到确认返回经历什么，确认成功到底代表什么？

   • 口述答案：客户端可把请求发到任意可处理请求的 node（节点），该节点作为 coordinating node（协调节点）解析 index（索引）和 routing（路由），根据 cluster state（集群状态）定位目标 primary shard（主分片）。主分片完成 mapping（映射）与并发条件校验，分配 seq_no（序列号），把变更加入 in-memory indexing buffer（内存索引缓冲）并追加 translog（事务日志），再把同一操作复制给当前同步集合中的 replica shard（副本分片）。满足现场版本和配置定义的确认条件后，结果经协调节点返回客户端。这里必须拆开四个边界：第一，写入确认说明请求达到配置的主副分片处理边界；第二，translog（事务日志）刷盘策略决定崩溃恢复窗口，不能凭记忆假定每次成功都已在所有磁盘同步；第三，文档要等 refresh（刷新）打开新 segment（分段）后才对后续搜索可见；第四，搜索写入成功不证明业务数据库已经提交，因为搜索只是权威事件的派生投影。若副本或网络超时，结果可能未知，主分片可能已处理，只是响应丢失。消费者应使用稳定文档标识和业务版本查证后重试，绝不能换随机标识重复插入。生产监控也应分别观察写入拒绝、事务日志、刷新延迟、未分配副本和事件水位，而不是用一个成功率代表整条一致性链路。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
   • 追问：协调节点会分配 seq_no（序列号）吗？
   • 直接回答：不会，协调节点负责路由与汇总，当前主分片负责排序并分配序列号。
   • 追问：写入成功后立即搜索查不到是否矛盾？
   • 直接回答：不矛盾，写入确认可能早于下一次 refresh（刷新），确认和搜索可见是不同边界。
   • 追问：副本确认是否等于 snapshot（快照）完成？
   • 直接回答：不等于，副本是在线冗余，快照是独立恢复点并需恢复演练验证。
   • 详情：写入确认链路

4. 问题：怎样严格区分 refresh（刷新）、flush（冲刷）和 merge（合并）？

   • 口述答案：我会按“搜索可见、崩溃恢复、存储整理”三个目标回答。refresh（刷新）把内存索引缓冲中的内容形成新 segment（分段）并打开新的搜索视图，所以它主要决定近实时可见延迟；写入已经确认但尚未刷新时，点查与搜索的观察可能不同，不能把刷新叫作业务提交。flush（冲刷）建立 Lucene（全文检索库）提交点并滚动 translog（事务日志）代际，主要服务恢复边界，不是为了让查询更快。merge（合并）读取多个不可变 segment（分段），过滤可回收删除并写出更大新段，提交后再释放旧段，目的是减少段数和读放大，但会产生处理器、磁盘输入输出和临时空间成本。以每秒 2 万条日志、10 个主分片、1 秒刷新为教学例，10 秒可能形成约 100 个小段；若每段 80 MB（兆字节），一次合并需要读取约 8 GB（吉字节）并写出约 6 GB（吉字节）新段，旧段在提交前仍占空间。拉长刷新间隔能提高吞吐并减少小段，却增加搜索新鲜度延迟；提高合并并发可能与前台查询和副本恢复抢磁盘。正确做法是根据业务新鲜度分层、聚批写入、保证临时空间，并联合回归可见延迟、段数、合并字节、写吞吐和查询尾延迟。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
   • 追问：refresh（刷新）后数据就一定持久安全吗？
   • 直接回答：不能这样推断，刷新主要发布搜索视图，持久化还要看事务日志策略与提交点。
   • 追问：merge（合并）能否消除更新写放大？
   • 直接回答：不能，它只是后台整理旧段与删除，过程本身还会再次读写数据。
   • 追问：小段过多第一步做什么？
   • 直接回答：先降低新增小段速度，检查批次和刷新频率，再给合并留足磁盘与输入输出资源。
   • 详情：刷新、冲刷与合并

5. 问题：为什么 Elasticsearch（搜索引擎）更新和多字段设计会产生明显写放大？

   • 口述答案：Elasticsearch（搜索引擎）的读取速度来自写入时预建多种结构。text（全文字段）要分词并建立倒排词项、文档关联，按配置还可能保存词频和位置；keyword（精确字段）通常服务精确过滤、排序和 aggregation（聚合），常伴随 doc values（列式值）；multi-field（多字段）会为同一原始值再建一套或多套结构；nested（嵌套字段）为保持对象数组内部关联，可能展开成额外隐藏文档。Lucene（全文检索库）segment（分段）不可变，更新一个价格字段通常不是原地改 8 B（字节），而是把旧文档标为删除并重新索引完整新文档，后续 merge（合并）再回收旧版本。假设 WMS（仓储管理系统）商品索引有 1000 万个 2 KB（千字节）文档，仅原文全量重建就约 20 GB（吉字节）；1 个副本使基础写入至少复制两份，20 个过滤字段、商品名双字段、5 项嵌套数组、旧文档删除和段合并会继续把实际输入输出推高。动态 mapping（映射）若把任意属性键变成字段，还会造成字段爆炸和 cluster state（集群状态）压力。设计时我会从查询日志反推必要字段，把高频变化但不参与检索的值留在权威库或独立小文档；全量变化使用新索引、断点回放、校验与别名切换，不在原索引上制造巨量删除垃圾。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
   • 追问：所有字符串都建立 text（全文字段）和 keyword（精确字段）是否方便？
   • 直接回答：方便但代价高，只有同时存在全文召回与精确查询价值时才应建立多字段。
   • 追问：nested（嵌套字段）为什么更贵？
   • 直接回答：它可能把一个业务文档展开为父文档和多个隐藏文档，更新父对象会放大底层文档重建。
   • 追问：1000 万文档更新如何降低风险？
   • 直接回答：新建索引分批导入，记录事件断点，增量追平并校验后切别名，保留旧索引作为回滚窗口。
   • 详情：映射与写放大

6. 问题：seq_no（序列号）、primary_term（主分片任期）与乐观并发怎样共同工作？

   • 口述答案：seq_no（序列号）表示一个 shard（分片）内由当前写入历史分配的操作顺序，primary_term（主分片任期）表示主分片代际；主分片故障提升时任期推进，使旧主代际与新主代际可区分。客户端读取 document（文档）时拿到这组并发坐标，更新时声明“只有当前序列号和任期仍等于我读到的值才允许写”，这就是 optimistic concurrency control（乐观并发控制）的核心。两个客服同时读取运单版本，甲先把状态改为运输中并成功，序列号推进；乙仍拿旧坐标把状态改为已揽收时会冲突，而不是无声覆盖甲。乙应重新读取权威业务状态，根据状态机决定合并、拒绝或重试。这里要避免两个扩大解释：第一，序列号和任期保护的是单文档索引并发，不提供跨多个文档的交易事务；第二，它们是搜索分片内部坐标，不能替代跨数据库、事件通道和搜索索引都能理解的业务版本。物流轨迹、库存、报警和任务投影仍需在事件中携带业务键、版本与来源水位。发生主分片切换后，旧主恢复必须接受新 cluster state（集群状态），旧任期写入被拒绝，防止两条历史继续分叉。回归应同时覆盖同版本竞争、故障切换、乱序事件和冲突后的领域处理。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
   • 追问：乐观并发冲突是否说明系统错误？
   • 直接回答：不一定，它常是并发竞争被正确暴露，关键是按领域规则处理而不是覆盖。
   • 追问：能否对冲突无限自动重试？
   • 直接回答：不能，只有更新函数可安全重算时才受控重试，状态机冲突应回源或人工处理。
   • 追问：业务版本为什么仍然需要？
   • 直接回答：搜索内部坐标不能表达跨系统事件顺序、删除和重放，业务版本才是异构投影的共同语言。
   • 详情：序列号、任期与乐观并发

7. 问题：写入超时形成未知结果时，怎样设计可证明的重试？

   • 口述答案：超时只说明客户端没有在期限内拿到确定响应，不能推断服务端没有执行。请求可能尚未到 primary shard（主分片），也可能主分片已分配 seq_no（序列号）、追加 translog（事务日志）并复制成功，只是响应在网络中丢失，还可能恰逢主分片切换，新主已经保留该操作。我的重试设计有三层。第一层是稳定 document（文档）标识和业务幂等键，同一运单版本或任务尝试永远定位同一键，禁止用随机新标识重试。第二层是业务版本比较，例如事件 88 更新运单 S9001，超时后读取当前投影：已是 88 表示原请求成功，仍是 87 才用相同语义重试，已是 89 则拒绝旧事件并记录乱序。第三层是持久化重试状态，消费者保存事件分区、水位、尝试次数和最后错误，查询也超时时进入退避队列，而不是丢弃。对库存扣减、支付通知、任务执行等外部副作用，幂等必须在权威系统独立完成，搜索索引的文档幂等不能保护真实扣款或发货。监控上把网络超时、最终查证成功、真正失败、版本冲突和重复副作用分开统计。故障演练要主动注入响应丢失、主分片提升和重复投递，验证最终只有一个业务版本、断点可继续、旧事件不会覆盖新事件。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
   • 追问：为什么随机标识重试最危险？
   • 直接回答：它把一次不确定操作变成多份确定重复文档，后续聚合、删除和对账都被污染。
   • 追问：查到版本 89 时如何处理事件 88？
   • 直接回答：按业务顺序规则拒绝或归档旧事件，不能把较新投影回退到 88。
   • 追问：搜索幂等是否能保护外部通知？
   • 直接回答：不能，通知、扣款和任务副作用必须在其权威执行边界使用独立幂等键和结果记录。
   • 详情：未知结果数据演绎

8. 问题：主分片失联、提升、旧主恢复和副本补建的完整流程是什么？

   • 口述答案：节点失联后，集群管理路径先根据可用分片副本和已知同步状态判断是否存在可提升的 replica shard（副本分片），然后发布新的 cluster state（集群状态），把候选提升为 primary shard（主分片）并推进 primary_term（主分片任期）。新任期建立唯一有效写入代际，客户端在路由刷新后向新主写入。旧主所在 node（节点）恢复时不能凭本地旧状态继续服务，它必须接受新集群状态；携带旧任期的写入会被拒绝，从而避免网络分区后两条历史并行。在线服务恢复后还没有结束，集群需要在合适节点创建新的副本目标，从健康主分片复用或复制 segment（分段），再追赶缺失操作，校验完成后加入同步集合并逐步承载查询。假设 10 个节点、20 个主分片和 20 个副本，单节点离线影响 4 个分片副本；若需重建 4 个各 100 GB（吉字节）的副本，总搬运约 400 GB（吉字节）。恢复并发过高会打满磁盘、网络并驱逐文件系统缓存，因此要用前台高分位、写拒绝和恢复目标联合限速。cluster health（集群健康）从 yellow（黄色）恢复到 green（绿色）只说明分片分配恢复，还要核对任期、同步水位、业务版本、删除和查询。副本补齐也不替代 snapshot（快照），因为错误删除会同时传播到主副分片。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
   • 追问：旧主恢复后为什么不能直接参与写入？
   • 直接回答：它属于旧任期，继续写会制造分叉历史，必须先接受新集群状态并按新角色恢复。
   • 追问：什么时候先恢复服务，什么时候先补副本？
   • 直接回答：先确保有效主分片和唯一写入代际，再在保护前台的条件下补冗余。
   • 追问：绿色后还要验证什么？
   • 直接回答：验证业务水位、版本、删除、关键查询、前台延迟与独立快照恢复能力。
   • 详情：主分片切换与恢复

9. 问题：如何区分副本确认、cluster health（集群健康）和 snapshot（快照）的保护边界？

   • 口述答案：这三个概念分别回答一次写入、当前在线拓扑和历史恢复点的问题。副本确认关注某次写入是否达到现场配置定义的主副分片处理条件，具体等待哪些副本、translog（事务日志）何时刷盘必须按版本与配置核对；它不说明搜索已经 refresh（刷新），也不说明权威业务事务提交。cluster health（集群健康）关注分片分配，通常 green（绿色）表示主副分片齐全，yellow（黄色）表示主分片可用但部分副本未分配，red（红色）表示存在未分配主分片。它不会检查运单版本是否漏投、映射是否写错、删除是否传播或消费者水位是否追平。snapshot（快照）保存可用于独立恢复的索引与元数据范围，保护误删、集群级损坏和历史回退，但快照有时间边界、仓库权限、分片稳定性和恢复兼容问题，任务显示成功仍要在隔离环境恢复并执行业务查询验证。副本会实时接收错误删除和错误映射，所以不能替代快照；快照恢复通常也不能替代副本的在线快速提升。生产验收我会建立三套证据：写入侧记录确认与未知结果查证，集群侧记录分片和未分配原因，灾备侧记录快照标识、恢复时间、文档与聚合校验。再叠加权威源与索引的事件水位和版本校验，才能分别证明在线可用、可恢复和业务收敛。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
   • 追问：集群绿色能否证明没有丢文档？
   • 直接回答：不能，它只证明目标主副分片已分配，内容正确性要靠权威水位、版本、删除与抽样校验。
   • 追问：每日快照能否取消副本？
   • 直接回答：不能，快照恢复时间通常远高于在线副本提升，两者承担不同恢复目标。
   • 追问：快照成功最关键的后续动作是什么？
   • 直接回答：在独立环境恢复，核对范围、权限、耗时、文档数、关键聚合和业务查询。
   • 详情：副本与快照边界

10. 问题：一次分布式搜索的 query phase（查询阶段）和 fetch phase（取回阶段）如何执行？

• 口述答案：没有有效 routing（路由）时，coordinating node（协调节点）要把请求扇出到每个目标 shard（分片）的一个可用副本。query phase（查询阶段）在各分片本地执行倒排匹配、过滤、评分或排序，并保留局部 Top-K（最高 K 个结果），返回的通常是文档标识、分数和排序值等轻量候选，而不是所有完整文档。协调节点等待目标分片响应，把局部候选做全局归并，得到最终窗口后再进入 fetch phase（取回阶段），按文档实际所在分片取回 _source 等内容，组装后返回客户端。这样可以避免为大量未进入全局结果的候选搬运正文，但不能消除局部扫描和排序成本。以 20 个主分片、size=20 为例，每分片保留 20 个局部候选，协调节点最多先处理约 400 个候选，再取回最终 20 个文档。若某一热点分片扫描 500 万候选耗时 2 秒，其余分片只需 80 毫秒，整体仍被慢分片拖住；如果窗口增至 1 万，中间候选约 20 万项，协调内存显著增加。优化顺序是先用 routing（路由）、时间、租户和状态过滤减少目标分片与候选，再查热点分片的段数、合并、文件系统缓存和磁盘，最后才考虑增加协调资源。最终返回少量结果不代表执行过程便宜。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：为什么查询阶段不直接返回完整文档？
• 直接回答：先用轻量候选完成全局排序，只取回最终命中文档，可以显著减少网络和正文读取。
• 追问：最慢分片为何影响整个请求？
• 直接回答：全局排序需要目标分片候选，协调节点通常要等待或按失败策略处理该分片响应。
• 追问：副本越多查询一定越快吗？
• 直接回答：不一定，副本提供选择与并发能力，但共享资源、恢复负载和数据热点仍会造成长尾。
• 详情：查询两阶段

11. 问题：请用具体数字解释 from + size（偏移分页）为什么不适合深分页。

• 口述答案：from + size（偏移分页）的分布式代价不是最终返回条数，而是每个目标 shard（分片）都要为全局归并准备足够深的局部候选。查询 from=100000&size=20 时，每分片理论上需要保留前 100020 个候选，因为它不知道哪些文档会在其他分片参与全局排序后落到前 100000。20 个主分片最坏产生约 20×100020=2000400 个候选，协调节点归并后丢弃前 100000 条，最终只返回 20 条。按教学估算，每个候选的文档标识、分数和排序值占 64 B（字节），候选信息已约 122 MB（兆字节），实际对象、优先队列、网络、并发请求与 fetch phase（取回阶段）还会继续放大。深页同时让每个分片执行更大的局部排序，任何热点或慢分片都会拉长高分位。简单增加协调节点 Java heap（Java 堆）只会推迟断路器或垃圾回收风险，不能减少中间结果。产品设计上应限制交互式可跳页范围，普通连续翻页改用 search_after（游标式分页）；需要稳定遍历时配合 PIT（时间点视图）；需要百万级导出时改成异步任务，保存查询条件、最后排序值、输出偏移、校验摘要和幂等键。这样把随机跳页、连续浏览与大批处理分成不同服务目标，不让一个分页参数变成集群级内存事故。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：为什么每分片不能只返回 20 条？
• 直接回答：全局第 100001 至 100020 条可能来自任意分片，本地必须保留偏移范围才能参与正确归并。
• 追问：设置最大结果窗口解决了什么？
• 直接回答：它限制单请求的候选放大风险，但业务仍需选择游标、异步导出或受限跳页方案。
• 追问：深分页事故第一步怎么止血？
• 直接回答：限制大偏移请求与并发，暂停低优先级导出，保护协调节点和数据节点，再改造查询接口。
• 详情：偏移分页与游标

12. 问题：search_after（游标式分页）与 PIT（时间点视图）如何配合，边界是什么？

• 口述答案：search_after（游标式分页）不是记录“第几页”，而是携带上一页最后一条文档的完整排序值，让各 shard（分片）从该位置继续寻找下一批候选。因此排序必须稳定，并包含唯一决胜字段。例如跨境轨迹按 (event_time,shipment_id) 排序，只用毫秒时间戳会因同一毫秒多条事件无法确定边界，导致重复或漏项。单独使用 search_after（游标式分页）时，分页之间发生 refresh（刷新）、更新和删除，搜索视图会变化；PIT（时间点视图）用于把一段遍历固定在相对一致的搜索视图中，减少页间漂移。客户端创建 PIT（时间点视图），每页携带视图标识、相同查询、相同排序和上一页最后排序值，处理成功后持久化业务断点。代价是 PIT（时间点视图）需要保留相关旧 segment（分段），会增加文件句柄、磁盘和合并回收压力，存活时间、上限与故障行为必须现场核对。它也不天然支持随机跳到第 5001 页。超长异步导出应按时间或租户切片，记录输出文件偏移、已完成区间和摘要；视图过期后根据稳定键重启，并对边界做去重和总量校验。这个方案优化的是连续遍历的中间结果，不替代业务权威快照，也不能让不断变化的搜索索引承担交易审计。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：为什么排序值必须包含唯一决胜字段？
• 直接回答：相同排序值无法唯一标识上一页边界，下一页会出现重复或漏项。
• 追问：PIT（时间点视图）可以无限续期吗？
• 直接回答：不应这样设计，长时间保留旧分段会占用资源，具体限制还需现场版本核对。
• 追问：视图过期后如何继续导出？
• 直接回答：用持久化业务断点和稳定排序键重建视图，从已确认位置继续并对边界去重校验。
• 详情：游标与时间点视图

13. 问题：doc values（列式值）、filter cache（过滤缓存）和 request cache（请求缓存）分别解决什么？

• 口述答案：doc values（列式值）是字段值的面向列磁盘结构，常用于排序、aggregation（聚合）和脚本访问，与用于全文召回的倒排结构责任不同。它能避免把全部字段值以大量 Java heap（Java 堆）对象长期驻留，但查询仍会消耗文件系统缓存、直接内存、处理器和协调内存，所以不能把“有列式值”理解为聚合免费。filter cache（过滤缓存）复用满足资格的过滤结果，例如稳定状态或权限过滤的分片级集合；request cache（请求缓存）复用满足条件的整个分片级请求结果。两类缓存的准入、淘汰、刷新失效和默认行为会随版本、配置与请求形状变化，本文统一要求现场核对，而不背固定默认值。排障时，缓存命中率低不一定意味着内存太小，可能是时间参数每次变化、租户条件高度离散或请求本身不具备复用价值；盲目扩大缓存会挤压 Java heap（Java 堆）或文件系统缓存。设计上先把稳定过滤放入非评分上下文，限制随机高离散查询，再观察命中、淘汰、磁盘读取和查询高分位。对排序与聚合字段，要确认 mapping（映射）和 doc values（列式值）设计正确；对 text（全文字段）不能为了临时聚合而开启高风险字段加载。最后用同分布压测验证缓存热身、刷新后的失效、节点重启和峰值并发，而不是只看一次热缓存查询。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：doc values（列式值）是否完全不占内存？
• 直接回答：不是，数据主要以列式结构落盘，但读取、桶状态、文件系统缓存和协调归并都消耗资源。
• 追问：缓存命中率低就应扩大缓存吗？
• 直接回答：不一定，先判断请求是否可复用，高离散参数扩大缓存只会增加淘汰和资源竞争。
• 追问：全文评分依赖 doc values（列式值）吗？
• 直接回答：主要依赖倒排索引与相关性结构，列式值更常服务排序、聚合和脚本取值。
• 详情：列式值与缓存

14. 问题：高 cardinality（基数）字段聚合为什么会压垮协调节点，怎样治理？

• 口述答案：高 cardinality（基数）聚合的危险在于中间 bucket（桶）数量，而不是最终展示条数。对最近 30 天 1 亿条轨迹按 5000 万个 shipment_id 做 aggregation（聚合），20 个主分片平均可能各遇到约 500 万个局部键。即使教学估算每个桶只占 80 B（字节），单分片也约 381 MB（兆字节），整个请求的局部中间状态可达数 GB（吉字节），协调节点还要归并跨分片重复键、维护排序并生成响应。最终只返回前 10 个运单并不能跳过这些局部建桶。doc values（列式值）降低字段值读取成本，但不消除桶对象、哈希结构、网络和归并成本；circuit breaker（断路器）只能在估算超限时拒绝请求，不能代替容量规划。事故止血先停止该聚合、限制并发和查询范围，保护其他搜索；修复要回到业务问题，若只是查单个运单就按精确键查询，若需要大规模唯一运单统计就放到分析副本、离线汇总或使用可分页复合聚合，并按租户和时间切分。还要设置业务可接受的最大桶数、超时和导出任务配额。回归使用真实基数与倾斜数据，记录每分片桶数、协调内存、断路器、网络、高分位和结果校验，不能用低基数测试集证明方案安全。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：把返回大小设为 10 能解决高基数吗？
• 直接回答：不能，分片仍可能先构建大量局部桶，返回大小只限制最终结果的一部分。
• 追问：提高断路器阈值是否可行？
• 直接回答：通常只会把可控拒绝推迟成进程失稳，必须先减少桶数量和并发。
• 追问：什么场景应改用分析系统？
• 直接回答：需要扫描长时间、大数据量并按千万级高基数维度统计时，应使用专用分析副本或预聚合。
• 详情：高基数聚合

15. 问题：动态 mapping（映射）、稀疏文档和 nested（嵌套字段）会带来哪些风险？

• 口述答案：动态 mapping（映射）适合受控接入，不适合把用户任意属性键直接变成字段。每个新字段都可能增加 mapping（映射）元数据、倒排或 doc values（列式值）结构，并通过 cluster state（集群状态）发布到节点；大量字段会增加管理节点堆、发布耗时、查询解析和每段字段元数据，最终形成 mapping explosion（映射爆炸）。稀疏文档看似每条只使用少量字段，但如果全体文档的字段并集巨大，集群仍需维护海量字段定义和段结构。nested（嵌套字段）用于保持对象数组中各字段的同对象关系，底层可能生成多个隐藏文档；一个商品含 100 个动态属性对象时，单个业务文档就可能对应大量底层文档，更新任一父字段又会重建整组结构。止血时先冻结异常生产者和动态字段创建，保留原始事件到隔离队列，避免继续扩散；然后根据查询需求把固定属性做模板白名单，把任意键值改成受控键值数组或外部属性模型，限制嵌套数量、深度和更新频率。历史结构通常要通过新 index（索引）重建清理，不能假设删除 mapping（映射）定义就释放旧数据。回归要测字段总数与增量、cluster state（集群状态）发布、管理节点垃圾回收、底层文档倍率、写入延迟、查询准确性和重建时间。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：稀疏文档为何仍可能很贵？
• 直接回答：单文档字段少不代表全索引字段并集小，海量不同字段仍增加映射、分段和集群状态成本。
• 追问：nested（嵌套字段）与普通对象数组最大区别是什么？
• 直接回答：嵌套模型保留数组元素内部字段关联，但以额外底层文档和更新放大为代价。
• 追问：映射爆炸后怎样清理？
• 直接回答：停止新字段，设计受控模板，新建索引只回放有效字段并校验后切换，不能直接删底层文件。
• 详情：字段模型与写放大

16. 问题：节点失联后副本重建为何容易形成 recovery storm（恢复风暴）？

• 口述答案：节点失联不仅减少冗余，还会让剩余健康节点同时承担前台查询、主分片写入、旧有 merge（合并）和新副本恢复。恢复通常先复用或复制 segment（分段），再追赶故障期间的变更；多分片并发恢复会集中消耗源节点磁盘读取、目标节点磁盘写入、网络、校验处理器与文件系统缓存。假设需要重建 4 个各 100 GB（吉字节）的副本，总量约 400 GB（吉字节），在可持续 200 MB/s（兆字节每秒）下，忽略其他成本的传输下限约 34 分钟。若把并发开到 8 路导致磁盘 95% 忙碌，查询高分位从 300 毫秒升到 4 秒，客户端超时和重试又增加负载，恢复就形成正反馈风暴。我的处置顺序是先确认所有 primary shard（主分片）可用和数据风险，再限制恢复并发与带宽，暂停低优先级回填、深分页和大聚合，按业务重要性恢复分片。恢复期间同时看恢复字节与阶段、未分配原因、磁盘队列、网络、文件系统缓存、写拒绝和前台高分位。分片进入同步集合后也不立即全量承载查询，要抽样校验运单版本、删除与查询，并灰度加入流量。长期通过故障域分布、容量余量、分片大小控制和定期恢复演练保证恢复目标。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：恢复越快是否一定越好？
• 直接回答：不是，恢复必须在不击穿剩余健康节点前台服务的条件下满足恢复目标。
• 追问：副本进入同步集合后为何还要业务校验？
• 直接回答：分片状态证明复制流程完成，不能替代业务版本、删除、查询和事件水位的内容校验。
• 追问：恢复期间最先暂停什么？
• 直接回答：暂停低优先级回填、扫描导出和高成本聚合，优先保护权威投影写入与关键查询。
• 详情：恢复限速与数据演绎

17. 问题：磁盘 watermarks（磁盘水位）触发写入异常时，如何止血、修复和回归？

• 口述答案：磁盘事故不能只看使用百分比，要把可用字节和即将发生的临时放大一起算。假设数据 node（节点）有 4 TB（太字节）磁盘，已用 3.6 TB（太字节），只剩约 400 GB（吉字节）；待合并 100 个小 segment（分段）共 300 GB（吉字节），预计新段 240 GB（吉字节），副本恢复还需 180 GB（吉字节），回填每小时新增 60 GB（吉字节），并发需求已经超过余量。现场 watermarks（磁盘水位）可能触发分片迁移、分配限制或写入保护，精确阈值和解除条件必须查配置与版本，不能凭固定数字操作。客户端看到超时或拒绝后若无界重试，会占满线程池队列并继续制造 translog（事务日志）和网络压力。止血先暂停历史回填、异步导出、非关键索引和高成本查询，限制重试并保留稳定幂等键；不要手工删除 segment（分段）文件。随后确认哪些空间可由受支持生命周期清理，扩容或迁移时保护健康节点，并让 merge（合并）和副本恢复分阶段进行。长期修复要建立容量模型，至少预留最大合并新段、最大单次恢复、持续增长、快照缓存和故障缓冲。回归不只看水位下降，还要验证分片不再往返迁移、写拒绝归零、段数净下降、恢复追平、查询高分位稳定和业务水位一致。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：为什么不能直接删除 segment（分段）文件？
• 直接回答：底层文件受 Lucene（全文检索库）提交点和分片元数据管理，绕过引擎删除会破坏索引一致性。
• 追问：只扩容磁盘是否算根治？
• 直接回答：扩容能止血，但还要修复回填、生命周期、分片分布和临时空间预算，否则仍会复发。
• 追问：解除写保护前验证什么？
• 直接回答：验证可用空间覆盖合并与恢复峰值，分配稳定、写队列可控、幂等重试和业务水位均正常。
• 详情：磁盘水位与恢复

18. 问题：出现 write rejection（写入拒绝）和线程池队列上涨时，如何判断根因？

• 口述答案：write rejection（写入拒绝）是保护结果，不是唯一根因。我会先按时间线确认哪些 index（索引）、routing（路由）键和请求类型开始异常，比较写入率、批次大小、响应耗时、队列、拒绝与重试。第一类集群证据包括目标 primary shard（主分片）是否可用、是否热点、未分配原因、mapping（映射）更新、refresh（刷新）、merge（合并）、translog（事务日志）和磁盘保护；第二类主机证据包括处理器、Java heap（Java 堆）、垃圾回收、磁盘队列、输入输出延迟、网络和文件系统缓存。若只有单分片写入率远高于其他分片，多半是 routing（路由）热点；若所有节点磁盘延迟同时上升且段合并、恢复并发很高，则是存储竞争；若管理节点 cluster state（集群状态）发布变慢并伴随新字段增长，则可能是动态映射爆炸；若客户端小批高频加无界重试，队列本身会成为放大器。止血先在入口按业务优先级限流、聚批，关闭无界重试并保存未知结果查证，暂停回填和低价值索引，不盲目扩大队列。修复针对根因调整路由、字段模板、刷新节奏、恢复限速或容量。回归使用峰值与热点分布压测，要求拒绝率、队列等待、未知结果、分片倾斜和事件水位同时达标，而不是只看平均吞吐恢复。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：为什么不先把线程池队列调大？
• 直接回答：大队列会延长等待、占用内存并把过载变成超时风暴，不能修复处理能力或热点根因。
• 追问：怎样区分热点路由和全局容量不足？
• 直接回答：比较各分片写入率、队列、段数和节点资源；单分片突出是热点，普遍饱和才更像全局容量。
• 追问：超时请求怎样回归？
• 直接回答：按稳定业务键查证最终状态，统计真正失败、已成功响应丢失和版本冲突，不能只重放请求数。
• 详情：生产排障矩阵

19. 问题：热点分片、小段过多和 merge（合并）积压如何形成连锁问题？

• 口述答案：热点分片把写入、refresh（刷新）、segment（分段）创建、translog（事务日志）、副本复制和查询同时集中到一个物理执行单元。若客户端又以极小批次写入并保持 1 秒刷新，热点分片会快速产生大量小段；查询需要打开和搜索更多段，文件句柄、元数据和随机读取增加，后台 merge（合并）必须持续读旧写新才能收敛。合并与前台写查、副本恢复共享磁盘和处理器，资源不足时合并积压，删除旧版本不能及时回收，磁盘继续上涨；达到 watermarks（磁盘水位）后分配或写入受限，客户端重试又加重队列，形成正反馈。排查时第一类证据看每分片文档数、索引率、段数、删除数、合并队列和查询耗时，第二类证据看节点磁盘队列、输入输出带宽、处理器、文件系统缓存和可用空间。止血顺序是限制热键与低优先级查询，聚批写入，暂停回填与恢复争抢，必要时放宽非关键索引可见延迟；不能只把 merge（合并）线程调高。长期修复是用确定性路由分桶或重建新索引，按冷热和新鲜度拆分工作负载，并把最大合并临时空间纳入容量。回归要求小段新增率低于合并消化率、热点分片差距收窄、磁盘水位下降、查询高分位恢复且业务版本无差异。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：段数高是否一定是根因？
• 直接回答：不一定，要结合段大小、查询命中、合并字节和磁盘证据；段数是重要线索而非单一结论。
• 追问：提高 merge（合并）并发为什么可能更慢？
• 直接回答：更多合并会与前台查询、写入和恢复竞争磁盘，导致整体输入输出排队加重。
• 追问：路由分桶后有哪些新成本？
• 直接回答：查询要访问多个桶，桶规则需要持久稳定，历史数据还要重建与校验。
• 详情：排障矩阵与设计取舍

20. 问题：Java heap（Java 堆）压力、circuit breaker（断路器）与文件系统缓存应怎样一起理解？

• 口述答案：Elasticsearch（搜索引擎）的内存性能不是把所有内存都给 Java heap（Java 堆）。查询协调、聚合 bucket（桶）、请求对象、mapping（映射）和 cluster state（集群状态）会消耗堆；Lucene（全文检索库）segment（分段）读取、doc values（列式值）和倒排文件又高度依赖操作系统文件系统缓存。Java heap（Java 堆）过小会频繁垃圾回收和触发 circuit breaker（断路器），过大又会挤压文件系统缓存，使查询产生更多磁盘读取，甚至增加暂停风险。断路器根据可估算内存限制危险请求，是避免整个进程被单次高基数 aggregation（聚合）或深分页拖垮的保护，不保证所有原生内存和缓存风险都被精确覆盖。排障要把两类证据并列：集群侧看断路器类型、请求桶数、协调扇出、查询缓存和段读取；主机侧看堆使用、垃圾回收暂停、常驻内存、页缓存命中、缺页、磁盘读延迟与交换风险。止血先停止大窗口、高基数聚合、脚本和扫描导出，限制并发，暂停副本恢复对缓存的冲击；不能简单提高断路器阈值。长期通过查询裁剪、预聚合、稳定字段模型、合理堆与节点角色隔离治理。回归要经历冷缓存、热缓存、刷新、合并、恢复和峰值并发，验证高分位与拒绝均可接受。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：堆越大为何不一定越快？
• 直接回答：更大堆会挤压文件系统缓存并可能增加垃圾回收暂停，Lucene（全文检索库）读取反而更依赖慢磁盘。
• 追问：断路器触发后能否直接提高阈值？
• 直接回答：不应先这样做，应减少请求中间状态和并发，否则可控拒绝可能变成进程失稳。
• 追问：冷缓存回归为什么必要？
• 直接回答：只测热缓存会隐藏磁盘读取与恢复后缓存被驱逐的真实尾延迟。
• 详情：内存与缓存排障

21. 问题：慢查询如何用两类证据定位，而不是凭感觉调参数？

• 口述答案：我先把慢查询按查询形状分组，而不是直接看全集群平均值：是否携带 routing（路由），目标分片数多少，是否深分页，是否全文评分、脚本排序、高基数 aggregation（聚合），时间范围、响应体和并发是多少。第一类 Elasticsearch（搜索引擎）证据包括 query phase（查询阶段）与 fetch phase（取回阶段）耗时、每分片耗时、命中与候选、段数、缓存、合并、恢复、断路器和线程池；第二类主机证据包括处理器、磁盘读取、输入输出队列、网络、Java heap（Java 堆）、垃圾回收和文件系统缓存。若只有一个分片慢并且文档数、段数与写入率异常，就是热点或分片局部问题；若 query phase（查询阶段）快而 fetch phase（取回阶段）慢，可能是大 _source、磁盘随机读或响应体；若协调节点堆升高且桶数巨大，则是聚合归并；若恢复期间所有分片读取变慢，则检查文件系统缓存和磁盘竞争。止血根据业务价值缩小时间、租户和字段，禁用深页与危险聚合，暂停低优先级导出或恢复。修复后使用同一查询样本、相同数据分布和冷暖缓存分别回归，比较每分片和整体高分位、读取字节、中间候选、桶数与结果准确性。没有可重复查询和主机时间线，就不应宣称某个参数是根因。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：query phase（查询阶段）快但 fetch phase（取回阶段）慢看什么？
• 直接回答：看命中文档大小、返回字段、磁盘随机读、网络和响应序列化，减少不必要 _source。
• 追问：所有分片都慢更可能是什么？
• 直接回答：优先检查共享磁盘、网络、缓存驱逐、恢复合并和全局查询形状，不排除普遍容量不足。
• 追问：为什么平均延迟不够？
• 直接回答：分布式查询受慢分片和高成本少数请求影响，高分位与分片分布才能暴露长尾。
• 详情：查询路径与排障

22. 问题：cluster state（集群状态）压力和 split brain（脑裂）防护应如何说明？

• 口述答案：cluster state（集群状态）承载 index（索引）元数据、mapping（映射）、分片路由和分配等全局控制信息，由集群管理路径形成并发布。它不是业务数据面，但字段爆炸、过多分片、频繁索引创建删除和反复分配会使状态体积、待处理任务、发布延迟和管理节点 Java heap（Java 堆）上升，最终影响映射更新、分片恢复和故障决策。split brain（脑裂）风险发生在网络分区或节点身份判断错误时，如果两个分区都继续接受主写，就会产生无法简单合并的分叉历史。现代部署的具体发现、选举、法定条件和发布确认会随版本与拓扑变化，必须通过版本卡核对，不能背一个固定最小节点公式。机制层面的不变量是：只有一个有效 cluster state（集群状态）代际能授权当前 primary shard（主分片），主分片提升推进 primary_term（主分片任期），旧主恢复后旧任期写入必须被拒绝。排障看管理节点选举与发布日志、待处理任务、状态大小、映射与分片变化，同时看网络分区、节点身份、时钟和资源。止血先冻结动态字段和批量索引变更，隔离旧主风险，避免人工同时在两侧写。修复后做网络分区、节点重启和状态发布演练，验证只保留单一写入代际、客户端路由刷新且业务版本可校验。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：cluster state（集群状态）保存所有文档吗？
• 直接回答：不保存，它主要保存集群级元数据与路由，业务文档在各分片数据面中。
• 追问：为何不写固定选举节点数量公式？
• 直接回答：发现与选举行为版本敏感，必须根据现场版本、角色与故障域核对，而机制不变量是单一有效写入代际。
• 追问：旧主拒写靠什么判断？
• 直接回答：新主提升推进主分片任期，旧任期操作不再被当前有效历史接受。
• 详情：集群状态与故障分配

23. 问题：跨境物流运单与轨迹搜索如何设计成可重建投影？

• 口述答案：我会把运单数据库和原始轨迹事件日志作为权威源，因为争议处理需要知道事件来源、发生时间、接收时间、原始状态与修正记录；Elasticsearch（搜索引擎）只保存面向客服和运营的检索投影。每个事件携带运单号、事件标识、业务版本、删除或撤销语义和来源水位，消费者以稳定 document（文档）标识按版本幂等更新。按运单号 routing（路由）可让单运单轨迹查询命中一个 primary shard（主分片），但要监控超大批次和大客户热点；模糊地址、异常描述和状态筛选使用受控 text（全文字段）、keyword（精确字段）与 doc values（列式值），不把所有原始键动态映射。消费者超时先查版本，重复事件不新增文档，乱序旧版本不覆盖新状态；依法删除、业务撤销和字段脱敏都作为事件传播。断点保存事件分区和水位，校验任务比较运单数、最后轨迹时间、版本、删除与关键查询。索引滞后时，精确运单号可限流回权威库，全文和大聚合提示更新中或缩小范围。需要重建时新建索引，全量导入权威快照，从起始水位追增量，影子比对后切换别名并保留旧索引回滚。这样搜索新鲜度可量化，事实争议始终回权威记录。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：为什么同时保存事件时间和接收时间？
• 直接回答：事件时间表达业务顺序，接收时间用于观察迟到、乱序和投影延迟。
• 追问：单号精确查询何时回源？
• 直接回答：索引水位超阈值、漏单告警或索引不可用时，在限流和权限控制下回权威库。
• 追问：如何证明重建完成？
• 直接回答：水位追平，并校验运单数、版本、删除、最后事件时间、关键过滤和抽样全文结果。
• 详情：项目投影闭环

24. 问题：WMS（仓储管理系统）商品搜索如何避免把索引当库存权威源？

• 口述答案：WMS（仓储管理系统）中商品主数据、可售库存、预占、释放和出入库流水分别有权威数据库事务边界，Elasticsearch（搜索引擎）负责商品名、编码、属性、库位和展示性库存的检索，不能决定是否还能卖出一件货。商品事件使用稳定商品键和业务版本投影，名称可按需要建立 text（全文字段）与 keyword（精确字段），筛选字段使用受控 mapping（映射），任意属性不直接创建动态字段；高频库存变化要评估是否只保存展示摘要，避免大商品文档反复整文档重建。下单提交必须回权威库存执行条件更新，即使搜索显示有货也要二次裁决；索引滞后时页面可标记更新中或按商品键限流回源，不能用旧索引继续扣减。商品失效、仓库下架和敏感属性删除必须传播删除或遮蔽事件，消费者按版本幂等处理并保存水位。校验除文档数外，还要比较商品状态、关键属性、展示库存版本、删除和抽样查询。1000 万商品全量变更时采用新 index（索引）重建，分批导入、增量追平、影子读与别名切换，保留旧索引和回滚门槛。查询侧限制深分页和高基数属性聚合，大批商品导出交给异步任务。这样搜索体验与库存正确性各自有清晰服务目标，搜索故障不会扩大成超卖。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：搜索显示有货能否直接下单？
• 直接回答：不能，展示可用索引，交易提交必须回权威库存再次执行条件校验。
• 追问：库存高频变化为什么可能不适合放大文档？
• 直接回答：小字段变化会触发整文档重建、复制和合并，造成写放大与可见延迟。
• 追问：商品下架如何保证搜索消失？
• 直接回答：权威源提交带版本的下架或删除事件，索引幂等处理，并通过水位与抽样查询校验传播完成。
• 详情：WMS（仓储管理系统）项目边界

25. 问题：IoT（物联网）报警风暴下，搜索投影如何保护权威事件和集群？

• 口述答案：IoT（物联网）报警场景先区分原始设备事件、规则版本、告警状态与搜索文档。原始事件和告警状态机是权威事实，Elasticsearch（搜索引擎）用于按设备、时间、级别和文本检索，不能因为索引漏写就判定告警不存在，也不能用 aggregation（聚合）结果替代告警裁决。每条事件携带设备标识、事件标识、事件时间、接收时间、规则版本和撤销语义，消费者按事件标识去重、按业务版本更新；同一设备的乱序事件通过状态机决定是否修正，不能按到达顺序覆盖。报警风暴时先保护权威事件落盘和关键告警，投影侧按设备或租户限流、聚批，把普通明细降级为延迟索引，严重告警走保留通道。routing（路由）既要避免单设备超热点，也要支持设备局部查询，可对超大租户使用确定性桶并保存查询规则。搜索集群出现线程池拒绝、小段和 merge（合并）积压时，暂停历史回填和大聚合，不能让重试反压权威接入。断点记录事件分区与水位，恢复后按设备时间窗口分段回放；校验每设备计数、最后事件、严重级别、撤销与抽样原文。搜索不可用时告警裁决和通知仍依赖权威状态，运营检索提示延迟或按精确设备回源。全量重建从原始事件和规则版本重算，避免把错误聚合结果当输入。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：报警聚合能否替代原始事件？
• 直接回答：不能，聚合用于观察，原始事件用于追溯、规则重算、争议处理和恢复。
• 追问：报警风暴最先保护什么？
• 直接回答：先保护权威事件和严重告警通道，再降级普通搜索投影、历史回填与低价值聚合。
• 追问：恢复后怎样回放？
• 直接回答：按持久水位和设备时间窗口分段幂等回放，校验计数、最后事件、撤销和告警状态。
• 详情：IoT（物联网）投影闭环

26. 问题：异步任务日志使用 Elasticsearch（搜索引擎）时，如何避免搜索结果影响任务执行？

• 口述答案：异步任务的任务状态、执行租约、尝试次数、幂等键和最终结果必须保存在权威调度存储，Runner（执行器）领取、续租和完成都以该状态裁决；Elasticsearch（搜索引擎）只保存日志与检索投影，用于按任务标识、执行器、错误码和时间排查。每次尝试使用稳定 task_id + attempt_no 作为业务键，日志事件携带单调序号、来源水位和删除保留策略；消费者重复收到同一批日志时按事件标识去重，超时先查证，不生成随机新文档。任务搜索索引晚到不能触发重复执行，运维页面需要重新运行任务时也必须调用权威调度接口，而不是根据“搜索不到成功日志”推断失败。高峰期普通调试日志可以聚批并延迟 refresh（刷新），关键状态摘要单独保持更短可见窗口，避免 1 秒刷新制造小 segment（分段）和 merge（合并）积压。异步导出采用 PIT（时间点视图）与 search_after（游标式分页），保存排序值和文件断点，不能使用深 from + size（偏移分页）。索引滞后时按任务标识限流回权威状态，全文日志搜索可降级。重建按时间区间从对象存储日志或事件日志回放，持续追增量，校验任务数、尝试数、最后状态、日志序号和删除保留。这样即使搜索集群 red（红色），任务执行不变量仍不会被破坏。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：搜索不到成功日志能否自动重试任务？
• 直接回答：不能，任务是否完成必须查询权威调度状态和副作用记录，日志索引可能滞后或缺失。
• 追问：关键状态与普通日志为何分层？
• 直接回答：两者新鲜度和保留价值不同，分层能避免所有明细都用高刷新频率拖垮写入。
• 追问：日志重建从哪里来？
• 直接回答：从权威任务记录、可回放事件或原始日志存储来，不能从已有错误索引复制后宣称修复。
• 详情：异步任务日志边界

27. 问题：请完整说明一次 Elasticsearch（搜索引擎）索引重建与别名切换。

• 口述答案：重建前先冻结数据语义，而不只是创建一个新 index（索引）。我会明确业务键、版本、删除、字段类型、routing（路由）、主分片数、分析规则、权限和回滚责任，记录全量快照对应的事件起始水位。新索引创建后先用权威数据库一致快照或可验证原始事件做全量导入，采用稳定 document（文档）标识和业务路由；导入过程持久化分区断点、成功数、失败样本和校验摘要。全量期间源端仍有变化，因此从起始水位持续消费增量，按版本幂等应用，未知结果查证后再推进断点。追平后做多层校验：总文档数、按租户或日期聚合、业务版本、删除与脱敏、关键过滤、排序、全文样例和权限结果；再用影子流量比较新旧查询和高分位。通过后灰度切换 alias（别名）或读取配置，观察错误率、差异、水位和资源，异常立即回旧索引并继续修复。回滚窗口内保留旧索引只读、事件日志和新旧水位，不能立即删除。最终停止旧读前执行 snapshot（快照）与隔离恢复验证，并记录实际重建时间、峰值磁盘、合并与副本恢复成本。若事件保留不足、删除语义不全或权威快照不一致，应停止切换，而不是用文档数接近掩盖缺口。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：全量导入完成为什么不能立刻切换？
• 直接回答：全量期间源端仍变化，必须从起始水位追增量并完成内容与行为校验。
• 追问：别名切换后为何保留旧索引？
• 直接回答：它提供查询回滚窗口和差异证据，直到新索引覆盖高峰与故障观察并完成恢复验证。
• 追问：文档数相同是否足够？
• 直接回答：不够，还要校验版本、删除、字段、聚合、查询、权限、路由和事件水位。
• 详情：幂等投影与重建时序

28. 问题：snapshot（快照）失败或恢复不达标时，应该怎样建立证据闭环？

• 口述答案：snapshot（快照）不是“任务状态成功”四个字，而是一条从范围、仓库、生成到恢复验证的链路。首先明确要保护哪些 index（索引）、cluster state（集群状态）元数据、模板、权限、插件配置和外部分词资源，哪些内容需另行备份；具体快照一致性、并发和版本兼容必须查现场文档与实验。任务失败时第一类证据查看失败分片、阶段、仓库响应、重试和权限，第二类证据查看对象存储可用性、网络、磁盘、凭据和配额；同时确认生产分片是否正在恢复、迁移或磁盘高水位。止血是停止删除旧恢复点和高风险变更，保护仍可用快照，限制与快照争用的低优先级任务；不能反复无界重试掩盖仓库错误。修复权限、仓库一致性或分片稳定性后重新执行，并在隔离集群恢复到明确目标版本，记录恢复点、耗时、峰值网络与空间。恢复验收包括主副分片可用、文档与聚合数量、业务版本、删除、关键查询、权限和应用兼容；若只能恢复数据却缺少模板、词典或插件，业务仍可能不可用。还要把恢复点目标与事件日志结合，快照之后的增量通过可回放事件追平。定期注入仓库不可用、单分片失败和版本回退场景，才能证明恢复流程不是纸面方案。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：快照成功为何还可能恢复失败？
• 直接回答：可能存在权限、仓库、版本、插件、外部词典、容量或范围缺失，只有独立恢复能暴露。
• 追问：快照之后的数据怎样恢复？
• 直接回答：从可回放事件日志按业务版本幂等追平，并校验水位与删除。
• 追问：快照失败时最先禁止什么？
• 直接回答：禁止删除现有恢复点和进行不可逆高风险变更，先保留可恢复证据。
• 详情：副本与快照边界

29. 问题：Elasticsearch（搜索引擎）的几个核心设计取舍如何串成一条主线？

• 口述答案：我会用“预付写成本，换取稳定并发搜索”串起来。倒排索引在写入时把 text（全文字段）分词并建立词项到文档的关联，keyword（精确字段）和 doc values（列式值）又为过滤、排序与 aggregation（聚合）准备结构，所以快速召回的代价是多字段索引、复制和 merge（合并）产生写放大。Lucene（全文检索库）segment（分段）不可变，让搜索线程可以读取稳定视图，新写通过新分段发布，删除与更新不原地修改，后台合并再回收旧版本；这用额外磁盘输入输出和临时空间换取并发读写简化。refresh（刷新）决定新段多久对搜索可见，频繁刷新降低可见延迟却产生更多小段并压低吞吐，所以新鲜度必须按业务分层。shard（分片）是容量、并行、路由和恢复单位，不是越多越好；更多分片提高并行与迁移颗粒度，也增加固定内存、cluster state（集群状态）、协调扇出和小段。replica shard（副本分片）提高在线冗余与读选择，不能替代 snapshot（快照）。这些取舍共同决定搜索 index（索引）适合作为可重建 projection（投影），而不是库存、支付、任务租约和告警状态的权威源。工程设计必须同时写明可见窗口、资源预算、故障降级、事件回放和重建证据。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：倒排索引为什么是写放大换召回？
• 直接回答：写入时预建词项、文档关联和多种字段结构，查询才能避免扫描全部原文。
• 追问：分片为什么不是越多越好？
• 直接回答：每个分片都有堆、线程、段、文件和协调固定成本，过多会放大管理与查询。
• 追问：refresh（刷新）取舍的两个端点是什么？
• 直接回答：一端是更短搜索可见延迟，另一端是更高写吞吐、更少小段和更低合并压力。
• 详情：设计思想与项目闭环

30. 问题：主分片数选错后，如何评估重新分片或重建的成本与风险？

• 口述答案：我先判断问题是单分片过大、主分片过少限制并行、分片过多造成固定成本，还是 routing（路由）倾斜；不同根因不能都归结为“加分片”。评估输入包括当前文档与字节、每日增长、每分片段数与热点、节点与故障域、查询扇出、恢复时长、事件保留和可用迁移窗口。主分片数参与文档路由空间，改变归属通常需要新 index（索引）和数据搬运。以 2 TB（太字节）主数据、20 个主分片为例，平均 100 GB（吉字节）；改为 40 个主分片至少要重新读取、解析和写入全部文档，1 个副本使目标基础数据约 4 TB（太字节），还要叠加旧索引、translog（事务日志）、merge（合并）临时空间、增量追平和网络。若事件每小时新增 300 GB（吉字节），全量速度不高于新增速度就永远追不平。方案应冻结 mapping（映射）、routing（路由）和业务版本，从一致快照开始导入，持续追增量，校验分片分布、版本、删除和查询；灰度切换并保留旧索引回滚。重新分片能力、限制和是否可原地执行属于版本敏感行为，必须现场核对，不能假设无停机零成本。完成后还要做节点失联和副本重建演练，证明新分片大小改善恢复而没有把协调扇出推到不可接受。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：增加节点为何不能修复主分片过少？
• 直接回答：节点只能承载和迁移既有分片，主分片并行上限与路由空间仍然不变。
• 追问：迁移容量为什么要同时保留新旧索引？
• 直接回答：全量、增量、校验和回滚窗口期间两套索引共存，还需预留合并与恢复临时空间。
• 追问：怎样判断增量能追平？
• 直接回答：目标持续应用速率必须高于源端新增速率，并为失败重试、校验和高峰保留余量。
• 详情：主分片数与未来迁移

31. 问题：请口述一次“写入拒绝、慢查询、磁盘水位与副本恢复同时发生”的完整事故处理。

• 口述答案：我先按业务影响分级：确认权威数据库和事件日志是否仍可提交，库存、任务与告警裁决是否受影响；搜索只读功能先降级，精确键在限流下回源，停止深分页、大聚合和异步导出。时间线上把写入拒绝、线程池队列、查询高分位、节点失联、watermarks（磁盘水位）、merge（合并）和恢复开始时间对齐。集群证据查看未分配 primary shard（主分片）与 replica shard（副本分片）、热点 routing（路由）、段数、合并、恢复字节、断路器和 cluster state（集群状态）任务；主机证据查看磁盘可用字节与队列、网络、处理器、Java heap（Java 堆）、垃圾回收和文件系统缓存。若节点离线触发 400 GB（吉字节）副本恢复，同时 100 个小 segment（分段）等待合并，磁盘只剩 400 GB（吉字节），恢复、合并与回填就共同触发保护，客户端无界重试再占满队列。止血是暂停回填和低优先级写，限制客户端重试，降低恢复并发，保护有效主分片与关键投影；必要时扩容，但不手工删段。修复批次与刷新、热点路由、生命周期和容量预算，分阶段恢复副本与查询。最后按稳定业务键查证所有未知结果，追平事件水位，校验版本、删除和关键查询；故障演练重放同等数据分布，要求写拒绝归零、磁盘有并发余量、查询高分位达标且快照恢复通过。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：事故中第一优先级是什么？
• 直接回答：保护权威事实和唯一写入代际，搜索降级不能反向影响交易与任务裁决。
• 追问：为何同时需要集群证据和主机证据？
• 直接回答：前者定位请求、分片与恢复路径，后者证明实际处理器、内存、磁盘和网络瓶颈，避免误判。
• 追问：怎样签收事故恢复？
• 直接回答：基础设施指标、事件水位、未知结果查证、业务校验、同分布压测和快照恢复演练全部通过。
• 详情：生产故障五段式矩阵

32. 问题：项目版本未知时，如何给出可信的 Elasticsearch（搜索引擎）方案与面试回答？

• 口述答案：我会把稳定机制、版本敏感行为和现场证据明确分层。稳定机制可以说明 index（索引）由 primary shard（主分片）与 replica shard（副本分片）组成，每个 shard（分片）是 Lucene（全文检索库）索引；写入经主分片排序复制，refresh（刷新）影响搜索可见，segment（分段）不可变并由 merge（合并）整理，查询经过分片局部候选、协调归并和 fetch phase（取回阶段），主分片切换通过 primary_term（主分片任期）隔离旧主。版本敏感内容则不猜测，包括项目实际版本、角色与发现配置、写入确认和 translog（事务日志）刷盘默认、refresh interval（刷新间隔）、缓存资格、watermarks（磁盘水位）、恢复限速、快照兼容、重新分片能力与客户端行为，全部标记“待现场核对”。核对卡记录部署镜像或软件包、插件、配置、拓扑、官方章节、最小实验、观察日期、适用边界和回退条件。方案评审时用最小实验验证写后搜索可见、超时未知结果、主分片提升、旧主拒写、深分页、高基数聚合、磁盘保护和快照恢复；容量结论再用真实数据分布压测，不能从小实验外推。面试中我会主动说清“机制上如此，默认值需按项目版本和配置确认”，这比声称“最新版已经解决”更可信，也便于升级后重新验证引用结论。 落地时我会把请求标识、业务键、事件水位、分片、节点和时间线写入同一观测链路，并在隔离环境注入超时、节点失联和磁盘紧张；发布后用分片分布、高分位、拒绝、业务版本、删除和恢复耗时共同签收。任何一项只能说明局部健康，不能替代权威源对账。
• 追问：为什么不能说“最新版默认安全”？
• 直接回答：项目可能不是该版本，默认与历史行为会变化，且插件、拓扑和配置都会改变实际边界。
• 追问：最小实验能替代容量压测吗？
• 直接回答：不能，最小实验验证机制，容量必须使用真实数据分布、并发、索引和故障恢复负载测量。
• 追问：版本卡至少记录什么？
• 直接回答：实际版本、插件、拓扑、配置、官方章节、实验输入输出、核对日期、适用边界、升级与回退条件。
• 详情：版本核对卡

7. 复习与验收清单

• 能从 cluster（集群）讲到 Lucene（全文检索库）segment（分段），并解释 20 个主分片与 1 个副本的容量、并行和恢复成本。
• 能画出协调节点、主分片、内存缓冲、translog（事务日志）、副本、refresh（刷新）、flush（冲刷）与 merge（合并）的不同确认点。
• 能用 seq_no（序列号）与 primary_term（主分片任期）解释乐观并发、未知结果查证、主分片提升和旧主拒写。
• 能演绎 query phase（查询阶段）、局部 Top-K（最高 K 个结果）、协调归并、fetch phase（取回阶段）、深分页和 PIT（时间点视图）游标。
• 能说明 doc values（列式值）、filter cache（过滤缓存）、request cache（请求缓存）、高 cardinality（基数）聚合和协调节点内存边界。
• 能按两类证据处理写入拒绝、热点、小段、合并、堆、断路器、文件系统缓存、慢查询、映射爆炸、恢复风暴和快照失败。
• 能把跨境物流、WMS（仓储管理系统）、IoT（物联网）报警和异步任务日志落到权威源、幂等、删除、断点、校验、回放、回源和重建。
• 能明确项目版本为“待现场核对”，任何默认行为都通过版本卡和最小实验确认。