数据异构的武器-BINLOG+MQ

转自：https://my.oschina.net/wangxindong/blog/1531596

一、定义

何谓数据异构，上周交易部门商品的同事过来作分享，又看到这个词，他的PPT里面是 数据库异构。其实咱们之前作的事情，也是能够成为数据异构。好比咱们将DB里面的数据持久化到REDIS里面去，就是一种数据异构的方式。若是要下个定义的话：把数据按需（数据结构、存取方式、存取形式）异地构建存储。

二、常见应用场景

分库分表中有一个最为常见的场景，为了提高数据库的查询能力，咱们都会对数据库作分库分表操做。好比订单库，开始的时候咱们是按照订单ID维度去分库分表，那么后来的业务需求想按照商家维度去查询，好比我想查询某一个商家下的全部订单，就很是麻烦。这个时候经过数据异构就能很好的解决此问题，好比下图

异构维度.png

总结起来大概有如下几种场景

1. 数据库镜像
2. 数据库实时备份
3. 多级索引
4. search build（好比分库分表后的多维度数据查询）
5. 业务cache刷新
6. 价格、库存变化等重要业务消息

三、数据异构方向

异构的几种方向.png

 

在平常业务开发中大体能够分为以上几种数据去向，DB-DB这种方式，通常常见于分库分表后，聚合查询的时候，好比咱们按照订单ID去分库分表，那么这个时候咱们要按照用户ID去查询，查询这个用户下面的订单就很是不方便了，固然可使用统一加到内存中去，但这样不太好。因此咱们就能够用数据库异构的方式，从新按照用户ID的维度来分一个表，像在上面常见应用场景中介绍的那样。把数据异构到redis、elasticserach、slor中去要解决的问题跟按照多维度来查询的需求差很少。这些存储天生都有聚合的功能。固然同时也能够提升查询性能，应对大访问量，好比redis这种抗量银弹。

四、数据异构的经常使用方法

3.一、完整克隆

这个很简单就是将数据库A，所有拷贝一份到数据库B，这样的使用场景是离线统计跑任务脚本的时候能够。缺点也很突出，不适用于持续增加的数据。

3.二、标记同步

这个是业务场景比较简单的时候，理想状况下数据不会发生改变，好比日志数据，这个时候能够去标记，好比时间戳，这样当发生故障的时候还能够回溯到上一次同步点，开始从新同步数据。

3.三、BINLOG方式

经过实时的订阅mysql的binlog日志，消费到这些日志后，从新构建数据结构插入一个新的数据库或者是其余存储好比es、slor等等。订阅binlog日志能够比较好的能保证数据的一致性。

3.四、MQ方式

业务数据写入DB的同时，也发送MQ一份，也就是业务里面实现双写。这种方式比较简单，但也很难保证数据一致性，对简单的业务场景能够采用这种方式。

五、binlog和mq方式重点介绍

5.一、binlog

5.1.一、订阅binglog日志异构流程图

canal异构方式.png

5.1.二、使用说明

binglog是数据的日志记录方式，每次对数据的操做都会有binlog日志。如今开源的订阅binlog日志的组件，好比使用比较普遍的canal，它是阿里开源的基于mysql数据库binlog的增量订阅和消费组件。因为cannal服务器目前读取的binlog事件只保存在内存中，而且只有一个canal客户端能够进行消费。因此若是须要多个消费客户端，能够引入activemq或者kafka。如上图绿色虚线框部分。咱们还须要确保全量对比来保证数据的一致性（canal+mq的重试机制基本能够保证写入异构库以后的数据一致性），这个时候能够有一个全量同步WORKER程序来保证，如上图深绿色部分。

5.1.三、canal的工做原理：

先来看下mysql主备（主从）复制原理以下图，在此原理基础之上咱们再来理解canal的实现原理就一眼能明白了。

 

mysql主备复制实现原理.jpg

mysql主备（主从）复制原理，从上层来看，复制分红三步：

1. master将改变记录到二进制日志(binary log)中（这些记录叫作二进制日志事件，binary log events，能够经过show binlog events进行查看）；
2. slave将master的binary log events拷贝到它的中继日志(relay log)；
3. slave重作中继日志中的事件，将改变反映它本身的数据。
   再来看下canal的原理，以下图：
   

   canal工做原理.jpg

   
   cannal实现原理相对比较简单（参照上面的mysql主备复制实现原理）：
4. canal模拟mysql slave的交互协议，假装本身为mysql slave，向mysql master发送dump协议
5. mysql master收到dump请求，开始推送binary log给slave(也就是canal)
6. canal解析binary log对象(原始为byte流)
   咱们在部署canal server的时候要部署多台，来保证高可用。可是canal的原理，是只有一台服务器在跑处理，其它的服务器做为热备。canal server的高可用是经过zookeeper来维护的。
   有关canal更具体的使用和详细原理请参照：https://github.com/alibaba/canal

5.1.四、注意点

• 一、确认MySQL开启binlog，使用show variables like 'log_bin'; 查看ON为已开启
• 二、确认目标库能够产生binlog，show master status 注意Binlog_Do_DB，Binlog_Ignore_DB参数
• 三、确认binlog格式为ROW，使用show variables like 'binlog_format'; 非ROW模式登陆MySQL执行 set global binlog_format=ROW; flush logs; 或者经过更改MySQL配置文件并重启MySQL生效。
• 四、为保证binlake服务能够获取Binlog，需添加受权，执行 GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON . TO 'admin'@'%' identified by 'admin'; FLUSH PRIVILEGES;

5.二、mq方式

MQ异构方式.png

mq的方式，就相对简单，其实是在业务逻辑中写DB的同时去写一次MQ，可是这种方式不可以保证数据一致性，就是不能保证跨资源的事务。注：调用第三方远程RPC的操做必定不要放到事务中。

六、总结

本文主要叙述了数据异构的使用场景，方法。这里面涉及到的activemq以及canal并无深刻分析，关于这块的内容能够直接参考相关具体文档，文中已给了连接地址。根据数据异构的定义，将数据异地构建存储，咱们能够应用的地方就很是多，文中说的分库分表以后按照其它维度来查询的时候，咱们想脱离DB直接用缓存好比redis来抗量的时候。数据异构这种方式都可以很好的帮助咱们来解决诸如此类的问题。
转载请注明出处，并附上连接 https://my.oschina.net/wangxindong/blog/1531596
参考资料：https://github.com/alibaba/canal