Elasticsearch数据同步方案
定时任务方案
比如 1 分钟 1 次，找到 MySQL 中过去几分钟内（至少是定时周期的 2 倍）发生改变的数据，然后更新到 ES。
优点：
- 简单易懂，开发、部署、维护相对容易。
- 占用资源少，不需要引入复杂的第三方中间件。
- 不用处理复杂的并发和实时性问题。
缺点：
- 有时间差：无法做到实时同步，数据存在滞后。
- 数据频繁变化时，无法确保数据完全同步，容易出现错过更新的情况。
- 对大数据量的更新处理不够高效，可能会引入重复更新逻辑。
应用场景：
- 数据实时性要求不高：适合数据短时间内不同步不会带来重大影响的场景。
- 数据基本不发生修改：适合数据几乎不修改、修改不频繁的场景。
- 数据容忍丢失
双写
写数据的时候，必须也去写 ES；更新删除数据库同理。
可以通过事务保证数据一致性，使用事务时，要先保证 MySQL 写成功，因为如果 ES 写入失败了，不会触发回滚，但是可以通过定时任务 + 日志 + 告警进行检测和修复（补偿）。
优点：
- 方案简单易懂，业务逻辑直接控制数据同步。
- 可以利用事务部分保证 MySQL 和 ES 的数据一致性。
- 同步的时延较短，理论上可以接近实时更新 ES。
缺点：
- 影响性能：每次写 MySQL 时，需要同时操作 ES，增加了业务写入延迟，影响性能。
- 一致性问题：如果 ES 写入失败，MySQL事务提交成功后，ES 可能会丢失数据；或者 ES 写入成功，MySQL 事务提交失败，ES无法回滚。因此必须额外设计监控、补偿机制来检测同步失败的情况（如通过定时任务、日志和告警修复）。
- 代码复杂度增加，需要对每个写操作都进行双写处理。
应用场景：
- 实时性要求较高
- 业务写入频率较低：适合写操作不频繁的场景，这样对性能的影响较小。
用 Logstash 数据同步管道
要配合 kafka 消息队列 + beats 采集器
优点：
- 配置驱动：基于配置文件，减少了手动编码，数据同步逻辑和业务代码解耦。
- 扩展性好：可以灵活引入 Kafka等消息队列实现异步数据同步，并可处理高吞吐量数据。
- 支持多种数据源：Logstash 支持丰富的数据源，方便扩展其他同步需求。
缺点：
- 灵活性差：需要通过配置文件进行同步，复杂的业务逻辑可能难以在配置中实现，无法处理细粒度的定制化需求。
- 引入额外组件，维护成本高：通常需要引入 Kafka、Beats 等第三方组件，增加了系统的复杂性和运维成本。
应用场景：
- 大数据同步：适合大规模、分布式数据同步场景。
- 对实时性要求不高：适合数据流处理或延迟容忍较大的系统。
- 系统已有 Kafka或类似的消息队列架构：如果系统中已经使用了 Kafka 等中间件，使用 Logstash 管道会变得很方便。
监听 MySQL Binlog
有任何数据变更时都能够实时监听到，并且同步到 Elasticsearch。一般不需要自己监听，可以使用现成的技术，比如 Canal 。
Canal 的核心原理：数据库每次修改时，会修改 binlog 文件，只要监听该文件的修改，就能第一时间得到消息并处理
优点：
- 实时性强：能够在 MySQL 数据发生变更的第一时间同步到 ES，做到真正的实时同步。
- 轻量级：Binlog是数据库自带的日志功能，不需要修改核心业务代码，只需要新增监听逻辑。
缺点：
- 引入外部依赖：需要引入像 Canal 这样的中间件，增加了系统的复杂性和维护成本。
- 运维难度增加：需要确保 Canal 或者其他Binlog 监听器的稳定运行，并且对 MySQL 的 Binlog 配置要求较高。
- 一致性问题：如果 Canal服务出现问题或暂停，数据可能会滞后或丢失，必须设计补偿机制。
应用场景：
- 实时同步要求高：适合需要实时数据同步的场景，通常用于高并发、高数据一致性要求的系统。
- 数据频繁变化：适合数据变更频繁且需要高效增量同步的场景。