MySQL | 实战 | 4 种将数据同步到ES方案
上周听到公司新同事分享 MySQL 同步数据到 ES 的方案，发现很故意思，感觉有必要将这块知识点再总结提炼一下，就有了这篇文章。1. 前言
在现实项目开发中，我们常常将 MySQL 作为业务数据库，ES 作为查询数据库，用来实现读写分离，缓解 MySQL 数据库的查询压力，应对海量数据的复杂查询。
这其中有一个很重要的问题，就是怎样实现 MySQL 数据库和 ES 的数据同步，今天和大家聊聊 MySQL 和 ES 数据同步的各种方案。
我们先看看下面 4 种常用的数据同步方案。
2. 数据同步方案
2.1 同步双写
这是一种最为简朴的方式，在将数据写到 MySQL 时，同时将数据写到 ES。
https://i-blog.csdnimg.cn/direct/ba74c29a2a7e47428f0c4bc977f7d85a.png
长处：
[*]业务逻辑简朴；
[*]及时性高。
缺点：
[*]硬编码，有必要写入 MySQL 的地方都必要添加写入 ES 的代码；
[*]业务强耦合；
[*]存在双写失败丢数据风险；
[*]性能较差，本来 MySQL 的性能不是很高，再加一个 ES，体系的性能一定会降落。
2.2 异步双写
针对多数据源写入的场景，可以借助 MQ 实现异步的多源写入。
https://i-blog.csdnimg.cn/direct/30238bf6545241ff9a1dc570ba1a25a0.png
长处：
[*]性能高；
[*]不易出现数据丢失问题，重要基于 MQ 消息的消费保障机制，比如 ES 宕机或者写入失败，还能重新消费 MQ 消息；
[*]多源写入之间相互隔离，便于扩展更多的数据源写入。
缺点：
[*]硬编码问题，接入新的数据源必要实现新的消费者代码；
[*]体系复杂度增长，引入了消息中心件；
[*]MQ是异步消费模型，用户写入的数据不一定可以马上看到，造成延时。
2.3 定时更新
上面两种方案中都存在硬编码问题，代码的侵入性太强，如果对及时性要求不高的情况下，可以考虑用定时器来处置惩罚：
[*]数据库的干系表中增长一个字段为 timestamp 的字段，任何 CURD 操作都会导致该字段的时间发生变革；
[*]原来程序中的 CURD 操作不做任何变革；
[*]增长一个定时器程序，让该程序按一定的时间周期扫描指定的表，把该时间段内发生变革的数据提取出来；
[*]逐条写入到 ES 中。
https://i-blog.csdnimg.cn/direct/f2bcc760a6374b35840dba1ca61741af.png
长处：
[*]不改变原来代码，没有侵入性、没有硬编码；
[*]没有业务强耦合，不改变原来程序的性能；
[*]Worker 代码编写简朴不必要考虑增删改查。
缺点：
[*]时效性较差，由于是采用定时器根据固定频率查询表来同步数据，只管将同步周期设置到秒级，也还是会存在一定时间的延迟；
[*]对数据库有一定的轮询压力，一种改进方法是将轮询放到压力不大的从库上。
经典方案：借助 Logstash 实现数据同步，其底层实现原理就是根据配置定期使用 SQL 查询新增的数据写入 ES 中，实现数据的增量同步。
2.4 基于 Binlog 及时同步
上面三种方案要么有代码侵入，要么有硬编码，要么有延迟，那么有没有一种方案既能保证数据同步的及时性又没有代入侵入呢？当然有，可以使用 MySQL 的 Binlog 来举行同步。
https://i-blog.csdnimg.cn/direct/9f46f77cf03b483a87a4c622d142a0f7.png
具体步骤如下：
[*]读取 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。
https://i-blog.csdnimg.cn/direct/6fdc1efc7c714c99b7cc1b4749a7a3d6.png
下面是 Cannel 执行的核心流程，其中 Binlog Parser 重要负责 Binlog 的提取、解析和推送，EventSink 负责数据的过滤 、路由和加工，仅作了解即可。
https://i-blog.csdnimg.cn/direct/543ef68c62924759987647f10351fa53.png
3.2 阿里云 DTS
数据传输服务 DTS（Data Transmission Service）支持 RDBMS、NoSQL、OLAP 等多种数据源之间的数据传输。
它提供了数据迁移、及时数据订阅及数据及时同步等多种数据传输方式。相对于第三方数据流工具，DTS 提供丰富多样、高性能、高安全可靠的传输链路，同时它提供了诸多便利功能，极大方便了传输链路的创建及管理。
特点：
[*]多数据源：支持 RDBMS、NoSQL、OLAP 等多种数据源间的数据传输；
[*]多传输方式：支持多种传输方式，包罗数据迁移、及时数据订阅及数据及时同步；
[*]高性能：底层采用了多种性能优化措施，全量数据迁移高峰期时性能可以达到70MB/s，20万的TPS，使用高规格服务器来保证每条迁移或同步链路都能拥有良好的传输性能；
[*]高可用：底层为服务集群，如果集群内任何一个节点宕机或发生故障，控制中心都能够将这个节点上的所有任务快速切换到其他节点上，链路稳定性高；
[*]简朴易用：提供可视化管理界面，提供向导式的链路创建流程，用户可以在其控制台简朴轻松地创建传输链路；
[*]必要付费。
再看看 DTS 的体系架构。
https://i-blog.csdnimg.cn/direct/d9f70a07157042f09d7d164e388329e4.png
[*]高可用：数据传输服务内部每个模块都有主备架构，保证体系高可用。容灾体系及时检测每个节点的康健状态，一旦发现某个节点异常，会将链路快速切换到其他节点。
[*]数据源地址动态适配：对于数据订阅及同步链路，容灾体系还会监测数据源的毗连地址切换等变动操作，一旦发现数据源发生毗连地址变动，它会动态适配数据源新的毗连方式，在数据源变动的情况下，保证链路的稳定性。
更多内容，请查看阿里官方文档：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。
https://i-blog.csdnimg.cn/direct/c290283b8e1740628abcecf5085aa708.png
[*]快速变革的消费者直接从 Relay 中取事件；
[*]如果一个消费者的数据更新大幅落伍，它要的数据就不在 Relay 的日志中，而是必要请求 Bootstrap 服务，返回的将会是自消费者前次处置惩罚变动之后的所有数据变动快照。
开源地址：https://github.com/linkedin/databus
3.4 Databus和Canal对比
https://i-blog.csdnimg.cn/direct/49b15262a0ad4f508d3a781c8107315a.png
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 和其它多维数据的同步方案，以及常用的数据迁移工具，帮助你更好选型。
写文章不是目的，最重要的是怎样应用到项目中。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]