Elasticsearch 如何处理并发更新和数据一致性？

面试考察点

是否理解 seq_no 与 primary_term 的乐观并发控制。
能否区分分片内复制和数据库到 ES 的跨系统一致性。
是否会用版本、重试和对账保证最终收敛。

核心答案

Elasticsearch 为操作分配序列号，并用 primary term 区分主分片任期。更新时携带 if_seq_no 与 if_primary_term，只有文档仍是读取时版本才执行，否则返回冲突，由业务决定重读、合并或放弃。

这能防止同一文档的丢失更新，但不能自动让关系数据库和 Elasticsearch 形成分布式事务。

主副本一致性

写操作先由主分片排序并执行，再复制到副本。故障切主需要依赖复制历史和检查点恢复；副本确认、超时与重试会影响调用方看到的结果，重试操作应具有幂等语义。

乐观并发控制示例

PUT orders/_doc/O1001?if_seq_no=42&if_primary_term=7
{"status":"PAID","version":8}

如果文档在读取后已被其他请求更新，seq_no 或 primary_term 不匹配，Elasticsearch 返回 409。调用方可以重新读取并合并字段、按业务状态机拒绝，或把冲突放入补偿队列；不能无脑覆盖，否则会丢失更新。

_version、seq_no、primary_term 和业务 version 不是同一个层次：前者帮助 ES 判断并发操作顺序，业务 version 表达订单/库存等领域事实。跨系统同步通常需要同时携带业务版本。

更新脚本与状态机

POST orders/_update/O1001
{
  "script": {
    "source": "if (ctx._source.version + 1 != params.version) { ctx.op = 'none' } else { ctx._source.status = params.status; ctx._source.version = params.version }",
    "params": {"version": 8, "status": "PAID"}
  }
}

脚本可以防止过旧事件覆盖新状态，但只有在业务状态合法时才应更新；例如 SHIPPED 不能退回 CREATED。更复杂状态机应在事实源或服务层校验，ES 只作为查询投影。

主副本复制的故障边界

主分片对操作排序并复制，副本可能暂时落后。请求成功的确认级别、refresh 时机和副本可用性会影响读到的数据。主节点故障切换后，系统通过复制历史和 checkpoint 处理已确认/未确认操作，但客户端重试仍可能重复，因此写入接口需要幂等。

数据库到 ES 的最终一致闭环

数据库事务 -> Outbox/CDC -> Kafka/队列 -> ES bulk
        ↘ 对账任务、重试、死信、版本过滤 ↗

事件应包含业务主键、版本、事件 ID、发生时间和删除标记。消费者按版本拒绝旧事件，按事件 ID 去重；失败记录持久化而非只打日志。定期从数据库抽取关键字段与 ES 比较，修复漏写、乱序、映射失败和删除遗漏。

删除和重建

ES 索引可删除重建，但重建期间别名切换、双写和读一致性需要设计。先创建新索引并回填，持续消费增量，校验文档数与版本，再原子切 alias；失败可切回旧索引。直接在原索引大量 update_by_query 可能长时间占用资源且难以回滚。

跨系统同步

数据库通常作为事实源，通过 Outbox、Binlog CDC 或可靠消息更新 ES。事件携带业务主键和单调版本，ES 只接受更新版本；失败进入重试与死信，并用定期对账修复漏数。

常见误区

外部版本号使用普通时间戳可能因精度或时钟问题冲突。遇到 409 就无限重试也可能覆盖业务意图，应针对计数合并、状态机更新和整文档替换使用不同策略。

高频追问与参考回答

追问：数据库已提交但 ES 更新失败怎么办？

不要在请求线程里只重试几次就结束；使用可持久化事件记录、异步重试、监控和对账，让更新最终可恢复且可追踪。

追问：ES 的版本控制可以替代数据库事务吗？

不能。它只控制 ES 内部文档并发更新，不会回滚数据库，也不保证多个外部系统原子提交。

追问：如何处理乱序 CDC 事件？

事件带单调业务版本，消费者只接受更高版本；旧事件丢弃但记录指标，缺版本可等待、回查或进入重试。不能仅按接收时间覆盖。

追问：为什么重试 ES 写入仍可能重复？

请求可能已在服务端成功而响应在网络中丢失，客户端重试又提交一次。使用稳定文档 ID、幂等 upsert 或事件去重记录消除重复副作用。

总结

分片内用序列号和任期做乐观并发，跨数据库则依赖可靠变更流、业务版本与对账实现最终一致。

机制全景图

下面把「Elasticsearch 如何处理并发更新和数据一致性？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。

flowchart LR
    A["写请求带版本条件"]
    A --> B["主分片顺序执行"]
    B --> C["复制到 in-sync 副本"]
    C --> D["refresh 提供搜索可见性"]
    D --> E["失败重试与外部数据源对账"]

