MySQL 保存业务真相，Elasticsearch 保存可重建的搜索投影。同步方案必须允许延迟和重复，避免旧事件覆盖新文档，并提供全量重建与持续对账。
Table of contents
Open Table of contents
三种同步方式
| 方式 | 优点 | 主要风险 |
|---|---|---|
| 应用同步双写 | 实现直观 | 任一边失败产生不一致，增加请求延迟 |
| Binlog CDC | 不侵入业务提交路径，可重放 | 表结构事件需转换成搜索文档 |
| Outbox + 事件 | 业务语义清晰，与本地事务原子 | 需维护发布、积压和事件契约 |
CDC（Change Data Capture，变更数据捕获）从数据库日志读取插入、更新和删除。搜索文档常由多张表拼成，一条行变更不等于完整业务事件；投影器可能需要回查数据库或消费领域事件。
用版本阻止倒序覆盖
每个变更携带单调版本，例如数据库行版本或 Binlog 位置。Elasticsearch 更新只接受比当前版本新的事件；重复和旧事件直接忽略。
运行实验室 CDC 测试下载：
mvn -Dtest=SearchArchitectureTest#cdcProjectionRejectsOldOrDuplicateEvents test测试先应用版本 2，再收到版本 1，投影仍保留新值。删除也要携带版本，并保留足够时间的墓碑或外部版本信息，避免迟到更新把已删除文档复活。
重建和对账是正式能力
新建版本化索引，从数据库快照全量导入，同时记录增量起点；全量完成后追平增量，校验数量、业务关键字段哈希和代表性查询，再切换读别名。不要在原索引上边删边重灌。
持续对账按主键范围抽样或计算摘要，差异进入修复队列。监控 CDC 位点延迟、失败事件、重试年龄、文档版本冲突和索引/数据库数量差。对外承诺“搜索在 30 秒内更新”比笼统的“最终一致”更可验证。
下一步
继续阅读09-12 微服务日志采集与检索，把搜索能力用于可治理的日志平台。