请列举将 MySQL 中的数据同步到 Elasticsearch 的常见方案，并结合你在项目中的实际做法进行说明。

回答思路

1. 【回答框架 1】常见方案主要有四类。一是基于 MySQL 的 binlog 监听，通过 Canal、Maxwell 等中间件解析 binlog，再写入 Elasticsearch。这种方案实时性高，能捕获增量变更，但对运维有要求。二是使用 Logstash 等工具做全量或定时增量同步，通过 SQL 查询或 JDBC 输入插件拉取数据，适合数据量不大、实时性要求不高的场景。三是应用双写，在业务代码中同时写 MySQL 和 Elasticsearch，实现简单但存在一致性和重复代码问题。四是使用数据同步服务或云厂商的 DTS 等产品，减少自建成本。
2. 【回答框架 2】在项目中，我使用的是基于 Canal 的 binlog 同步方案。业务中 MySQL 是主存储，Elasticsearch 用于搜索和聚合。由于数据实时性要求高，且需要处理 delete 和 update，我选型 Canal 监听 MySQL 的 binlog，并将变更事件发送到 Kafka 作为缓冲，再由消费者程序解析并写入 Elasticsearch。这样能解耦生产者和消费者，避免大量写入时对 Elasticsearch 造成压力。
3. 【回答框架 3】在具体落地时，我设计了如下流程：MySQL binlog 被 Canal 捕获，Canal 把数据以 JSON 格式发到 Kafka 指定 topic，消费者从 Kafka 读取事件，根据事件类型（insert、update、delete）对 Elasticsearch 文档做相应处理。为了处理幂等性，我会在事件中加入业务主键和版本号，写入时使用 Elasticsearch 的 upsert 操作。对于删除操作，采用软删除（在文档中标记 deleted）或直接删除文档，根据业务需求决定。
4. 【回答框架 4】针对数据一致性和性能，我做了几项优化。一是开启 Canal 的并行解析和批量消费，提升吞吐。二是对写入 Elasticsearch 进行批量 bulk 操作，减少网络开销。三是针对更新频繁的字段，在业务侧合并短时间内的多次变更，减少无效写。四是设置合理的索引分片和副本，并根据查询模式设计 mapping，避免不必要的字段被索引。
5. 【回答框架 5】这个方案在当时满足了我们项目日增百万级数据、搜索响应在百毫秒内的要求。需要注意的是，binlog 同步方案只保证最终一致性，如果 MySQL 与 Elasticsearch 之间出现短暂不一致，需要定期对账或通过全量同步做校验。在选型时，如果项目对实时性要求不高且数据量小，使用 Logstash 会更简单；如果对实时性要求高，Canal 或 Maxwell 是主流选择。
6. 【关键点 1】Canal 基于 MySQL binlog 解析，可实现增量同步，实时性较高。
7. 【关键点 2】Kafka 作为消息缓冲，能削峰填谷，解耦 Canal 和写入 Elasticsearch 的消费者。
8. 【关键点 3】写入 Elasticsearch 时使用 upsert 操作，并利用业务主键或版本号保证幂等。
9. 【关键点 4】使用批量 bulk 写入可显著提升同步性能。
10. 【关键点 5】同步方案需注意最终一致性，定期对账可帮助发现并修复差异。
11. 【易错点 1】binlog 同步只能保证最终一致性，不能做到绝对实时一致，需评估业务对延迟的容忍度。
12. 【易错点 2】如果 MySQL 和 Elasticsearch 事务性要求高，双写方案容易导致数据不一致，但 binlog 方案无法解决业务层面的事务问题。
13. 【易错点 3】同步过程中需关注 binlog 的三种格式（row、statement、mixed），推荐使用 row 格式，否则某些更新事件可能无法捕获完整数据。