完整链路：从输入到结果

沿着「写请求带版本条件 → 主分片顺序执行 → 复制到 in-sync 副本 → refresh 提供搜索可见性 → 失败重试与外部数据源对账」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。

1. 写请求带版本条件

seq_no 与 primary_term 标识主分片上的操作顺序，可用于乐观并发控制避免旧写覆盖新写。

2. 主分片顺序执行

主分片对同一文档串行裁决，if_seq_no/if_primary_term 不匹配时返回冲突。

3. 复制到 in-sync 副本

副本异步应用主分片操作并保持 in-sync 集合，故障选主仍有明确历史。

4. refresh 提供搜索可见性

GET 与 search 可见性不同：实时 GET 可读最新操作，search 依赖 refresh。

5. 失败重试与外部数据源对账

与 MySQL 等外部事实源同步时，重试、乱序和删除都需业务版本及对账，ES 不能提供跨系统事务。

源码与实现定位

入口	阅读重点
InternalEngine#planIndexingAsPrimary	seq_no/primary_term 裁决
_seq_no/_primary_term	乐观锁令牌

源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。

参数配置与可复现实验

PUT products/_doc/42?if_seq_no=17&if_primary_term=3
{"status":"ONLINE"}

乱序重放 v1/v3/v2 和删除墓碑，验证旧版本被拒绝。

验证步骤与预期结果

1. 固定输入和基线

先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「version conflict」为主基线，记录值应满足「记录稳态基线」；同时保存版本冲突数、CDC Lag，使后续变化能够回到同一时间轴比较。

2. 从实现入口确认路径

在「InternalEngine#planIndexingAsPrimary」确认请求确实进入「seq_no/primary_term 裁决」对应的实现，再沿「_seq_no/_primary_term」观察「乐观锁令牌」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。

3. 注入本文特有的失败模式

优先复现「用 last-write-wins 接受乱序覆盖」，并把单一变量逐级放大，直到「version conflict」越过「超过基线2倍」。随后再分别验证「把 refresh 延迟误判为数据丢失」和「重试删除与写入没有墓碑版本」，三类故障分开执行，避免多个变量同时变化而无法归因。

4. 执行止损和根因修复

第一轮只应用「外部事件带单调版本」，确认它能控制影响范围；第二轮应用「删除保留墓碑版本」，验证核心链路恢复；最后落实「周期源库对账」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。

5. 通过退出条件

实验只有同时满足三项才算通过：「version conflict」回到「记录稳态基线」、「P99」回到「小于业务预算」、「结果差异」回到「0」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。

量化基线

指标	样例基线/口径	风险线	结论
version conflict	记录稳态基线	超过基线2倍	按实现入口定位
P99	小于业务预算	突破预算	停止扩量
结果差异	0	任意非零	回滚并重建

这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。

事故复盘：CDC 延迟恢复后旧事件覆盖新文档

重放队列把较早更新晚于新更新送达，普通 index API 覆盖了当前状态。把数据库单调版本作为 external_gte 或脚本条件后，旧事件被拒绝并记录。

失败模式	首要证据	第一处置动作
用 last-write-wins 接受乱序覆盖	版本冲突数	外部事件带单调版本
把 refresh 延迟误判为数据丢失	CDC Lag	删除保留墓碑版本
重试删除与写入没有墓碑版本	源库/索引差异	周期源库对账

发布与回滚检查点

发布前：确认「InternalEngine#planIndexingAsPrimary」对应实现和上述配置在目标版本仍然有效，并保存「version conflict」基线。
灰度中：同时观察版本冲突数、CDC Lag、源库/索引差异；任一指标越过表中风险线，就停止继续扩量。
回滚时：先执行「外部事件带单调版本」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
发布后：至少覆盖一个完整峰值周期，确认「用 last-write-wins 接受乱序覆盖」没有再次出现，才关闭变更观察窗口。

方案对比与选型

方案	更适合的场景	主要收益	代价与边界
内部 seq_no 控制	读改写都在同一 ES 索引	原生并发控制	不能跨重建或外部系统直接沿用
外部业务版本	CDC/多源按单调版本同步	能拒绝乱序旧事件	版本必须全局可比较且处理删除
全量重建 + alias	大范围修复或 Mapping 变化	结果可审计、切换原子	资源、时间和增量追平复杂

选型至少带上文档规模、分片数、字段基数、查询并发和写入速率，并用上面的量化基线验证；未知数据应明确为待测假设。

设计边界与工程取舍

ES 一致性要分为单文档并发、主副本复制、搜索可见性和外部数据源同步四层，不能用一个“最终一致”概括全部。

工程落地遵循：先设计 Mapping 与分片，再优化查询；任何调优都要控制扫描与内存放大。回答时直接引用「InternalEngine#planIndexingAsPrimary」、配置实验和事故数据，比复述固定模板更有说服力。