做搜索和业务数据打通的项目，最绕不开的一个坎就是MySQL和Elasticsearch之间的数据同步。业务数据在MySQL里老老实实待着，搜索要用的字段却散落在ES里，两边一旦对不上账，线上就会出现搜索结果和详情页不一致、状态显示错乱、库存到处飘的尴尬局面。这类问题排查起来极其痛苦，因为你很难说清楚到底是谁先乱的。我在实际项目里先后换过四种同步方案，每一种都有它适用的场景和绕不开的坑，这篇文章就把它们的原理、选型和踩坑经验一次性讲透。
这篇文章适合正在做搜索系统、数据中台或者任何需要把关系型数据库数据搬运到搜索引擎的同学，不管你是刚接触ES的初级开发，还是已经在运维同步管线的负责人，都能在这里找到一套可落地的选型思路和实操模板。
1. 先搞清楚：MySQL和Elasticsearch的一致性难在哪
1.1 两套存储的底层定位完全不同
MySQL是典型的关系型数据库，核心能力是事务和约束，讲究的是ACID，数据一致性靠锁和事务日志来保证。Elasticsearch是搜索引擎，核心能力是倒排索引和全文检索，讲究的是海量数据下的查询速度和相关性排序，它的写入是近实时的，默认情况下文档刷新到搜索可见有一秒左右的延迟。
这就带来一个天然的错位：业务在MySQL里做了变更，ES这边并不会自动感知。两边本质上是两套独立的存储引擎，没有原生的数据同步机制，只能靠数据同步方案在外面搭桥。你不可能指望MySQL提交一个事务之后，ES里的数据瞬间跟着变，因为ES的设计目标里压根没有“跟MySQL强一致”这一项。
1.2 一致性问题具体出现在哪些环节
实际业务中，数据从MySQL流向ES要经过一条链路，链路里每个环节都可能出问题。最常见的有三类：
- 写入中断：业务代码在更新MySQL之后，还没来得及写ES，应用就崩溃了，或者网络闪断，ES那一侧永远少了一条数据。
- 顺序错乱：同一条记录被先后修改两次，第一次的旧值还没到ES，第二次的新值反而先到了，ES里最终留下了旧数据。
- 部分失败：一个事务里涉及多张表变更，MySQL那边提交成功了，但ES的批量写入只成功了一半，两边状态就分叉了。
这三个问题的本质是：MySQL和ES之间的同步不是原子操作，也没有回滚机制。一旦一侧成功一侧失败，系统不会自动纠正，只能靠另外的机制去发现和补齐。当你真正理解了这一点，再看市面上各种同步方案，你会发现它们本质上都在解决同一件事：如何让链路不中断、不乱序、不丢数据，并且在出错之后能自动恢复。
2. 四种方案全景图：核心思路和适用边界
先给大家一张全景对照表，后面每一节再拆开细讲。
| 方案 | 核心思路 | 实时性 | 数据可靠性 | 开发成本 | 运维成本 | 典型场景 |
|---|---|---|---|---|---|---|
| 应用双写 | 业务代码在同一逻辑里同时写MySQL和ES | 高，天然同步 | 依赖补偿机制 | 低 | 低 | 小项目、低频写、对一致性要求高的核心场景 |
| 消息队列异步同步 | 写MySQL后发消息，由消费者异步写ES | 准实时，依赖MQ吞吐 | 高，可重试 | 中 | 中 | 中等并发、需要削峰解耦的互联网业务 |
| Binlog订阅同步 | 解析MySQL的Binlog，把增量变更回放到ES | 准实时，秒级 | 高，不依赖业务代码 | 高 | 高 | 大规模、多服务共享数据、需要稳定管线的场景 |
| 定时全量+增量扫描 | 定时任务按时间戳或版本号扫描增量数据，同步到ES | 分钟级到小时级 | 中，需注意扫描窗口 | 低 | 低 | 对实时性要求不高、数据量可控、允许阶段性同步 |
四个方案没有绝对的好坏，只有匹配不匹配。你要先把业务对实时性、可靠性和成本的要求摆清楚，再决定用哪一套，或者组合使用哪几套。下面我逐个展开。
3. 方案一：应用双写，最直接也最需要兜底
3.1 双写的基本流程
应用双写是最朴素的做法：在业务代码里，同一个请求处理好MySQL写入之后，紧接着把数据写入ES。看起来很简单，核心逻辑就是一条链路上连续执行两个写操作。
public void updateGoods(Goods goods) { // 第一步：写MySQL goodsMapper.updateById(goods); // 第二步：写Elasticsearch goodsEsMapper.updateDocument(goods); }很多小项目一开始都是这么干的，因为它几乎不需要引入额外组件，整个写入链路肉眼可见，出了问题也容易顺着代码排查。如果MySQL和ES都写在同一个本地事务里，还能保证两边要么都成功、要么都失败。
但这里有个非常关键的前提：MySQL和ES不在同一个事务管理器里，你不能用数据库本地事务去覆盖ES的写入。很多团队用分布式事务框架（比如TCC或Saga）去硬套，结果复杂度直接起飞，运维成本比收益还高。实际业务里，我更推荐的是“主流程不阻塞 + 失败补偿”的思路。
3.2 双写方案的补偿机制
双写最怕的是第二步失败，而MySQL已经提交了。对于这种情况，我的常规套路是加一张同步日志表，把每次写ES失败的情况记录下来，由后台任务定时重放。
CREATE TABLE es_sync_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_type VARCHAR(32) NOT NULL COMMENT '业务类型', biz_id VARCHAR(64) NOT NULL COMMENT '业务主键', action VARCHAR(16) NOT NULL COMMENT 'INSERT/UPDATE/DELETE', payload JSON NOT NULL COMMENT '写入ES的完整数据', status TINYINT NOT NULL DEFAULT 0 COMMENT '0-待重放 1-成功 2-失败', retry_count INT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL );业务里写MySQL时，在同一事务里插入这条同步日志，然后应用把日志异步发送给一个消费端去写ES。消费端成功后把日志状态改成成功。如果消费端异常，日志还躺在表里，后台扫描任务每隔几分钟捞一次待重放的记录重新写入ES。这个方案本质上就是双写 + 本地消息表，虽然代码变多了，但一致性的兜底能力提升了一个档次。
3.3 双写方案适用边界
双写方案最大的优点是链路简单、定位问题快，但它有明显的天花板。首先是双写延迟不可控，如果写ES的耗时太长，会拖累主请求的响应时间，尤其在高并发写入场景下，ES的写入吞吐可能成为瓶颈。其次是业务代码侵入性强，每个需要同步的业务操作都得手动加上ES写入逻辑，如果系统里有几十个接口都在改同一张表，漏掉一个就是隐患。我见过不少项目就是因为在某个不起眼的状态更新接口里忘写了ES，导致线上数据对不上，排查了很久才发现是漏同步。
所以我的建议是：双写方案用于核心链路、低频写入、对一致性要求苛刻的场景，并且一定要配合日志补偿表兜底，绝对不能裸奔。如果并发量上来了，或者写入口太多、维护不过来，就要尽快切到下面两种方案。
4. 方案二：消息队列异步同步，用解耦换实时性
4.1 架构和基本流程
消息队列方案的思路是把同步动作从业务主流程里剥离出来：业务只负责写MySQL，写入成功后发送一条消息到MQ，独立的同步消费者拉取消息后写入ES。整体流程如下：
- 业务请求更新MySQL，事务提交成功。
- 业务将变更事件以消息的形式发送到消息队列。
- 同步服务消费消息，解析出需要同步的数据，写入ES。
- 消息消费成功后确认，失败则重试。
这样做的好处是：写ES的耗时不再占用主请求链路，即使ES短暂抖动，消息也会堆积在MQ里，恢复后继续消费，不会直接导致线上接口不可用。同时，业务代码只需要关心“发消息”，不需要关心ES的写入细节，同步逻辑被解耦到独立的服务里。
// 业务侧：只关注MySQL更新和消息发送 @Transactional public void updateGoods(Goods goods) { goodsMapper.updateById(goods); syncMessageSender.send(new GoodsSyncMessage(goods)); } // 同步消费侧：专注ES写入 @Component public class GoodsSyncConsumer { @RabbitListener(queues = "goods.sync.queue") public void onMessage(GoodsSyncMessage message) { Goods goods = queryLatestDataFromMySQL(message.getGoodsId()); goodsEsMapper.saveDocument(goods); } }4.2 三个必须处理的异常场景
MQ方案虽然解耦了链路，但它把一致性问题从“双写失败”转移到了消息处理的三个细节上，处理不好同样会出乱子。
第一个是消息丢失。如果业务成功写MySQL后，发送消息时网络异常或MQ宕机，这条同步消息就丢了。解决的思路和双写补偿一样，可靠性要求高的场景也引入本地消息表，或者要求MQ生产者开启确认机制，发送失败时记录日志，由补偿任务重发。千万不要以为把消息丢进MQ就万事大吉了，消息从业务服务到Broker再到消费者，每一跳都有丢失的可能。
第二个是消息重复消费。MQ通常只保证至少一次投递，也就是消费者可能收到重复消息。消费端必须做幂等：要么在ES写入前先按主键查询，已存在就更新，要么用业务主键做唯一标识去重。更简单的做法是，把ES文档的_id直接设置成MySQL主键，同一个_id写入多次，其实就是覆盖更新，天然幂等。
第三个是消息乱序。同一个商品被改了两次，消息在老版本还没有被消费时，新版本的消费先执行了，之后老版本消息到达，就会用旧数据覆盖新数据。解决这个问题的办法是在消息里带上业务数据的版本号或更新时间戳，消费端在写入前比较版本号，只有更大版本的更新才允许写入，否则丢弃。
if (message.getUpdateTime() <= currentEsDoc.getUpdateTime()) { return; // 老消息，丢弃 }这三个问题处理完，MQ方案才算真正达到可以上生产的可靠水平。
4.3 实用优化建议
在使用MQ方案时，有几个小细节值得注意。
消息体里不要只封装整条业务数据，尽量只带主键信息，消费者拿到主键后再去MySQL查最新数据，这样能避免消息体里携带的是旧值。因为从业务写MySQL到消费者真正执行写入之间往往有几秒的延迟，如果消息体里带着快照数据，期间如果有新变更，消费者写入的就是过期数据。只带主键、消费时再查一次库，能极大减少这种旧值覆盖的问题。
另外，建议把同步消费端的并发数和ES集群的写入吞吐对齐。消费者并发太大，容易把ES打爆，触发write队列满或拒绝请求；并发太小，堆积严重。一般做法是先小规模压测，找出ES集群能承受的写入速率，再据此配置消费并发。
这套方案的适用场景是：业务并发中高、写入口较多、希望把同步链路和业务解耦、对实时性要求达到秒级左右的系统。它比双写方案干净，又比Binlog方案简单，属于比较均衡的选择。
5. 方案三：Binlog订阅同步，从数据库底层解决问题
5.1 Binlog同步的原理
如果说前两种方案是从应用层硬搭一座桥，那Binlog订阅就是从MySQL自身的运行机制里找到一条通道。MySQL的主从复制之所以能实现，靠的就是Binlog——主库把每一次数据变更以日志形式写下来，从库拉取这些日志重放到本地。Binlog订阅方案的核心思想就是把自己伪装成一个MySQL从库，去订阅主库的Binlog，然后解析出变更事件，重新组装成ES的写入动作。
这条思路的巧妙之处在于：它完全不侵入业务代码。业务方不需要在自己逻辑里发消息、写日志表，凡是写MySQL的操作，都会被Binlog忠实地记录下来，不存在漏同步的问题。这对那种“历史遗留系统改不动代码、但是希望新增搜索能力”的场景特别适用。
5.2 位点管理和幂等设计
用Binlog方案，有两个问题必须小心，处理不好会翻车。
第一个是消费位点管理。Binlog是顺序追加的日志流，消费者必须记录自己消费到了哪个位置（位点），重启之后才能从这个位置继续消费。如果位点记录错误或丢失，可能导致两种情况：重复消费或者数据丢失。解决思路是让同步服务定期把当前消费位点上报到MySQL或系统表里，启动时先加载上次的位点。我第一次自建这类组件时，就是没处理好位点持久化，重启后从最新位点开始消费，结果丢失了重启期间的所有变更，后来花了整整半天补数据。
第二个是解析后的幂等写入。消费者从Binlog里解析出一条UPDATE事件时，这条事件通常只包含被修改的字段，以及数据库里更新的主键。你需要带着这个主键去MySQL查一次全量最新数据，再写入ES。如果不查库，直接用Binlog里的字段去更新ES，很容易漏掉那些没有被本次UPDATE修改但ES里需要保留的字段。所以比较稳妥的做法是：收到变更事件后，第一步永远是按主键去MySQL查最新状态，然后把完整文档写入ES。
5.3 实战中的架构取舍
实现Binlog订阅方案，通常有两种路径：一是基于一些已经封装好的开源Binlog客户端做二次开发，这些客户端已经处理了连接管理、位点存储、事件解析这些脏活，你只需要关注业务逻辑和最终的ES写入；二是从零开始用连接协议解析Binlog事件，这种方式适合深度定制，但工作量巨大，需要处理Binlog版本差异、事件格式变化、断线重连等问题，一般不建议小团队轻易尝试。
这个方案虽然好，但运维门槛也是四个方案里最高的。你需要额外部署同步服务，并做好监控：
- 消费位点积压监控。如果消费速度跟不上写入速度，位点会越拉越远，ES数据延迟越来越严重。
- Binlog解析异常告警。Binlog格式升级、字段类型变化、DDL变更都可能导致解析报错，要及时发现处理。
- 同步延迟指标。通常我们期望秒级以内，如果延迟分钟级以上就要排查原因。
这套方案最适用的场景是：数据表多、写入来源杂、业务代码已经无法轻易改动、需要统一且稳定地同步大量表到ES的大中型系统。它的成本比较高，但换来的是一劳永逸的可靠性和可维护性。
6. 方案四：定时全量+增量扫描，简单可靠但有时效代价
6.1 时间戳增量策略
定时扫描是很多数据量不大、对实时性要求不高的项目最后的兜底选项。它的做法是给业务表增加一个update_time字段，同步任务每隔一段时间扫描一批更新时间大于上次游标的数据，把它们同步到ES。
SELECT * FROM goods WHERE update_time > #{lastSyncTime} ORDER BY update_time ASC LIMIT 1000;这个SQL看似简单，实际落地时有一个很常见的坑：如果业务表正好在扫描范围内出现了并发更新，更新操作晚于扫描起始时间但早于本批次查询结束时间，同时这条记录的update_time又恰好落在当前批次的边界附近，那么这一轮可能扫不到这条数据，下一轮扫描的起始游标已经越过它的更新时间，它就被永久漏掉了。解决方法是不要直接用“最大记录时间”作为游标，而是把startTime调整成当前批次最大时间往前偏移一段时间，用“带重叠窗口”的方式扫描，每次捞数据都留出几分钟的重叠区间，然后再按主键做去重。
6.2 尽量避免直接扫表
更稳妥地做增量同步，是在MySQL侧建一张版本表，或者给业务表增加一个版本号字段。每次业务变更时，版本号递增，同步任务查询版本号大于游标的数据。这比时间戳可靠一些，因为版本号是单调递增的，不会因为并发更新时间错乱产生漏扫。但缺点是业务代码又要改动，又回到侵入性的问题上去了。
我实际项目里还遇到过一个情况：业务数据实在太多，每次全量扫描把ES刷一遍太慢，于是改成增量扫描 + 定期全量快照。增量同步保证每日实时性，每周日夜里再做一次全量对比，把增量过程中因为漏扫、异常导致的不一致纠正过来。这种“兜底任务”的思路在运维实践中非常实用，即便主力同步已经用了Binlog方案，我也会保留一个低频率的全量对账任务，把它当作最后一道保险。
6.3 定时扫描方案的定位
定时扫描的优点是几乎不需要引入额外组件，只要一个定时任务框架就行，开发成本低，排查问题也直观。缺点是实时性差，分钟级甚至小时级都有可能，而且如果同步的数据量很大，每次扫描对数据库的压力也不容小觑。尤其当业务表中有几亿行数据时，即使加上了时间索引，扫描大量增量数据对MySQL主库来说也是不小的负担。
所以我的定位是：定时扫描要么作为低要求业务的数据同步主方案，要么作为其他同步方案的定期对账补偿。想靠它支撑秒级实时搜索，方向就错了。
7. 选型决策与排坑笔记
7.1 按业务场景怎么选
选型没有一个万能答案，但可以按下面几条经验去套。
- 写流量很小、团队人少、项目初期，直接双写 + 本地消息表兜底，最快见效。
- 写流量中等、已经上了MQ、希望解耦，用MQ异步同步，注意幂等和消息乱序。
- 存量系统代码改不动、或同步表很多、要求稳定统一管控，上Binlog订阅。
- 对实时性无要求、没有搜索压力、只做非核心数据的统计同步，定时扫描就好。
- 实际上很多成熟系统是“主从搭配”：Binlog订阅做实时主链路，定时任务做小时级对账。两条链路互不干扰，遇到数据不一致也能快速恢复。
7.2 实测中踩过的坑
这些年我在这条同步链路上踩过不少坑，挑几个典型的写在这里，希望能帮大家省点时间。
第一个是ES的写入异常处理和重试机制不能简单做“死循环重试”。如果ES集群本身出问题了，比如磁盘满了或者健康状态变红，你写一次失败一次，无脑重试只会把ES压得更惨。正确做法是设置最大重试次数，超过之后进入死信队列或失败表，暂停该批次，等ES恢复后再批量回放。
第二个是千万别忽略DDL变更。不管用哪种方案，MySQL表结构一旦发生变更，比如新增字段、修改字段类型，如果同步端没有跟着调整映射，轻则新字段同步不过去，重则解析报错导致整个同步链路中断。规范的做法是：发版流程里把同步管线的变更一起带上，并配备字段映射校验。
第三个是ES的_id生成策略不要乱换。一旦选定用MySQL主键做_id，就不要改成用UUID，不然历史数据全部变成新增，同一份业务数据在ES里出现两份，旧数据都成孤儿文档了。数据迁移必须先把映射规则定死。
第四个是做好全链路的可观测性。同步链路本质上是一个分布式异步流程，每跳都需要指标监控：MySQL写入延迟、MQ堆积数量、消费失败率、ES写入耗时和拒绝率。没有这些指标，出问题时就像大海捞针。我一般会在同步服务里埋一套计数器，把成功数、失败数、重试数、丢弃数都记下来，配合告警规则，数据一有分叉苗头就能提前发现。
7.3 最后说一点个人体会
我做过的项目里，真正能把四种方案用得恰到好处的团队并不多，多数情况是拿一种方案硬扛所有场景。其实同步方案的选取是一件动态演进的事情，项目初期数据量小，双写就够了，等项目变大了，再慢慢演进到MQ甚至Binlog。最怕的不是方案不先进，而是方案和业务规模严重错配。架构设计不能光看技术选型是否酷炫，还得看团队是否hold得住，监控是否跟得上。
如果你正在为这个同步问题发愁，我个人的建议是：先画出你的变更链路，统计一下每天对MySQL的写请求量和可接受的同步延迟，再回头对照上面的表，基本就能锁定适合的方案。如果看完还是不确定，那就先用最稳妥的“Binlog订阅 + 定时对账”组合，虽然前期辛苦一点，但它是各种规模下最不容易出大乱子的配置。找个周末把这个管线搭起来，你会发现后面加班排查同步问题的次数能少一大半。
