本文详述了 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中。同步工具（如Canal、Maxwell等）会监听Binlog的变动，实时捕获这些变更数据，并将其同步到其他数据库或存储系统中。

流程如下：

• 给mysql开启binlog功能。
• mysql完成增、删、改操作都会记录在binlog中。
• hotel-demo基于canal监听binlog变化，实时更新elasticsearch中的内容。

如何选择？

方式一：同步调用

优点：

• 业务逻辑编写简单
• 业务查询实时性高

缺点：

• 业务硬编码，有需要写入 MySQL 的地方都需要添加写入 ES 的代码
• 业务代码强耦合度很高
• 存在双写失败丢数据风险
• 双写性能较差，本来 MySQL 的性能不是很高，再加一个 ES，系统的性能必然会下降

方式二：异步通知

优点：

• 提高系统可用性：即使备库出现问题，也不会影响主库的正常运行和数据写入
• 降低主库写入延迟：由于不需要等待备库确认，主库可以更快地完成写入操作，从而提高系统的整体性能
• 多数据源同步：多源写入之间相互隔离，便于扩展更多的数据源写入

缺点：

• 硬编码问题：接入新的数据源需要实现新的消费者代码
• 系统复杂度增加：需要额外引入了消息中间件
• 实时性较低：由于MQ是异步消费模型，用户写入的数据不一定可以马上看到，消息挤压等会造成延时
• 数据一致性风险：由于存在异步处理的时间差，可能会出现主库和备库之间数据暂时不一致的情况。因此，需要采取适当的措施来确保数据的最终一致性。

方式三：监听binlog

优点：

• 实时性：能够实时捕获和同步数据库的变更数据
• 一致性：确保源数据库和目标数据库之间数据的一致性
• 灵活性：支持多种数据库和存储系统之间的同步
• 可扩展性：可以根据业务需求进行扩展和定制
• 没有代码侵入、没有硬编码，原有系统不需要任何变化，没有感知

缺点：

• 配置和维护同步工具可能具有一定的复杂性
• 在高并发场景下，Binlog的写入和同步可能会对数据库性能产生一定影响
• 同步工具依赖于数据库的Binlog功能，如果数据库版本或配置发生变化，可能需要重新配置同步工具

总结

数据同步的实现方式多种多样，有以上我们介绍的同步调用、异步通知及监听binlog等。在选择同步方案时，我们需要综合考虑数据的实时性要求、系统架构的复杂度、运维成本以及数据的增量更新特性等因素。