在实际的项目开发与运维过程中，MySQL 常常扮演着业务数据库的核心角色，以其强大的事务处理能力和数据完整性保障，支撑着系统的稳定运行。然而，随着数据量的急剧增长和查询复杂度的不断提升，单一依赖 MySQL 进行高效的数据检索显得日益吃力，尤其是在面对海量数据的复杂查询场景时，性能瓶颈愈发凸显。
为了有效缓解这一挑战，我们通常采用读写分离的策略，将 Elasticsearch（简称 ES）引入作为专门的查询数据库。ES 以其卓越的搜索性能、灵活的数据模式以及强大的可扩展性，成为处理复杂查询需求的理想选择。通过 ES，我们可以实现数据的快速检索与分析，从而大幅提升用户体验和系统响应速度。
在这一过程中，确保 MySQL 数据库与 ES 之间的数据同步成为了至关重要的一环。数据同步不仅关乎数据的实时性和准确性，更是保障系统稳定性和用户体验的基石。因此，我们需要精心设计与实施一套高效、可靠的数据同步方案。
具体而言，数据同步的实现方式多种多样，包括但不限于使用 Logstash、Kafka Connect、Debezium 等工具进行实时数据捕获与传输，或通过定时任务（如 Cron Job）结合 SQL 查询与批量导入的方式实现数据的定期同步。在选择同步方案时，我们需要综合考虑数据的实时性要求、系统架构的复杂度、运维成本以及数据的增量更新特性等因素。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
- 项目地址：https://github.com/YunaiV/ruoyi-vue-pro
- 视频教程：https://doc.iocoder.cn/video/
同步双写是一种数据同步策略，它指的是在主数据库（如MySQL）上进行数据修改操作时，同时将这些修改同步写入到ES中。这种策略旨在确保两个数据库之间的数据一致性，并优化系统的读写性能。
同步双写是指在进行数据写入操作时，同时向两个或多个数据库写入相同的数据。在MySQL与ES的同步场景中，其主要目的是将MySQL中的业务数据实时同步到ES中，以便利用ES的高效查询能力来应对复杂的查询需求，同时减轻MySQL的查询压力。
直接同步
在业务代码中，每次对MySQL数据库进行写入操作时，同时执行对ES的写入操作。这种方式简单直接，但可能增加代码的复杂性和出错的风险。
使用中间件
利用消息队列（如Kafka）、数据变更捕获工具（如Debezium）或ETL工具（如Logstash）等中间件来捕获MySQL的数据变更事件，并将这些事件转发到ES进行同步。这种方式可以解耦业务代码与数据同步逻辑，提高系统的可扩展性和可维护性。
触发器与存储过程
在MySQL中设置触发器或编写存储过程，在数据发生变更时自动触发ES的写入操作。这种方式可以减少业务代码的侵入性，但可能会增加MySQL的负担并影响性能。
- 业务硬编码，有需要写入 MySQL 的地方都需要添加写入 ES 的代码
- 双写性能较差，本来 MySQL 的性能不是很高，再加一个 ES，系统的性能必然会下降
同步双写策略适用于对数据一致性要求较高且需要优化查询性能的场景。例如，在电商系统中，可以将商品信息、订单数据等存储在MySQL中，同时将这些数据同步到ES中以支持复杂的搜索和分析需求。
异步双写也是一种数据同步策略，它允许在主数据库（如MySQL）进行数据修改操作时，异步地将这些修改写入到多个数据源（如ES）中。与同步双写相比，异步双写具有降低主数据库写入延迟、提高系统性能以及避免因备库问题而影响主库性能等优点。
- 提高系统可用性：即使备库出现问题，也不会影响主库的正常运行和数据写入
- 降低主库写入延迟：由于不需要等待备库确认，主库可以更快地完成写入操作，从而提高系统的整体性能
- 多数据源同步：多源写入之间相互隔离，便于扩展更多的数据源写入
- 实时性较低：由于MQ是异步消费模型，用户写入的数据不一定可以马上看到，消息挤压等会造成延时
- 数据一致性风险：由于存在异步处理的时间差，可能会出现主库和备库之间数据暂时不一致的情况。因此，需要采取适当的措施来确保数据的最终一致性。
异步双写适用于对数据一致性要求不是特别高但对系统性能要求较高的场景。例如，在电商平台中，可以将用户订单信息、商品库存等关键数据实时同步到主数据库中，同时将一些非关键数据（如用户浏览记录、商品点击量等）异步地同步到备数据库中用于数据分析。这样可以在保证关键数据一致性的同时提高系统的整体性能。
Logstash 是一个开源的服务器端数据处理管道，可以同时从多个来源采集数据，转换数据，然后将数据发送到您指定的存储库中。在实现 MySQL 数据库和 Elasticsearch 之间的数据同步时，Logstash 可以发挥重要作用。
- 时效性较差，由于是采用定时器根据固定频率查询表来同步数据，尽管将同步周期设置到秒级，也还是会存在一定时间的延迟
- 对数据库有一定的轮询压力，一种改进方法是将轮询放到压力不大的从库上
- 无法实现同步删除，需要在Elasticsearch中执行相关命令手动删除
- Elasticsearch中的_id字段必须与MySQL中的id字段相同
Binlog实时同步是一种数据库同步技术，主要用于实时捕获并同步数据库中的变更数据。
免翻官方ChatGPT 4.0 和 Claude Pro，稳定有售后
Binlog（Binary Log）是MySQL等数据库的一种二进制日志，它记录了数据库中所有更改数据的SQL语句信息，但不包括查询操作。这些变更包括数据的插入、更新、删除等。Binlog主要用于数据库的主从复制和数据恢复。
Binlog实时同步的原理基于数据库的复制机制。当数据库发生变更时，这些变更会被写入到Binlog中。同步工具（如Canal、Maxwell等）会监听Binlog的变动，实时捕获这些变更数据，并将其同步到其他数据库或存储系统中。
- 一致性 ：确保源数据库和目标数据库之间数据的一致性
- 没有代码侵入、没有硬编码，原有系统不需要任何变化，没有感知
- 在高并发场景下，Binlog的写入和同步可能会对数据库性能产生一定影响
- 同步工具依赖于数据库的Binlog功能，如果数据库版本或配置发生变化，可能需要重新配置同步工具
Canal是阿里巴巴集团提供的一个开源产品，能够通过解析数据库的增量日志，提供增量数据的订阅和消费功能。Canal的功能原理及详细说明请参见Canal。使用Canal模拟成MySQL的Slave，实时接收MySQL的增量数据binlog，然后通过RESTful API将数据写入到阿里云ES实例或ES Serverless应用中，适用于对数据同步的实时性要求较高的场景。
Canal 原理就是伪装成 MySQL 的从节点，从而订阅 master 节点的 Binlog 日志。通过订阅binlog的方式实现数据实时同步，在不影响源数据库的情况下，同步延迟可降至毫秒级别。
- Canal 服务端向 MySQL 的 master 节点传输 dump 协议
- MySQL 的 master 节点接收到 dump 请求后推送 binlog 日志给 Canal 服务端，解析 binlog 对象（原始为byte流）转成 Json 格式
- Canal 客户端通过 TCP 协议或 MQ 形式监听 Canal 服务端，同步数据到ES
- canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议
