1.同步双写方案
在代码中对数据库和ES进行双写操作,确保先更新数据后更新ES。
优点:
- 数据一致性:双写策略可以保证在MySql和Elasticsearch之间数据的强一致性,因为每次数据库的变更都会在Elasticsearch同步反映。
- 实时性:双写策略可以实现数据的实时同步,用户在MySql中进行的任务操作都会立即在ElasticSearch中体现。
- 易于实现:从技术角度来说,双写策略的实现相对简单,通常只需要在程序代码中添加额外的写入逻辑。
缺点:
- 代码复杂性:需要在应用程序中增加额外的处理数据的双写,这会增加代码的复杂性和维护难度。
- 性能开销:每次数据操作都需要执行两次,这会导致额外的性开销,龙其是在高并发的场景下。
- **为据不一致风险:**在双写过程中,如果发生系统故障或网络延迟,可能会出现数据不一致的情况,龙其是在写入MySql成功但写入ES失败时。
应用场景:
- 系统特点:旧系统年限长,单体架构且技术比较落后,如果引入es之外的其他中间件治理成很高,可以考虑这个方案。
- 业务场景:用户量少、偏后台管理类的系统,对数据同步的实时性要求很高,接近实时。
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中间件成本不高。
- 业务场景:互联网公司,用户体量大、大型多中心组织、高并发场景,业务上允许有一定的延迟(秒级)