MySQL开源数据传输中间件架构设计实践

本文根据洪斌10月27日在「3306π」技术 Meetup - 武汉站现场演讲内容整理而成。

主要内容：

本次分享将介绍目前数据迁移、数据同步、数据消费，多IDC架构中数据复制技术所面临问题及现有的产品和方案，并分享新开源的能在异构数据存储之间提供高性能和强大复制功能的DTLE相关技术内容。

提纲：

1. MySQL Replication

2. DTLE核心场景

3. DTLE设计原则

4. DTLE相关介绍（架构/集群机制/拓扑结构/技术栈/功能/限制）

5. Demo演示

6. 云间同步案例

大家好，我今天分享的主题是关于爱可生在前不久开源的数据传输中间件DTLE，也可简称为DTS。爱可生作为一家以MySQL为主的技术服务公司，在我们服务企业客户过程中，经常会遇到各种数据同步的需求，能做数据同步的软件很多，但未能找到满足我们所有需求的软件，所以我们决定自研一款数据传输软件，结合我们客户的需求场景做了DTLE，并选择在10月24号“程序员节”向社区开源。

今天主要是对DTLE的一些技术架构，跟大家分享。

 1. MySQL Replication 

MySQL如此受欢迎，其原因和MySQL原生支持了 Replication密不可分。基于replication能力社区也是玩出了各种拓扑架构。

 1.1 MySQL Replication架构

这张图对DBA们应该并不陌生，左边是MySQL主实例，右边是MySQL从实例，数据变更记录在binlog中。主实例的Dump线程，将binlog 事件通过网络推送给从实例。

从实例的IO线程将接收到事件写入本地relay log，SQL线程读取relay log bing进行回放执行，这是MySQL Replication的基本流程。

既然MySQL已经有了数据同步能力，那为何还要做DTLE呢？

 1.2 MySQL Replication的限制

· 筛选功能不足

MySQL Replication只能在库表级别做筛选，无法在行级别进行筛选。

· 数据落地，开销较大

MySQL Replication需要日志或数据落地，这会产生存储空间的开销。

· 灵活性较弱

无法支持较为复杂的复制拓扑结构，以及在跨网络边界不同数据中心场景的。

· 应用场景多为高可用

MySQL replication更多以高可用、读写分离应用场景为主，利用开源工具实现Master failover以及读写分离架构。

 2. DTLE的核心场景 

MySQL Replication主要应用在数据全同步的场景。而对于DTLE主要解决以下场景：

· 异地多活

异地多活的场景通常建立在网络环境不佳的条件下，我们通过数据压缩、加密、限速等方法，保障复制的可靠性、安全性、效率。解锁跨网络边际、双向同步等能力，在业务配合下，实现异地多活的。

· 数据汇聚分发

数据的汇聚和分发，需要支持到库、表、行这几个级别。比如：在业务垂直分库场景下可将前端多个分库实例汇总到实例中进行统计分析。数据行按不同条件分发到下游节点，条件可以是简单的where条件，也可是简单函数表达式等。

· 数据订阅

数据订阅的场景是对MySQL binlog日志进行解析，将增量变化实时同步给Kafka消息队列，其他系统通过kafka订阅需要的数据。

· 在线数据迁移

在线数据迁移，要简化MySQL到MySQL或其他DB到MySQL的迁移过程，减少停机时间，目前还只支持MySQL间的迁移。首先抽取全量的数据，并获取增量起始的快照点，当全量回放完毕后，从增量起始点开始同步增量数据。

这对MySQL分布式架构的数据分片扩容特别有帮助，一般我们将先预分片好的物理分片放在相同MySQL实例中，当数据量增长超过实例处理能力时，就需要讲分片迁移到新的实例节点，迁移过程肯定希望尽量平滑不影响业务。DTLE可以配合我们之前开源分布式中间件DBLE，进行在线扩容。

· 云间同步

公有云RDS用户会有一些上下云和云间迁移同步的需求，我们测试了几家云厂商，针对云厂商自研的RDS for MySQL的特点，实现不同云厂商的RDS之间进行数据同步。

 3. DTLE设计原则 

以上是DTLE主要的应用场景。软件设计DTLE力求两个基本原则：易用性与可靠性。

易用性

作为软件的使用者和开发者，我们特别重视产品的使用体验，上手简单，易于部署是必须的，没有复杂的部署条件要求，没有外部依赖，安装配置步骤越简单越好，尽可能符合使用者的操作习惯。

