MySQL 实战 4 种将数据同步到ES方案

文章目次

• 1. 前言
  
• 2. 数据同步方案
  
• 
  
  
  
  • 2.1 同步双写
    
  • 2.2 异步双写
    
  • 2.3 定时更新
    
  • 2.4 基于 Binlog 及时同步
    
  
  
• 3. 数据迁徙工具选型
  
• 
  
  
  
  • 3.1 Canal
    
  • 3.2 阿里云 DTS
    
  • 3.3 Databus
    
  • 3.4 Databus和Canal对比
    
  • 3.4 别的
    
  
  
• 4. 跋文
  

上周听到公司新同事分享 MySQL 同步数据到 ES 的方案，发现很故意思，感觉有须要将这块知识点再总结提炼一下，就有了这篇文章。
1. 前言

在现实项目开发中，我们常常将 MySQL 作为业务数据库，ES 作为查询数据库，用来实现读写分离，缓解 MySQL 数据库的查询压力，应对海量数据的复杂查询。
这此中有一个很紧张的题目，就是怎样实现 MySQL 数据库和 ES 的数据同步，本日和各人聊聊 MySQL 和 ES 数据同步的各种方案。
我们先看看下面 4 种常用的数据同步方案。
2. 数据同步方案

2.1 同步双写

这是一种最为简单的方式，在将数据写到 MySQL 时，同时将数据写到 ES。

长处：

• 业务逻辑简单；
  
• 及时性高。
  缺点：
  
• 硬编码，有必要写入 MySQL 的地方都必要添加写入 ES 的代码；
  
• 业务强耦合；
  
• 存在双写失败丢数据风险；
  
• 性能较差，原来 MySQL 的性能不是很高，再加一个 ES，体系的性能肯定会降落。
  

2.2 异步双写

针对多数据源写入的场景，可以借助 MQ 实现异步的多源写入。

长处：

• 性能高；
  
• 不易出现数据丢失题目，紧张基于 MQ 消息的斲丧保障机制，比如 ES 宕机大概写入失败，还能重新斲丧 MQ 消息；
  
• 多源写入之间相互隔离，便于扩展更多的数据源写入。
  缺点：
  
• 硬编码题目，接入新的数据源必要实现新的斲丧者代码；
  
• 体系复杂度增长，引入了消息中心件；
  
• MQ是异步斲丧模子，用户写入的数据不肯定可以立即看到，造成延时。
  

2.3 定时更新

上面两种方案中都存在硬编码题目，代码的侵入性太强，如果对及时性要求不高的情况下，可以思量用定时器来处理惩罚：

• 数据库的干系表中增长一个字段为 timestamp 的字段，任何 CURD 利用都会导致该字段的时间发生变革；
  
• 原来步调中的 CURD 利用不做任何变革；
  
• 增长一个定时器步调，让该步调按肯定的时间周期扫描指定的表，把该时间段内发生变革的数据提取出来；
  
• 逐条写入到 ES 中。
  
  
  
  

长处：

• 不改变原来代码，没有侵入性、没有硬编码；
  
• 没有业务强耦合，不改变原来步调的性能；
  
• Worker 代码编写简单不必要思量增编削查。
  缺点：
  
• 时效性较差，由于是采取定时器根据固定频率查询表来同步数据，只管将同步周期设置到秒级，也还是会存在肯定时间的延长；
  
• 对数据库有肯定的轮询压力，一种改进方法是将轮询放到压力不大的从库上。
  

经典方案：借助 Logstash 实现数据同步，其底层实现原理就是根据设置定期使用 SQL 查询新增的数据写入 ES 中，实现数据的增量同步。
2.4 基于 Binlog 及时同步

上面三种方案要么有代码侵入，要么有硬编码，要么有延长，那么有没有一种方案既能包管数据同步的及时性又没有代入侵入呢？固然有，可以使用 MySQL 的 Binlog 来举行同步。

具体步调如下：

• 读取 MySQL 的 Binlog 日志，获取指定表的日志信息；
  
• 将读取的信息转为 MQ；
  
• 编写一个 MQ 斲丧步调；
  
• 不停斲丧 MQ，每斲丧完一条消息，将消息写入到 ES 中。
  长处：
  
• 没有代码侵入、没有硬编码；
  
• 原有体系不必要任何变革，没有感知；
  
• 性能高；
  
• 业务解耦，不必要关注原来体系的业务逻辑。
  缺点：
  
• 构建 Binlog 体系复杂；
  
• 如果采取 MQ 斲丧剖析的 Binlog 信息，也会像方案二一样存在 MQ 延时的风险。
  

3. 数据迁徙工具选型

对于上面 4 种数据同步方案，“基于 Binlog 及时同步”方案是现在最常用的，也诞生了许多良好的数据迁徙工具，这里紧张对这些迁徙工具举行先容。
这些数据迁徙工具，许多都是基于 Binlog 订阅的方式实现，模仿一个 MySQL Slave 订阅 Binlog 日志，从而实现 CDC（Change Data Capture），将已提交的更改发送到卑鄙，包罗 INSERT、DELETE、UPDATE。
3.1 Canal

基于数据库增量日志剖析，提供增量数据订阅&斲丧，现在紧张支持 MySQL。
Canal 原理就是伪装成 MySQL 的从节点，从而订阅 master 节点的 Binlog 日志，紧张流程为：

