背景
MySQL由于自身简单、高效、可靠的特点，成为小米内部使用最广泛的数据库，但是当数据量达到千万/亿级别的时候，MySQL的相关操作会变的非常迟缓；如果这时还有实时BI展示的需求，对于MySQL来说是一种灾难。
为了解决sql查询慢，查不了的业务痛点，我们探索出一套完整的实时同步，即席查询的解决方案，本文主要从实时同步的角度介绍相关m w L 0 # U Y E ~工f / F作。
早期业务借助Sqoop将MySQL中的数据同步到Hive来进行数据分析，使用过程中也带来了一o 5 S 5 k r T 8些问题：
-
虽然Sqoop支持增量同步但还属于粗粒度的离线同步，无法满足实时性的需求；
-
每次同步Sqoop以sql的方式向Z 5 g + q N v NMySQL发出数据请求也在一定程度上对MySQL带来一定的压力；
-
同时Hive对数据更o t . i w新的支持也相对较弱。
为了更有效地连i W h ( _ +接前端业务数据系统（MySQL）和后端统计分析系统（查询分f G c m析引擎），我们需要一套实时同步MySQL数据的解决方案。
小米内部实践
如何能够做到数据的实时同步呢？我们想到了MySQL主从复制时使用的binlog日志，它记录了所有的DDL和DML语句（除了数据查询语句select、show等），以事件形式记录，还包含语句所执行的消耗时间。
下面来看一下MySQS # 5 l nL主从复制的原理，主要2 E r ^ [ ~ O [有以下几个步骤：
-
master（主库）b w ` p s U在每次准备提交事务完成数8 ? $ ) M据更新前，将改变记录到二进制日志(bR ^ ~ } s a E c Xinary log)中；
-
slave（从库）发起连接，连接到master，请求获取指定位置的binJ 9 glog文件；
-
master创建dump线程，推送binlog的slav$ c pe；
-
slave启动一个I/O线程来读取主库上binary log5 : l 0 $ A p v e中的事件，并记录到slave自己的中o e : W { R r B继日志(relay log)中；
-
slave还会起动一个SQL线程，该线程从relay log中读取事件并在备库执行，完成数据同步；
-
slave记录自己的binlog。
binlog记录了Mysql数据的实时变化，是数据同步的基础，服务, ! n z { - K L需要做的就是遵守Mysql的协议，将自己伪装成MK W e 3ysql的slave来监听业务从库，完成数据实时同步。
结合小米内部系统特点，构建了Mysql数据同步服务LCSBinlog，作为一种独立的数据接入方式整合在Talos Platform中，Talos Platform作为大数据集成的基础解决方案，以自研消息队列TaloG ? [ W Qs为数据总线，连接各种系统为主要目标，提供丰富的数据Soug ` G Krce输入和数据Sink输出，并且Talos天然支持流式计算，因此业务可以充分利用{ | O o 0Talos Platform互联互通的特性，并结合自身的业务需求实现更加高阶的业务场景。
上图是Tax I w p ( @los Platf# o Z Aorm中的整体流程架构，其中标红部分是目J [ ] ^ ` ) &前LCSBinlog在小米内部使用最广泛的一条链路：Mysql ---&7 U _ 4 + F hgt; Talos ---> Kudu ---> BI，数据同步到kudu后借助Sparksql查询引擎为上层BI系统提供即席查询服务，Kudu和Sparksql的整合细节可以参见往期内容：告别”纷纷扰扰”—小米OLAP服务架构演进。
LCSBinlog服务的主体架构
服务一共有两种角色：$ S . a 7 ]
-
Master ：主要负责作业的调度；
-
Worker：主要完成具体的数据同步任务
在Worker上运行两种作业：
-
BinlogSyncJob：每一个mysql库都会对应这P U _ 9 A ( d M )样一个Job，将R N 7binlog日志完整地写入d + g 3 G - W I到服务创建的Talos topic中；
-
MysqlSyncJP e B i ; . . i Zob：同步历史数据，消费binlog数据，4 6 5 W 3 3 5过滤特定库表数据实时同步至用户配置的topf t M / U N S (ic中。
服务整体依赖于Zookeeper来同步服务T ; J I v x j Q v状态，记录作业调度信息和标记作业运行状态0 e Z l；在kudu表中记录作业同步进度。
控制流程如下：
-
Worker节点通过在Zookeeper上注册告知自己可以被调度；
-
通过在Zw b i , , K L {ookeeper上抢占EPHEMERAL临时节点实现Mc q R ` | ,aster的HA；
-
用户在融合云（Web）上注册Binf xlogSource同步任务；
-
Master周期性从配置服务读取Binlog同步作业配置；
-
Master更新Zookeeper中的调度信息；
-
Worker节点 根据Zookeeper上的调度信息启动新分配任务，停止配置失效任务；作业启动后完成数据实时同步并周期性将同步进度记录在kudu中；
-
服务上报监控信息到Falcon平台，作业异常退出发送报警邮件。
如何保障数据正确性
顺序t j v 6性
用户配置的每C + g Z z ? + * x一个Binlogj 0 M b / * 1Source 都会绑定一个Talos的topic，在进行消费的时候需要保证同一条mysql记录操作的顺序性，消息队列TaloD e J k q is是无法保证全局消息有序的，只能保证partition内部有o K - a 0 ; ; y u序。
对于配置分库分表或者多库同步任务的BinlogSource，服务会根据库表信息进行hash，将数据写入相应的partiton，保证同一张表的数据在一个partition中，使得下游消费数据的顺序性。
对于单表同- = R B步的作业$ [ o # d F N -目前使用l l 4一个partition保证其数据有序。
一致性
如何保证在作业异常退出后，作业重新启动能够完整地将mysql中的数据同步到下游系统，主要依赖于以下三b b V H a # !点：
-
服务会记录作业同步的offset，重启后从上次commit的offset继续消费；
-
Binlog数据的顺序性保证了即便数据被重复消费（未c@ Y g S r - I ~ommit的数据），也能对同一条记录的操作以相同的顺序执行；
-
下游存储系_ 8 X V B . b .统kudu，Es ，Redis基于主键的操作能够保证binlog重C J m $ Q 1 C 2复回放后数据的最终一致性。
应用场景
有了这份数据我们可以做些什么事情呢，本节例举了几种常) B 6 / ~见的应用场景。
实时更? f ; 6 0 s R j (新缓存
业务查询类服务往往会在mysql之上架设一个缓存，减少对底Z % S |层数据库的访问；当mysql库数据变化时3 # q @ x $ f - K，如果缓存还没有过期那么就会拿到过期的数据，业务` U v B * 8期望能够实时更新缓存。
利用binlog服务f ) Y，根据策略实时将数据同步d u = d P w V到redis中，这样就能够保证了缓存中数据有效性，减少了对数据库的{ G 0 5调用，S * D从而提高整体性能。
异步处理，系统解耦
随着业务. z h K ~ k的发展m L ^ H，同一份数据可能有不同的分析用途，数据成功写入到mysql的同时也需要被同步到其他系统；如果用同步的方式处理，一方面拉长了一次事务整Z 4 u ^ % a 9 z d个流程，另一方面系统间也会h ) @相互影响。
数据在mysql中操作成功后才会记录在binlog中，保证下游处理到时的一致性；使用binlog服务完成数据的下发，有助于系统的解耦。
关于异步处理，系统解耦在消息队列价值思考一文中有更深入的解读。
即席查询的BI系统
就如文章开篇提到的，mysql在一定场景下的性能瓶颈，mysql数据同步到kudu后可以借助sparksql完成性能的提升。
因为同样是sql接口，对使用者l ? K a | s的切换成本也是较低的，数据同步到更适合的存储m 1 o B ~ i中进行查询，也能够避免因大查询而V F v对原mysql库其他查询的影响。
目前小米内部稳定运行3000+的同步作业，使用binlogA Q x l服务同步数据到kudu中；小米内部BI明星产品XDATA借助整套同步流程很好地支持了运营、sql分析同学日常统计分析的需求。
如何使用Binlog数据
用户接入数据的时候要求mysql库开启binlog日志格式必须为Row模式：记录的] t $ k Q是每一行记录的每个字段变化前后} ~ 8 r .的值，虽然会造成bD P % & Ninlog数据量的增多，但是能够确保每一条记录准确性，避免数据同步不一致情况的出现。
最终通过监听binlog日志，LCSBinlog服务将数据转换成如下的数据结构，写入用户注册的Topic中， 目前Sink服务使用SparkStre3 6 d p & ? Gaming实时转储数据到kudu中，后续也将逐步迁移到Flink上以提升资源利用、降低延迟W , K + # E 4 f I。
业务用户也可以根G K $据我们提供的数据格式，实时消费Talos数据以实现更复杂的业务逻辑，下表为每一种数据操作，是否保存修改前后的列表。
疑难杂症
下面分享2个上线后遇到的有趣问题。
1）数据不一致问题，业务使用唯一索引
业务接入一e G m + ^ G段时间后，发现部分表会偶尔存在kudu表的数据条目数多于同步的mysql表的数据条目数，我们将多出来的数据与mysql产生的binlog日志经过一一对比，发现用户在mysql表中设置了唯一索引} M v F # y，通过唯+ w Q D $ ) (一索引修改了主键: I S , n 0 -，而U L p s u F 2kudu中的数据是通过主键标识或更新一条记录的，n F l 6 H $于是update操作变成了insert操作，这就造成了原来的1条记录] # M ,变成了2条。
解决办法：对于这种类型的表，LCSBinlog服务会把一次Update操作转换成一条Delete数据和一条Insert% o G数据。
2）FuR 8 3 C L bll DumE g , m 8 Np同步历史数据时，客户端超时
服务刚上线的时候，通过jO C b x ?dbc 执行sql的方式完成全量历史数据的同步，在同步的过程中会发现dump任务会卡顿很长时间才会返回结果，当数据量很大会出现超时同步失败的情况，会造成数据的延迟。调研后发现使用mysql官方jdbc在客户端查询数据的时候，默认为从服务器一次取出所有数据放在客户端内存中，fetch siI v V ~ o z o MzV t G k ! Ue参数不起作用，当一条SQL返回数据量较大时可能会出现OOM。% 2 8
解决办法：当statement设置以下属性时，采用的是流数据接收方y @ : x式，每次只从服务器接收部份数据，直到所有数据处理完毕。优化后历史数据同步% ~ X d 9 ^ J 3 g稳定运行，对my{ T j T * ! ~ b 8sql端p ` * - k 1 O K的压力& | y也很小。
总结
MySQL以BinK Y R ! ; 1 J ^ dlog日志的方式记录数据变化P D W，基于流式数据的Change Data CaputI Q o L Pre (CDC)机制实现了LCSBinlog服务。
本文主要对LCSBinlog的服务架构、应用场景以及在小米内部的实践经验进行了介绍，也和大家分享了我们实际中遇到的问题和解V 9 B Y p [ - u ^决方案，希望能够帮助到大家理解服务的原理，带来启发，也欢迎大家和我们一起交流。
作者丨刘心光
来源丨小米云技术（ID：mi-cloud-tech）
dbaplus社群欢迎广大技术人员投稿，投` j A r 2稿邮箱：editor@dbaplus.cn
>q [ y k 6 R 5 .;>>>
2020年4月17a d { u z w O日，北京，Gdevops全球敏捷运维峰会将开启年度首站！重点围绕数据库、智慧运维、Fintech金融科技领域，携手阿里、腾讯、蚂蚁金服、中国银行、平安银行、中邮消费金融、中国农业银行、中国民生银行V z i n U R 2 : Z、中国联通大数据、浙江移动、新炬网络等技术代表，展望云时代下数据库发展趋势、破解运维转型困局。