ElasticSearch 与 MYSQL 数据同步三种方案
2024-08-30科技
本文介绍 ElasticSearch 与 MYSQL 数据的三种同步方案以及它们的优缺点对比。
什么是数据同步?
Elasticsearch中的酒店数据来自于mysql数据库,因此mysql数据发生改变时,elasticsearch 也必须跟着改变,这个就是 elasticsearch与mysql之间的数据同步。
思路分析
常见的数据同步方案有三种:
同步调用
异步通知
监听binlog
方案一:同步调用
同步调用
基本步骤如下:
hotel-demo对外提供接口,用来修改elasticsearch中的数据。
酒店管理服务在完成数据库操作后,直接调用hotel-demo提供的接口。
方案二:异步通知
异步通知
流程如下:
hotel-admin对mysql数据库数据完成增、删、改后,发送MQ消息。
hotel-demo监听MQ,接收到消息后完成elasticsearch数据修改。
方案三:监听binlog
监听binlog
同步原理
Binlog实时同步的原理基于数据库的复制机制。当数据库发生变更时,这些变更会被写入到Binlog中。同步工具(如Canal、Maxwell等)会监听Binlog的变动,实时捕获这些变更数据,并将其同步到其他数据库或存储系统中。
流程如下:
给mysql开启binlog功能。
mysql完成增、删、改操作都会记录在binlog中。
hotel-demo基于canal监听binlog变化,实时更新elasticsearch中的内容。
如何选择?
方式一:同步调用
优点:
业务逻辑编写简单
业务查询实时性高
缺点:
业务硬编码,有需要写入 MySQL 的地方都需要添加写入 ES 的代码
业务代码强耦合度很高
存在双写失败丢数据风险
双写性能较差,本来 MySQL 的性能不是很高,再加一个 ES,系统的性能必然会下降
方式二:异步通知
优点:
提高系统可用性:即使备库出现问题,也不会影响主库的正常运行和数据写入
降低主库写入延迟:由于不需要等待备库确认,主库可以更快地完成写入操作,从而提高系统的整体性能
多数据源同步:多源写入之间相互隔离,便于扩展更多的数据源写入
缺点:
硬编码问题:接入新的数据源需要实现新的消费者代码
系统复杂度增加:需要额外引入了消息中间件
实时性较低:由于MQ是异步消费模型,用户写入的数据不一定可以马上看到,消息挤压等会造成延时
数据一致性风险:由于存在异步处理的时间差,可能会出现主库和备库之间数据暂时不一致的情况。因此,需要采取适当的措施来确保数据的最终一致性。
方式三:监听binlog
优点:
实时性:能够实时捕获和同步数据库的变更数据
一致性:确保源数据库和目标数据库之间数据的一致性
灵活性:支持多种数据库和存储系统之间的同步
可扩展性:可以根据业务需求进行扩展和定制
没有代码侵入、没有硬编码,原有系统不需要任何变化,没有感知
缺点:
配置和维护同步工具可能具有一定的复杂性
在高并发场景下,Binlog的写入和同步可能会对数据库性能产生一定影响
同步工具依赖于数据库的Binlog功能,如果数据库版本或配置发生变化,可能需要重新配置同步工具
总结
数据同步的实现方式多种多样,有以上我们介绍的
同步调用
、
异步通知
及
监听binlog
等。在选择同步方案时,我们需要综合考虑数据的实时性要求、系统架构的复杂度、运维成本以及数据的增量更新特性等因素。