什么是数据异构？上周交易部同事过来分享，又看到了这个词。他的PPT说数据库异构。其实我们之前做的也可以叫做数据异构。比如我们将DB中的数据持久化到Redis中，这是数据异构的一种方式。如果想做一个定义：按需在不同的地方构建和存储数据（数据结构、访问方式、访问形式）。常见应用场景分库分表有一个最常见的场景。为了提高数据库的查询能力，我们会对数据库进行分库和分表操作。例如，订单数据库。一开始我们是按照订单ID维度分库分表的。那么，如果我们要根据商户维度进行查询，以备后面的业务需要，比如我要查询某个商户下的所有订单，就很麻烦。这时候数据异构就可以很好的解决这个问题，如下图所示：数据异构可以归纳为以下几个场景Query)业务缓存刷新价格，库存变化等重要业务信息数据异构方向可以大致在日常业务发展中分为以上几类数据去向。比如当我们按照订单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的增量订阅消费组件。由于cannalserver当前读取的binlogevents只保存在内存中，只有一个cannalclient可以消费。所以如果需要多个消费者客户端，可以引入activemq或者kafka。如上图绿色虚线框所示。我们还需要保证全比对来保证数据的一致性（canal+mq的重试机制基本可以保证写入异构库后的数据一致性）。这时候，我们可以有一个全同步的WORKER程序来保证，如上图绿色部分。canal的工作原理首先看一下mysql的主从（master-slave）复制原理如下图所示。基于这个原理，我们可以一目了然地理解canal的实现原理。mysql主从（master-slave）复制的原理，从上层的角度来看，复制分为三个步骤：master将变化记录到二进制日志（binarylog）中（这些记录被称为二进制日志事件,二进制日志事件,可以通过showbinlogevents查看);从服务器将主服务器的二进制日志事件复制到它的中继日志；从站重做中继日志中的事件，这将改变以反映它自己的数据。再来看看canal的原理，如下图所示：cannal的实现原理比较简单（参考上面mysql主备复制的实现原理）：canal模拟了mysqlslave的交互协议，伪装成做mysqlslave，向mysqlmaster发送转储协议mysqlmaster收到转储请求后，开始向slave（即canal）推送二进制日志。Canal解析二进制日志对象（原本是字节流）。在部署canal服务器的时候，我们需要部署多台服务器来保证高可用。但是canal的原理是只有一台服务器在运行和处理，其他服务器作为双机热备。canalserver的高可用由zookeeper维护。canal更具体的使用和详细原理可以参考：https://github.com/alibaba/canal注释确认MySQL开启了binlog，使用showvariableslike'log_bin'；勾选ON确认目标库可以生成binlog，showmasterstatus注意Binlog_Do_DB、Binlog_Ignore_DB参数确认binlog格式为ROW，使用showvariableslike'binlog_format'；非ROW方式登录MySQL执行setglobalbinlog_format=ROW;刷新日志；或更改MySQL配置文件，重启MySQL生效。为了保证binlake服务能够获取Binlog，需要添加授权，执行GRANTSELECT,REPLICATIONSLAVE,REPLICATIONCLIENTON*.*TO'admin'@'%'identifiedby'admin';冲洗特权；MQ方式比较简单，其实就是在业务逻辑中写DB的同时写一次MQ，但是这种方式不能保证数据的一致性，即不能保证跨资源事务。注意：调用第三方远程RPC的操作一定不能放在事务中。小结本文主要介绍数据异构的使用场景和方法。这里涉及的activemq和canal没有深入分析。本篇内容可直接参考相关具体文档，文章中已给出链接地址。根据数据异构性的定义，我们可以在不同的地方构建和存储数据。我们可以应用到很多地方。文中提到的分库分表后，根据其他维度查询时，我们想脱离DB，直接使用redis等缓存来抗量。什么时候。数据异构可以很好的帮助我们解决这样的问题。推荐阅读（请注意，不要当妓女！）Netty是如何实现单机百万并发的？最安全的加密算法Bcrypt，再也不用担心数据泄露~实用干货！SpringCloudGateway集成OAuth2.0实现分布式统一认证授权！在实现原理上，为什么Nacos这么强？阿里的限流神器Sentinel杀连载17题？openFeign的致命连环9题，谁受得了？SpringCloudGateway致命系列的10个问题？