可靠性

可靠性也必不可少，我们将DTLE的设计采用分布式的架构，具备扛单点风险和故障切换的能力。元数据信息保存在分布式一致性KV存储中，如果某工作节点或进程挂了，工作任务会转移至其他进程继续之前的断点处理数据同步，不影响服务连续性。

 4. DTLE相关介绍 

DTLE （Data-Transformation-le） 是爱可生10月24日在“程序员节”贡献开源社区的 CDC 工具，主要具备以下特点：

•多种数据传输模式：支持链路压缩，支持同构传输和异构传输，支持跨网络边际的传输

•多种数据处理理模式：支持库/表/行级别 数据过滤

•多种数据通道模式：支持多对多的数据传输、支持回环传输

•多种源/目标端：支持MySQL - MySQL的数据传输，支持MySQL - Kafka的数据传输

•集群模式部署

•提供可靠的元数据存储

• 可进行自动任务分配

• 支持自动故障转移

Github地址：https://github.com/actiontech/dtle

 4.1 DTLE架构

DTLE架构上包含两种角色的进程，Agent角色与Manager角色。Manager角色主要负责元数据信息存储，任务的接收和分发，Agent节点健康状态检测、故障转移。Agent主要负责数据读取，binlog解析，数据筛选、压缩、传输、回放等。

用户通过http协议访问Manager发布job，job是以json格式的配置项，里面定义了源数据库实例，目标数据库实例，需要复制的schema或table对象，数据的筛选条件等信息，任务提交后manager会分配给可用的agent进程，agent根据任务配置连接数据库实例，开始全量或增量的数据同步。

 4.2 DTLE的集群机制

DTLE 的manager节点可以部署多个冗余节点，节点之间的元数据信息同步和故障切换都是利用Raft分布式一致性协议来保障的。

woker节点接收来自Manager发来的任务请求，并实时上报自己的状态。当Manager的Leader节点发现worker无响应时，会通知可用的agent继续执行同步任务。

 4.3 DTLE的拓扑结构

DTLE支持的多种拓扑结构，最简单的1对1同步，n对1的汇聚同步模式，1对n的数据分发同步模式。

在跨数据中心的场景，虚线框内是两个不同的数据中心，DTLE部署在不同的数据中心，DTLE负责本数据中心的数据读取或回放，DTLE将数据压缩后通过网络发送到对端，减少了对带宽的利用，适用于窄带宽的网络环境下。

在跨数据中心有多个实例之间需要数据同步，如果通过MySQL Replication需要建立多条链路通道，而通过DTLE可以在数据中心间建立一条通道同步多个实例的数据，网络策略配置更简单，也避免了MySQL服务对外暴露。

跨数据中心的双向同步能力，可以应用在数据中心双活的场景，但数据层自身还无法做冲突检测，需要在应用层来保障数据不会冲突。

 4.4 DTLE技术栈

在DTLE的开发过程中我们借助了一些优秀的开源组件，来支撑起整个架构。

我们选用的开发语言是Golang，它的好处是开发效率高，性能有保障，部署也方便，build后的二进制文件自带运行时环境，完全不需要担心软件依赖问题。

网上有许多优秀的Golang开源项目，Hashicorp公司就是其中一家以分布式应用见长的开源软件公司，他们开发了很多优秀的DevOps 基础设施组件，包括Vagrant、Packer 、 Terraform 、Serf 、Consul , Vault 和 Nomad 等，我们使用了部分组件来构建DTLE。

nomad是一个集群管理器和调度器，我们利用它来构建基础架构，解决的任务调度和集群管理的问题，在此基础上我们开发所需的任务模板。

consul是一个分布式KV存储，nomad也集成了consul，我们用它来做manager元数据信息存储。

serf是基于gossip协议的节点状态检测组件，能够快速检测到故障节点并踢出集群，主要用来解决agent节点的failover，如果某个agent节点不可用，这个节点就会被移出集群。

NATS是一款开源的轻量级消息系统组件，我们在agent之间的数据传递使用了NATS。

以上是DTLE采用的开源组件。如果之前对这些组件由所了解，可以帮助理解DTLE的架构原理。

 4.5 DTLE功能

作者：爱可生云数据库
链接：https://www.jianshu.com/p/9813b4a95490