关于数据:数据异构方式

数据异构形式

何谓数据异构，上周交易部门商品的共事过去做分享，又看到这个词，他的 PPT 外面是 数据库异构。其实咱们以前做的事件，也是可能称之为数据异构。比如咱们将 DB 外面的数据持久化到 Redis 外面去，就是一种数据异构的形式。

如果要下个定义的话：把数据按需（数据结构、存取形式、存取形式）异地构建存储。

常见利用场景

分库分表中有一个最为常见的场景，为了晋升数据库的查问能力，咱们都会对数据库做分库分表操作。比如订单库，开始的时候咱们是按照订单 ID 维度去分库分表，那么起初的业务需要想按照商家维度去查问，比如我想查问某一个商家下的所有订单，就非常麻烦。

数据异构总结起来大概有以下几种场景

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

数据异构方向

在日常业务开发中大抵可能分为以上几种数据去向，DB-DB这种形式，一般常见于分库分表后，聚合查问的时候，比如咱们按照订单 ID 去分库分表，那么这个时候咱们要按照用户 ID 去查问，查问这个用户上面的订单就非常不便利了，当然可能使用对立加到内存中去，但这样不太好。

所以咱们就可能用数据库异构的形式，从新按照用户 ID 的维度来分一个表，像在下面常见利用场景中介绍的那样。把数据异构到 redis、elasticserach、slor 中去要解决的问题跟按照多维度来查问的需要差不多。这些存储天生都有聚合的功能。当然同时也可能提高查问性能，应答大访问量，比如 redis 这种抗量银弹。

数据异构的罕用方法

1. 完整克隆

这个很简略就是将数据库 A，全副拷贝一份到数据库 B，这样的使用场景是离线统计跑工作脚本的时候可能。缺点也很突出，不适用于持续增长的数据。

2. 标记同步

这个是业务场景比较简略的时候，现实情况下数据不会发生改变，比如日志数据，这个时候可能去标记，比如工夫戳，这样当发生故障的时候还可能回溯到上一次同步点，开始从新同步数据。

3. binlog 形式

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

4. MQ 形式

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

binlog 形式

binglog是数据的日志记录形式，每次对数据的操作都会有 binlog 日志。现在开源的订阅 binlog 日志的组件，比如使用比较广泛的 canal，它是阿里开源的基于mysql 数据库 binlog 的增量订阅和生产组件。

因为 cannal 服务器目前读取的 binlog 事件只保存在内存中，并且只有一个 canal 客户端可能进行生产。所以如果需要多个生产客户端，可能引入 activemq 或者kafka。如上图绿色虚线框部分。

咱们还需要确保全量对比来保证数据的一致性（canal+mq 的重试机制基本可能保障写入异构库之后的数据一致性），这个时候可能有一个全量同步 WORKER 程序来保障，如上图深绿色部分。

canal 的工作原理

​ 先来看下 mysql 主备（主从）复制原理

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

1：master 将改变记录到二进制日志 (binary log) 中（这些记录叫做二进制日志事件，binary log events，可能通过 show binlog events 进行查看）；2：slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)；3：slave 重做中继日志中的事件，将改变反映它自己的数据。

cannal 实现原理绝对比较简单

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

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

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

咱们在部署 canal server 的时候要部署多台，来保障高可用。然而 canal 的原理，是只有一台服务器在跑处理，其它的服务器作为热备。canal server的高可用是通过 zookeeper 来保护的。

注意点

确认 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;

MQ 形式

mq 的形式，就绝对简略，实际上是在业务逻辑中写 DB 的同时去写一次 MQ，然而这种形式不能够保证数据一致性，就是不能保障跨资源的事务。注：调用第三方近程 RPC 的操作肯定不要放到事务中。

总结

本文次要叙述了数据异构的使用场景，方法。这外面涉及到的 activemq 以及 canal 并没有深入分析，对于这块的内容可能间接参考相干具体文档，文中已给了链接地址。

根据数据异构的定义，将数据异地构建存储，咱们可能利用的地方就非常多，文中说的分库分表之后按照其它维度来查问的时候，咱们想脱离 DB 间接用缓存比如 redis 来抗量的时候。数据异构这种形式都能够很好的帮助咱们来解决诸如此类的问题。