Mysql数据实时同步实践( 二 )
用户配置的每一个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上以提升资源利用、降低延迟
文章插图
业务用户也可以根据我们提供的数据格式,实时消费Talos数据以实现更复杂的业务逻辑,下表为每一种数据操作,是否保存修改前后的列表
文章插图
推荐阅读
- 巨量引擎无需API开发连接MySQL,实现推广线索自动同步到数据库
- 数据库持久化+JDBC数据库连接
- 云原生声明式数据库结构迁移工具 - SchemaHero
- 红眼|DNF:红眼剑魂加强了!7.27职业平衡,3个技能重做,11个数据增强
- 水库|为了抓钓鱼人有多拼?大数据无人机都用上了
- 华为|华为运动传感器S-TAG来了:支持13项跑姿数据监测
- 暗黑破坏神|《暗黑破坏神4》测试版或将上线 现已加入PS4/5数据库
- 大数据专业学什么就业方向 大数据专业学什么
- 杨幂|美妆市场竞争激烈,国货逐渐取得上风,唯品会数据揭开实情
- 如何实时监控老婆手机 教你怎么远程监控老婆手机