面试必问！MySQL 数据如何同步到 Elasticsearch？原来有这么多方案

概述

在实际的项目开发与运维过程中，MySQL 常常扮演着业务数据库的核心角色，以其强大的事务处理能力和数据完整性保障，支撑着系统的稳定运行。然而，随着数据量的急剧增长和查询复杂度的不断提升，单一依赖 MySQL 进行高效的数据检索显得日益吃力，尤其是在面对海量数据的复杂查询场景时，性能瓶颈愈发凸显。

为了有效缓解这一挑战，我们通常采用读写分离的策略，将 Elasticsearch（简称 ES）引入作为专门的查询数据库。ES 以其卓越的搜索性能、灵活的数据模式以及强大的可扩展性，成为处理复杂查询需求的理想选择。通过 ES，我们可以实现数据的快速检索与分析，从而大幅提升用户体验和系统响应速度。

在这一过程中，确保 MySQL 数据库与 ES 之间的数据同步成为了至关重要的一环。数据同步不仅关乎数据的实时性和准确性，更是保障系统稳定性和用户体验的基石。因此，我们需要精心设计与实施一套高效、可靠的数据同步方案。

具体而言，数据同步的实现方式多种多样，包括但不限于使用 Logstash、Kafka Connect、Debezium 等工具进行实时数据捕获与传输，或通过定时任务（如 Cron Job）结合 SQL 查询与批量导入的方式实现数据的定期同步。在选择同步方案时，我们需要综合考虑数据的实时性要求、系统架构的复杂度、运维成本以及数据的增量更新特性等因素。

同步方案

1. 同步双写

同步双写是一种数据同步策略，它指的是在主数据库（如 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 中以支持复杂的搜索和分析需求。

2. 异步双写

异步双写也是一种数据同步策略，它允许在主数据库（如 MySQL）进行数据修改操作时，异步地将这些修改写入到多个数据源（如 ES）中。与同步双写相比，异步双写具有降低主数据库写入延迟、提高系统性能以及避免因备库问题而影响主库性能等优点。

图片

优缺点

• 优点

  提高系统可用性：即使备库出现问题，也不会影响主库的正常运行和数据写入

  降低主库写入延迟：由于不需要等待备库确认，主库可以更快地完成写入操作，从而提高系统的整体性能

  多数据源同步：多源写入之间相互隔离，便于扩展更多的数据源写入

• 缺点

  硬编码问题：接入新的数据源需要实现新的消费者代码

  系统复杂度增加：需要额外引入了消息中间件

  实时性较低：由于 MQ 是异步消费模型，用户写入的数据不一定可以马上看到，消息挤压等会造成延时

  数据一致性风险：由于存在异步处理的时间差，可能会出现主库和备库之间数据暂时不一致的情况。因此，需要采取适当的措施来确保数据的最终一致性。

应用场景

异步双写适用于对数据一致性要求不是特别高但对系统性能要求较高的场景。例如，在电商平台中，可以将用户订单信息、商品库存等关键数据实时同步到主数据库中，同时将一些非关键数据（如用户浏览记录、商品点击量等）异步地同步到备数据库中用于数据分析。这样可以在保证关键数据一致性的同时提高系统的整体性能。

3. Logstash 同步

Logstash 是一个开源的服务器端数据处理管道，可以同时从多个来源采集数据，转换数据，然后将数据发送到您指定的存储库中。在实现 MySQL 数据库和 Elasticsearch 之间的数据同步时，Logstash 可以发挥重要作用。

图片

优缺点

• 优点

  不改变原代码，没有侵入性、没有硬编码

  没有业务强耦合，不改变原来程序的性能

• 缺点

  时效性较差，由于是采用定时器根据固定频率查询表来同步数据，尽管将同步周期设置到秒级，也还是会存在一定时间的延迟

  对数据库有一定的轮询压力，一种改进方法是将轮询放到压力不大的从库上

  无法实现同步删除，需要在 Elasticsearch 中执行相关命令手动删除

  Elasticsearch 中的_id 字段必须与 MySQL 中的 id 字段相同

4. Binlog 实时同步

Binlog 实时同步是一种数据库同步技术，主要用于实时捕获并同步数据库中的变更数据。

图片

Binlog（Binary Log）是 MySQL 等数据库的一种二进制日志，它记录了数据库中所有更改数据的 SQL 语句信息，但不包括查询操作。这些变更包括数据的插入、更新、删除等。Binlog 主要用于数据库的主从复制和数据恢复。

同步原理

Binlog 实时同步的原理基于数据库的复制机制。当数据库发生变更时，这些变更会被写入到 Binlog 中。同步工具（如 Canal、Maxwell 等）会监听 Binlog 的变动，实时捕获这些变更数据，并将其同步到其他数据库或存储系统中。

优缺点

