1.同步双写方案

在代码中对数据库和ES进行双写操作，确保先更新数据后更新ES。
优点：

1. 数据一致性：双写策略可以保证在MySql和Elasticsearch之间数据的强一致性，因为每次数据库的变更都会在Elasticsearch同步反映。
2. 实时性：双写策略可以实现数据的实时同步，用户在MySql中进行的任务操作都会立即在ElasticSearch中体现。
3. 易于实现：从技术角度来说，双写策略的实现相对简单，通常只需要在程序代码中添加额外的写入逻辑。

缺点：

1. 代码复杂性：需要在应用程序中增加额外的处理数据的双写，这会增加代码的复杂性和维护难度。
2. 性能开销：每次数据操作都需要执行两次，这会导致额外的性开销，龙其是在高并发的场景下。
3. **为据不一致风险：**在双写过程中，如果发生系统故障或网络延迟，可能会出现数据不一致的情况，龙其是在写入MySql成功但写入ES失败时。

应用场景：

1. 系统特点：旧系统年限长，单体架构且技术比较落后，如果引入es之外的其他中间件治理成很高，可以考虑这个方案。
2. 业务场景：用户量少、偏后台管理类的系统，对数据同步的实时性要求很高，接近实时。

2.MQ异步双写方案

应用程序在更新数据库后发送消息到MQ，由MQ的消费者异步更新ES。

方案核心:

• 生产者端双写：生产者系统在发送消息到MQ的同时，也写入到MySql。

• 消费者端异步处理：消费者从MQ中读取消息，并异步地将消息处理结果写入到ES。

  优点：

• 系统解藕：MQ的使用使得MySQL和ES之间的依赖性降低，提高了系统的可难搞性和扩展性。

• 高可用性：MQ可以提供消息的持久化存储，确保即使系统故障，消息也不会丢失。

• 容错性：**在双写过程中，即使某个系统出现故障，数据仍然可以通过其他系统恢复。

  应用场景：

• 用户量大，高并发场景：系统服务的大量用户同时进行操作，导致系统面临高并发压力。

• 业务变更少：业务逻辑变更相对较少，数据同步的需比较稳定。

• 允许一定的延迟：在保证用户体验的前提下，数据同步的延迟在秒级范围内是可以接受的。

3.扫表定时同步方案

通过定时任务定期扫描数据库，将变更的数据同步到ES。
优点：

• 实现简单：使用定时任务调试框架，不需要复杂的开发工作。

• 适合批量数据：对于大量数据的迁移，批量处理可以减少网络传输次数和ES的写入压力。

• 对业务影响小：定时任务可以在系统负载较低的时段运行，对在线业务影响较小。

  缺点：

• 实时性差：由于是定期执行，数据同步存在延迟，不适合对实时性要求高的应用。

• 性能影响：同步过程中可能会对MySQL和ES的性能产生短期影响，尤其是在数据量大时。

• 数据一致性:如果在同步周期内数据发生变化，可能会导致ES中数据与MySql不一致。

  应用场景：

• 系统特点：旧系统年限长、技术框架老旧，引入其他的中间件成本很高。

• 业务场景：用户体量小、偏报表统计类业务、对数据实时性要求不高。

4.监听binlog同步方案

通过直接监听MqSql的binlog来实现数据库和ES之间的实时同步。

优点：

• 业务无侵入，数据同步准时
• 业务解藕，不需要关注原来系统的业务逻辑

缺点：

• 构建Binlog系统复杂
• 如果采用MQ消费解析的Binlog信息，也会像方案二一样存在MQ延时的风险。

应用场景

• 系统特点：C端系统，开放mysql binlog日志监听，引入第三方canal中间件成本不高。
• 业务场景：互联网公司，用户体量大、大型多中心组织、高并发场景，业务上允许有一定的延迟(秒级)