Mysql数据实时同步实践( 二 ) _Mysql数据

Master周期性从配置服务读取Binlog同步作业配置

Master更新Zookeeper中的调度信息

Worker节点根据Zookeeper上的调度信息启动新分配任务，停止配置失效任务；作业启动后完成数据实时同步并周期性将同步进度记录在kudu中

服务上报监控信息到Falcon平台，作业异常退出发送报警邮件

如何保障数据正确性>>>>顺序性
用户配置的每一个BinlogSource 都会绑定一个Talos的topic，在进行消费的时候需要保证同一条mysql记录操作的顺序性，消息队列Talos是无法保证全局消息有序的，只能保证partition内部有序。
对于配置分库分表或者多库同步任务的BinlogSource，服务会根据库表信息进行hash，将数据写入相应的partiton，保证同一张表的数据在一个partition中，使得下游消费数据的顺序性；
对于单表同步的作业目前使用一个partition保证其数据有序。
>>>>一致性
如何保证在作业异常退出后，作业重新启动能够完整地将mysql中的数据同步到下游系统，主要依赖于以下三点

服务会记录作业同步的offset，重启后从上次commit的offset继续消费
Binlog数据的顺序性保证了即便数据被重复消费（未commit的数据），也能对同一条记录的操作以相同的顺序执行
下游存储系统kudu，Es ，redis基于主键的操作能够保证binlog重复回放后数据的最终一致性

应用场景有了这份数据我们可以做些什么事情呢，本节例举了几种常见的应用场景
>>>>实时更新缓存
业务查询类服务往往会在mysql之上架设一个缓存，减少对底层数据库的访问；当mysql库数据变化时，如果缓存还没有过期那么就会拿到过期的数据，业务期望能够实时更新缓存；
利用binlog服务，根据策略实时将数据同步到redis中，这样就能够保证了缓存中数据有效性，减少了对数据库的调用，从而提高整体性能。

文章插图

>>>>异步处理，系统解耦
随着业务的发展，同一份数据可能有不同的分析用途，数据成功写入到mysql的同时也需要被同步到其他系统；如果用同步的方式处理，一方面拉长了一次事务整个流程，另一方面系统间也会相互影响
数据在mysql中操作成功后才会记录在binlog中，保证下游处理到时的一致性；使用binlog服务完成数据的下发，有助于系统的解耦
【Mysql数据实时同步实践】关于异步处理，系统解耦在消息队列价值思考一文中有更深入的解读
>>>>即席查询的BI系统
就如文章开篇提到的，mysql在一定场景下的性能瓶颈，mysql数据同步到kudu后可以借助sparksql完成性能的提升
因为同样是sql接口，对使用者的切换成本也是较低的，数据同步到更适合的存储中进行查询，也能够避免因大查询而对原mysql库其他查询的影响
目前小米内部稳定运行3000+的同步作业，使用binlog服务同步数据到kudu中；小米内部BI明星产品XDATA借助整套同步流程很好地支持了运营、sql分析同学日常统计分析的需求
如何使用Binlog数据用户接入数据的时候要求mysql库开启binlog日志格式必须为Row模式：记录的是每一行记录的每个字段变化前后的值，虽然会造成binlog数据量的增多，但是能够确保每一条记录准确性，避免数据同步不一致情况的出现
最终通过监听binlog日志，LCSBinlog服务将数据转换成如下的数据结构，写入用户注册的Topic中，目前Sink服务使用SparkStreaming实时转储数据到kudu中，后续也将逐步迁移到Flink上以提升资源利用、降低延迟