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
等。在选择同步方案时，我们需要综合考虑数据的实时性要求、系统架构的复杂度、运维成本以及数据的增量更新特性等因素。