• Canal 服务端向 MySQL 的 master 节点传输 dump 协议；
  
• MySQL 的 master 节点汲取到 dump 哀求后推送 Binlog 日志给 Canal 服务端，剖析 Binlog 对象（原始为 byte 流）转成 Json 格式；
  
• Canal 客户端通过 TCP 协议或 MQ 情势监听 Canal 服务端，同步数据到 ES。
  
  
  
  下面是 Cannel 实验的核心流程，此中 Binlog Parser 紧张负责 Binlog 的提取、剖析和推送，EventSink 负责数据的过滤 、路由和加工，仅作相识即可。
  
  
  
  

3.2 阿里云 DTS

数据传输服务 DTS（Data Transmission Service）支持 RDBMS、NoSQL、OLAP 等多种数据源之间的数据传输。
它提供了数据迁徙、及时数据订阅及数据及时同步等多种数据传输方式。相对于第三方数据流工具，DTS 提供丰富多样、高性能、高安全可靠的传输链路，同时它提供了诸多便利功能，极大方便了传输链路的创建及管理。
特点：

• 多数据源：支持 RDBMS、NoSQL、OLAP 等多种数据源间的数据传输；
  
• 多传输方式：支持多种传输方式，包罗数据迁徙、及时数据订阅及数据及时同步；
  
• 高性能：底层采取了多种性能优化步调，全量数据迁徙高峰期时性能可以到达70MB/s，20万的TPS，使用高规格服务器来包管每条迁徙或同步链路都能拥有良好的传输性能；
  
• 高可用：底层为服务集群，如果集群内任何一个节点宕机或发生故障，控制中心都可以或许将这个节点上的全部使命快速切换到其他节点上，链路稳固性高；
  
• 简单易用：提供可视化管理界面，提供向导式的链路创建流程，用户可以在其控制台简单轻松地创建传输链路；
  
• 必要付费。
  

再看看 DTS 的体系架构。

• 高可用：数据传输服务内部每个模块都有主备架构，包管体系高可用。容灾体系及时检测每个节点的康健状态，一旦发现某个节点非常，会将链路快速切换到其他节点。
  
• 数据源所在动态适配：对于数据订阅及同步链路，容灾体系还会监测数据源的毗连所在切换等变动利用，一旦发现数据源发生毗连所在变动，它会动态适配数据源新的毗连方式，在数据源变动的情况下，包管链路的稳固性。
  更多内容，请检察阿里官方文档：https://help.aliyun.com/product/26590.html
  

3.3 Databus

Databus 是一个低延长、可靠的、支持变乱的、保持同等性的数据变动抓取体系。由 LinkedIn 于 2013 年开源。
Databus 通过发掘数据库日志的方式，将数据库变动及时、可靠的从数据库拉取出来，业务可以通过定制化 client 及时获取变动并举行其他业务逻辑。
特点：

• 多数据源：Databus 支持多种数据泉源的变动抓取，包罗 Oracle 和 MySQL。
  
• 可扩展、高度可用：Databus 能扩展到支持数千斲丧者和变乱数据泉源，同时保持高度可用性。
  
• 变乱按序提交：Databus 能保持泉源数据库中的变乱完备性，并按照变乱分组和泉源的提交顺寻交付变动变乱。
  
• 低延长、支持多种订阅机制：数据源变动完成后，Databus 能在毫秒级内将变乱提交给斲丧者。同时，斲丧者使用D atabus 中的服务器端过滤功能，可以只获取本身必要的特定命据。
  
• 无穷回溯：对斲丧者支持无穷回溯本领，比方当斲丧者必要产生数据的完备拷贝时，它不会对数据库产生任何额外负担。当斲丧者的数据大大落伍于泉源数据库时，也可以使用该功能。
  再看看 Databus 的体系架构。
  Databus 由 Relays、bootstrap 服务和 Client lib 等构成，Bootstrap 服务中包罗 Bootstrap Producer 和 Bootstrap Server。
  
  
  
  
• 快速变革的斲丧者直接从 Relay 中取变乱；
  
• 如果一个斲丧者的数据更新大幅落伍，它要的数据就不在 Relay 的日志中，而是必要哀求 Bootstrap 服务，返回的将会是自斲丧者前次处理惩罚变动之后的全部数据变动快照。
  开源所在：https://github.com/linkedin/databus
  

3.4 Databus和Canal对比

3.4 别的

Flink
● 有界数据流和无界数据流上举行有状态盘算分布式处理惩罚引擎和框架。
● 官网所在：https://flink.apache.org
CloudCanal
● 数据同步迁徙体系，贸易产物。
● 官网所在：https://www.clougence.com/utm_source=wwek
Maxwell
● 使用简单，直接将数据变动输出为json字符串，不必要再编写客户端。
● 官网所在：http://maxwells-daemon.io
DRD
● 阿里巴巴团体自主研发的分布式数据库中心件产物，专注于办理单构造系型数据库扩展性题目，具备轻量(无状态)、机动、稳固、高效等特性。
● 官方所在：https://www.aliyun.com/product/drds
yugong
● 资助用户完成从 Oracle 数据迁徙到 MySQL。
● 访问所在：https://github.com/alibaba/yugong
4. 跋文

通过这篇文章，让你知道 MySQL 和别的多维数据的同步方案，以及常用的数据迁徙工具，资助你更好选型。
写文章不是目的，最紧张的是怎样应用到项目中。