微服务MySQL分库分表数据到MongoDB同步方案

在现有的架构中做大数据分析，第一步面临的问题就是数据如何从关系型数据库到非关系数据库，网上有很多的解决方案，我们也经过了很多的摸索，经历了三套方案的实践，最终使用了canal。这是我们大数据部门的一个同事张同睿写的文章，分享给大家，如果感兴趣后面可以进一步的介绍。

需求背景

近年来，微服务概念持续火热，网络上针对微服务和单体架构的讨论也是越来越多，面对日益增长的业务需求是，很多公司做技术架构升级时优先选用微服务方式。我所在公司也是选的这个方向来升级技术架构，以支撑更大访问量和更方便的业务扩展。

发现问题

微服务拆分主要分两种方式：拆分业务系统不拆分数据库，拆分业务系统拆分库。如果数据规模小的话大可不必拆分数据库，因为拆分数据看必将面对多维度数据查询，跨进程之间的事务等问题。而我所在公司随着业务发展单数据库实例已经不能满足业务需要，所以选择了拆分业务系统同时拆分数据库的模式，所以也面临着以上的问题。本文主要介绍多维度数据实时查询解决方案。当前系统架构和存储结构如下：

解决思路

• 要对多数据库数据进行查询，首先就需要将数据库同步到一起以方便查询

• 为了满足大数据量数据需求，所以优先选择NOSQL数据库做同步库

• NOSQL数据库基本无法进行关联查询，所以需要将关系数据进行拼接操作，转换成非关系型数据

• 业务多维度查询需要实时性，所以需要选择NOSQL中实时性相对比较好的数据库：MongoDB

根据以上思路，总结数据整合架构如下图所示：

解决方案

目前网上一些数据同步案例分两种：MQ消息同步和binlog数据读取同步

先说MQ消息同步，该同步方式我所在公司试用过一段时间，发现以下问题：

• 数据围绕业务进行，对业务关键性数据操作发送MQ消息，对业务系统依赖性比较高

• 对于数据库中存量数据需要单独处理

• 对于工具表还需要单独维护同步

• 每次新增数据表都需要重新添加MQ逻辑

考虑到以上问题，用MQ方式同步数据最优解决办法

使用binlog 数据读取方式目前有一些成熟方案，比如tungsten replicator，但这些同步工具只能实现数据1:1复制，数据复制过程自定义逻辑添加比较麻烦，不支持分库分表数据归集操作。综上所述，最优方案应该是读取后binlog后自行处理后续数据逻辑。目前binlog读取binlog工具中最成熟的方案应该就是alibaba开源的canal了。

canal

canal是阿里巴巴mysql数据库binlog的增量订阅&消费组件 。阿里云DRDS、阿里巴巴TDDL 二级索引、小表复制. 都是基于canal做的，应用广泛。canal原理相对比较简单：

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

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

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

canal介绍： https://github.com/alibaba/canal/wiki

我使用的是canal的HA模式,由zookeeper选举可用实例，每个数据库一个instance,服务端配置如下：

目录：

conf
 database1
 -instance.properties
 database2
 -instance.properties
 canal.properties

canal.instance.mysql.slaveId =instance.properties 1001
canal.instance.master.address = X.X.X.X:3306
canal.instance.master.journal.name = 
canal.instance.master.position = 
canal.instance.master.timestam