• 优点

  实时性：能够实时捕获和同步数据库的变更数据

  一致性：确保源数据库和目标数据库之间数据的一致性

  灵活性：支持多种数据库和存储系统之间的同步

  可扩展性：可以根据业务需求进行扩展和定制

  没有代码侵入、没有硬编码，原有系统不需要任何变化，没有感知

• 缺点

  配置和维护同步工具可能具有一定的复杂性

  在高并发场景下，Binlog 的写入和同步可能会对数据库性能产生一定影响

  同步工具依赖于数据库的 Binlog 功能，如果数据库版本或配置发生变化，可能需要重新配置同步工具

5. Canal 数据同步

Canal 是阿里巴巴集团提供的一个开源产品，能够通过解析数据库的增量日志，提供增量数据的订阅和消费功能。Canal 的功能原理及详细说明请参见 Canal。使用 Canal 模拟成 MySQL 的 Slave，实时接收 MySQL 的增量数据 binlog，然后通过 RESTful API 将数据写入到阿里云 ES 实例或 ES Serverless 应用中，适用于对数据同步的实时性要求较高的场景。

同步原理

Canal 原理就是伪装成 MySQL 的从节点，从而订阅 master 节点的 Binlog 日志。通过订阅 binlog 的方式实现数据实时同步，在不影响源数据库的情况下，同步延迟可降至毫秒级别。

图片

同步流程

1. Canal 服务端向 MySQL 的 master 节点传输 dump 协议

2. MySQL 的 master 节点接收到 dump 请求后推送 binlog 日志给 Canal 服务端，解析 binlog 对象（原始为 byte 流）转成 Json 格式

3. Canal 客户端通过 TCP 协议或 MQ 形式监听 Canal 服务端，同步数据到 ES

执行核心流程

图片

• canal 模拟 mysql slave 的交互协议，伪装自己为 mysql slave，向 mysql master 发送 dump 协议

• mysql master 收到 dump 请求，开始推送 binary log 给 slave(也就是 canal)

• canal 解析 binary log 对象(原始为 byte 流)

5. 阿里云 DTS

数据传输服务 DTS（Data Transmission Service）是阿里云提供的实时数据流服务，支持关系型数据库（RDBMS）、非关系型的数据库（NoSQL）、数据多维分析（OLAP）等数据源间的数据交互，集数据同步、迁移、订阅、集成、加工于一体，助您构建安全、可扩展、高可用的数据架构。

相对于传统数据迁移或同步工具，DTS 为您提供功能更丰富、传输性能更强、易用性更高且安全可靠的服务，帮助您简化复杂的数据交互工作，专注于上层的业务开发。

系统架构

图片

架构特性

系统高可用数据传输服务内部每个模块都有主备架构，保证系统高可用。容灾系统实时检测每个节点的健康状况，一旦发现某个节点异常，会将链路快速切换到其他节点。

数据源地址动态适配对于数据订阅及同步链路，容灾系统还会监测数据源的连接地址切换等变更操作，一旦发现数据源发生连接地址变更，它会动态适配数据源新的连接方式，在数据源变更的情况下，保证链路的稳定性。

数据同步的工作原理

图片

DTS 可以在两个数据源之间同步正在进行的数据变更。数据同步通常用于 OLTP 到 OLAP 的数据传输。数据同步包括以下两个阶段：

• 同步初始化：DTS 先开始收集增量数据，然后将源数据库的结构和存量数据加载到目标数据库。

• 数据实时同步：DTS 同步正在进行的数据变更，并保持源数据库和目标数据库的同步。

DTS Serverless

DTS Serverless 实例是数据传输服务 DTS（Data Transmission Service）提供的资源规格可以弹性变化的实例。Serverless 实例可以适应不断变化的业务需求，使实例资源能够随业务规模的变化自动调整，从而避免资源浪费和控制运维成本。

Serverless 是一种动态计费方式，能够根据实例负载情况以分钟级别的动态调整资源，并实时计费（每小时生成一个收费订单），您仅需要为实际用量付费，从而节省大量成本。使用 Serverless 计费方式购买的实例，被称为 Serverless 实例。

Serverless 实例会根据 RPS（Records Per Second）、CPU、内存利用率、网络等因素动态调整资源规格，调整的资源规格以 DU（DTS Unit）数体现。在 DU 数调整后的 60 秒，系统会检测当前资源规格是否满足负载需求。

在数据传输量波动较大的场景下，普通实例和 Serverless 实例资源使用和规格变化情况如下图所示：

图片

由上图可以看到，在业务波动较大的场景下：

• 普通实例：在波谷期浪费的资源较多，在高峰期资源不足，业务受损。

• Serverless 实例：实例的资源规格随负载需求动态调整，在波谷期和高峰期都能完全满足业务需求，保证业务不受损。