数据异构的武器 BINLOG+MQ.docxVIP

数据异构的武器 BINLOG+MQ 2021-09-12 1、定义 何谓数据异构，上周买卖部门商品的同事过来做共享，又看到这个词，他的PPT里面是 数据库异构。其实我们以前做的事情，也是可以成为数据异构。比如我们将DB里面的数据长久化到REDIS里面去，就是一种数据异构的方式。假如要下个定义的话：把数据按需（数据结构、存取方式、存取方式）异地构建存储。 2、常见应用场景 分库分表中有一个最为常见的场景，为了提升数据库的查询力量，我们都会对数据库做分库分表操作。比如订单库，开头的时候我们是依据订单ID维度去分库分表，那么后来的业务需求想依据商家维度去查询，比如我想查询某一个商家下的全部订单，就格外麻烦。这个时候通过数据异构就能很好的处理此问题，比如下图 总结起来或许有以下几种场景： 数据库镜像 数据库实时备份 多级索引 search build（比如分库分表后的多维度数据查询） 业务cache刷新 价格、库存变化等重要业务消息 3、数据异构方向 在日常业务开发中大致可以分为以上几种数据去向，DB-DB这种方式，一般常见于分库分表后，聚合查询的时候，比如我们依据订单ID去分库分表，那么这个时候我们要依据用户ID去查询，查询这个用户下面的订单就格外不便利了，当然可以使用统一加到内存中去，但这样不太好。所以我们就可以用数据库异构的方式，重新依据用户ID的维度来分一个表，像在上面常见应用场景中引见的那样。把数据异构到redis、elasticserach、slor中去要处理的问题跟依据多维度来查询的需求差不多。这些存储天生都有聚合的功能。当然同时也可以提高查询功能，应对大访问量，比如redis这种抗量银弹。 4、数据异构的常用方法 4.1、完整克隆 这个很简约就是将数据库A，全部拷贝一份到数据库B，这样的使用场景是离线统计跑任务脚本的时候可以。缺点也很突出，不适用于持续增长的数据。 4.2、标记同步 这个是业务场景比较简约的时候，抱负情况下数据不会发生转变，比如日志数据，这个时候可以去标记，比如时间戳，这样当发生毛病的时候还可以回溯到上一次同步点，开头重新同步数据。 4.3、BINLOG方式 通过实时的订阅mysql的binglog日志，消费到这些日志后，重新构建数据结构插入一个新的数据库或者是其他存储比如es、slor等等。订阅binglog日志可以比较好的能保证数据的全都性。 4.4、MQ方式 业务数据写入DB的同时，也发送MQ一份，也就是业务里面实现双写。这种方式比较简约，但也很难保证数据全都性，对简约的业务场景可以接受这种方式。 5、binlog和mq方式重点引见 5.1、binglog 5.1.1、订阅binglog日志异构流程图 5.1.2、使用说明 binglog是数据的日志记录方式，每次对数据的操作都会有binglog日志。现在开源的订阅binlog日志的组件，比如使用比较广泛的canal，它是阿里开源的基于mysql数据库binlog的增量订阅和消费组件。由于cannal服务器目前读取的binlog大事只保存在内存中，并且只要一个canal客户端可以进行消费。所以假如需要多个消费客户端，可以引入activemq或者kafka。如上图绿色虚线框部分。我们还需要确保全量对比来保证数据的全都性（canal+mq的重试机制基本可以保证写入异构库之后的数据全都性），这个时候可以有一个全量同步WORKER程序来保证，如上图深绿色部分。 5.1.3、canal的工作原理 先来看下mysql主备（主从）复制原理如下图，在此原理基础之上我们再来理解canal的实现原理就一眼能明白了。 mysql主备（主从）复制原理，从上层来看，复制分成三步： master将转变记录到二进制日志(binary log)中（这些记录叫做二进制日志大事，binary log events，可以通过show binlog events进行查看）； slave将master的binary log events拷贝到它的中继日志(relay log)； slave重做中继日志中的大事，将转变反映它本人的数据。 再来看下canal的原理，如下图： 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