Java八股文之Spring Boot 中解决 MySQL 和 Elasticsearch (ES) 的数据一致性问题

在 Spring Boot 中解决 MySQL 和 Elasticsearch (ES) 的数据一致性问题，核心在于放弃对强一致性的追求，转而采用"最终一致性"的架构思想。

这是因为 ES 本身不支持 ACID 事务，强行在业务代码中实现双写事务会带来性能瓶颈和复杂的异常处理。因此，我们需要引入异步、解耦的机制来保障数据的最终一致。

以下是几种在 Spring Boot 项目中主流且成熟的解决方案及其对比：

方案	核心原理	实时性	业务侵入性	复杂度	适用场景
同步双写	在同一个业务方法中，同时写入 MySQL 和 ES。	高	高	低	数据量小、对实时性要求极高，且能容忍一定不一致风险的简单场景。
异步双写 (MQ)	MySQL 写入成功后，发送消息到 MQ，由消费者异步写入 ES。	中	中	中	最推荐的主流方案，适用于大多数需要平衡性能、解耦和一致性的业务场景。
定时任务	定期扫描 MySQL 中发生变更的数据，批量同步到 ES。	低 (分钟级)	低	低	对实时性要求不高，数据变更不频繁的场景，如报表统计、历史数据迁移。
CDC (如 Canal)	伪装成 MySQL 从库，解析其 binlog 日志，捕获数据变更并同步到 ES。	高 (准实时)	极低	高	对实时性要求高，且希望彻底解耦，零业务侵入的场景，如核心交易数据的搜索。

这是最直接的方式，在 @Transactional 方法中同时操作 MySQL 和 ES。

一致性风险：最大的问题是，如果 ES 写入失败，MySQL 事务已提交，就会导致数据不一致。
如何保障 ：通常需要在 ES 写入失败时，手动抛出运行时异常来回滚 MySQL 事务 。但这会导致业务失败，且无法处理 ES 偶尔的网络超时等问题。另一种方式是记录失败日志，再由补偿任务处理。

这种方式将写入 ES 的操作与主业务解耦，是平衡性能与一致性的最佳实践。

核心流程 ：
1. 业务服务更新 MySQL。
2. 发送一条包含数据变更信息的消息到消息队列（如 RabbitMQ、Kafka）。
3. 独立的消费者服务消费消息，并更新 ES。
一致性保障 ：
- 最终一致性：允许 MySQL 和 ES 存在短暂的不一致，通过后续的异步操作保证最终一致。
- 消息可靠消费：消费者需开启 MQ 的手动 ACK 机制，确保消息被成功处理后才确认，防止消息丢失。
- 幂等性设计 ：消费者必须支持幂等处理，因为消息可能因网络问题被重复投递。例如，使用数据的唯一 ID 进行 upsert（更新或插入）操作。
- 异常与重试：ES 写入失败时，消息不应被确认，应重新入队等待重试，并设置重试次数上限和死信队列。

通过 @Scheduled 注解或 Quartz 等框架，定期将 MySQL 中变更的数据同步到 ES。

核心流程 ：维护一个 last_sync_time，每次任务查询 update_time > last_sync_time 的数据进行同步。
一致性保障 ：
- 最终一致性：存在分钟级甚至更长的延迟。
- 可靠性：需要处理好任务执行的监控和失败重试，防止因任务中断导致数据漏同步。

使用 Canal、Debezium 等工具，通过解析 MySQL 的 binlog 来实现数据同步，对业务代码零侵入。

核心流程 ：
1. Canal 等工具模拟成 MySQL 从库，实时获取 binlog 变更事件。
2. 将变更事件解析后，可以直接写入 ES，或发送到 MQ 进行缓冲和消费。
一致性保障 ：
- 事务时序保证：Canal 能保证 binlog 事件的顺序，确保 ES 的更新顺序与 MySQL 一致。
- 最终一致性：Canal 本身提供了可靠的数据捕获机制，配合 MQ 的可靠消费和 ES 的幂等写入，能很好地保证最终一致性。
- 缺点：架构和运维相对复杂，需要独立部署 Canal 等服务。

无论选择哪种方案，幂等性设计 和失败的监控与补偿机制都是保证最终一致性的关键防线。