1、定义
何谓数据异构，比如我们将DB里面的数据持久化到REDIS里面去，就是一种数据异构的方式。如果要下个定义的话：把数据按需（数据结构、存取方式、存取形式）异地构建存储。
2、常见应用场景
分库分表中有一个最为常见的场景，为了提升数据库的查询能力，我们都会对数据库做分库分表操作。比如订单库，开始的时候我们是按照订单ID维度去分库分表，那么后来的业务需求想按照商家维度去查询，比如我想查询某一个商家下的所有订单，就非常麻烦。这个时候通过数据异构就能很好的解决此问题，比如下图
异构维度.png
总结起来大概有以下几种场景
- 数据库镜像
- 数据库实时备份
- 多级索引
- search build（比如分库分表后的多维度数据查询）
- 业务cache刷新
- 价格、库存变化等重要业务消息
3、数据异构方向
异构的几种方向.png
在日常业务开发中大致可以分为以上几种数据去向，DB-DB这种方式，一般常见于分库分表后，聚合查询的时候，比如我们按照订单ID去分库分表，那么这个时候我们要按照用户ID去查询，查询这个用户下面的订单就非常不方便了，当然可以使用统一加到内存中去，但这样不太好。所以我们就可以用数据库异构的方式，重新按照用户ID的维度来分一个表，像在上面常见应用场景中介绍的那样。把数据异构到redis、elasticserach、slor中去要解决的问题跟按照多维度来查询的需求差不多。这些存储天生都有聚合的功能。当然同时也可以提高查询性能，应对大访问量，比如redis这种抗量银弹。
4、数据异构的常用方法
3.1、完整克隆
这个很简单就是将数据库A，全部拷贝一份到数据库B，这样的使用场景是离线统计跑任务脚本的时候可以。缺点也很突出，不适用于持续增长的数据。
3.2、标记同步
这个是业务场景比较简单的时候，理想情况下数据不会发生改变，比如日志数据，这个时候可以去标记，比如时间戳，这样当发生故障的时候还可以回溯到上一次同步点，开始重新同步数据。
3.3、BINLOG方式
通过实时的订阅mysql的binlog日志，消费到这些日志后，重新构建数据结构插入一个新的数据库或者是其他存储比如es、slor等等。订阅binlog日志可以比较好的能保证数据的一致性。
3.4、MQ方式
业务数据写入DB的同时，也发送MQ一份，也就是业务里面实现双写。这种方式比较简单，但也很难保证数据一致性，对简单的业务场景可以采用这种方式。
5、binlog和mq方式重点介绍
5.1、binglog
5.1.1、订阅binglog日志异构流程图
canal异构方式.png
5.1.2、使用说明
binglog是数据的日志记录方式，每次对数据的操作都会有binlog日志。现在开源的订阅binlog日志的组件，比如使用比较广泛的canal，它是阿里开源的基于mysql数据库binlog的增量订阅和消费组件。由于cannal服务器目前读取的binlog事件只保存在内存中，并且只有一个canal客户端可以进行消费。所以如果需要多个消费客户端，可以引入activemq或者kafka。如上图绿色虚线框部分。我们还需要确保全量对比来保证数据的一致性（canal+mq的重试机制基本可以保证写入异构库之后的数据一致性），这个时候可以有一个全量同步WORKER程序来保证，如上图深绿色部分。
5.1.3、canal的工作原理：
先来看下mysql主备（主从）复制原理如下图，在此原理基础之上我们再来理解canal的实现原理就一眼能明白了。
mysql主备复制实现原理.jpg
mysql主备（主从）复制原理，从上层来看，复制分成三步：
- master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，可以通过show binlog events进行查看）；
- slave将master的binary log events拷贝到它的中继日志(relay log)；
- slave重做中继日志中的事件，将改变反映它自己的数据。
再来看下canal的原理，如下图：
canal工作原理.jpg
- cannal实现原理相对比较简单（参照上面的mysql主备复制实现原理）：
- canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议
- mysql master收到dump请求，开始推送binary log给slave(也就是canal)
- canal解析binary log对象(原始为byte流)
我们在部署canal server的时候要部署多台，来保证高可用。但是canal的原理，是只有一台服务器在跑处理，其它的服务器作为热备。canal server的高可用是通过zookeeper来维护的。
有关canal更具体的使用和详细原理请参照：https:///alibaba/canal
5.1.4、注意点
- 1、确认MySQL开启binlog，使用show variables like 'log_bin'; 查看ON为已开启
- 2、确认目标库可以产生binlog，show master status 注意Binlog_Do_DB，Binlog_Ignore_DB参数
- 3、确认binlog格式为ROW，使用show variables like 'binlog_format'; 非ROW模式登录MySQL执行 set global binlog_format=ROW; flush logs; 或者通过更改MySQL配置文件并重启MySQL生效。
- 4、为保证binlake服务可以获取Binlog，需添加授权，执行 GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON . TO 'admin'@'%' identified by 'admin'; FLUSH PRIVILEGES;
5.2、mq方式
MQ异构方式.png
mq的方式，就相对简单，实际上是在业务逻辑中写DB的同时去写一次MQ，但是这种方式不能够保证数据一致性，就是不能保证跨资源的事务。注：调用第三方远程RPC的操作一定不要放到事务中。
Canal的git地址 https:///alibaba/canal
Canal原理：
1.canal模拟mysql slave的交互协议，伪装自己为mysql slave,向mysql master发送dump协议；
2.mysql master收到dump请求，开始推送binary log给slave(也就是canal)
3.canal解析binary log对象（原始byte流）
Canal部署：
1.首先针对mysql服务，需要对mysql进行设置，开启binlog权限：
[mysqld]
log-bin=mysql-bin #添加这一行就ok
binlog-format=ROW #选择row模式
server_id=1 #配置mysql replaction需要定义，不能和canal的slaveId重复
2.对配置在canal的mysql用户进行赋权操作（需要模拟slave）：
CREATE USER canal IDENTIFIED BY 'canal';
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';
-- GRANT ALL PRIVILEGES ON *.* TO 'canal'@'%' ;
FLUSH PRIVILEGES;
3.下载canal并进行解压（当时操作的版本为canal.deployer-1.0.25.tar.gz）
4.对canal进行参数设置：
应用参数：
vi conf/example/instance.properties
## mysql serverId
canal.instance.mysql.slaveId = 1234
position info，需要改成自己的数据库信息
canal.instance.master.address = 127.0.0.1:3306
=
canal.instance.master.position =
canal.instance.master.timestamp =
#canal.instance.standby.address =
# =
#canal.instance.standby.position =
#canal.instance.standby.timestamp =
username/password，需要改成自己的数据库信息
canal.instance.dbUsername = canal
canal.instance.dbPassword = canal
canal.instance.defaultDatabaseName =
canal.instance.connectionCharset = UTF-8
#正则控制对那些数据库的哪些表进行监控，.\..则是全库全表
table regex
canal.instance.filter.regex = .\..
说明：
canal.instance.connectionCharset 代表数据库的编码方式对应到java中的编码类型，比如UTF-8，GBK , ISO-8859-1
启动服务。
sh bin/startup.sh
