1. 首页>
  2. 腾讯云代理

技术干货| 腾讯云TDSQL多源同步架构与特性详解

腾讯云 2019年08月13日 浏览17

    腾讯云代理 腾讯云新闻 腾讯云代理 腾讯云直播申请 游戏上云

摘要:

作者介绍

吴夏,腾讯云TDSQL研发工程师,目前主要负责日志解析复制、数据传输同步模块的开发工作。



一、场景及需求



在金融业务场景中,数据的同步、订阅、分发是常见需求,例如保险行业常见的总分系统架构,多个子库需要实时地将业务数据同步至总库汇总查询;银行核心交易系统中,需要将交易数据实时同步至分析子系统进行报表、跑批等业务操作。

因此,腾讯云打造的分布式数据库TDSQL(Tencent distribute database)作为一个金融级数据库产品,对数据的分发、解耦能力是必不可少的。



image

▲ 数据实时同步分析架构

其中,TDSQL-MULTISRCSYNC(下文简称多源同步)模块正是为了应对这样的需求和场景所开发的高性能、高一致、支持多种异构数据平台的数据分发服务。

该服务支持以TDSQL作为源端的数据实时同步分发至MySQL、Oracle、Postgres、Kafka等平台,同时也支持以TDSQL作为目标端,将MySQL或者Oracle的数据实时同步至TDSQL中,并且部署灵活,支持一对多、多对一等多种复制拓扑结构。当前该服务的官网名称为“数据同步”,是作为一个子功能集成在腾讯云TencentDB for TDSQL产品中。



二、系统架构



多源同步模块典型的基于日志的CDC复制技术,其系统架构如下:

整个系统可以大致分成三个部分:producter,store,consumer。



1、producter


增量日志获取模块,主要负责解析获取源端的增量数据改动日志,并将获取到的日志解析封装为JSON协议的消息体,投送至Kafka消息队列。

当源端是MySQL或者TDSQL时,获取的增量日志为binlog事件,这里要求binlog必须是row格式且为full-image。当源端是Oracle,producter从Oracle的物化视图日志中获取增量数据并进行封装和投送。

这里producter在向Kafka生产消息时,采用at-least-once模式,即保证特定消息队列中至少有一份,不排除在队列中有消息重复的情况。



2、store


这里采用Kafka作为中间存储队列,因为数据库系统日志有顺序性要求,因此这里所有的topic的partition个数均为1,保证能够按序消费。



3、consumer


日志消费和重放模块,负责从Kafka中将CDC消息消费出来并根据配置重放到目标实例上。这里因为producter端采用at-least-once模式生产,因此消费者这里实现了幂等逻辑保证数据重放的正确。



三、核心设计及实现



1、基于行的哈希并发策略


金融业务场景中,往往对数据的实时性要较高,因此对数据同步的性能提出了比较高的要求。为了解决这样的问题,consumer采用了基于行的哈希并发策略实现并行重放。下面以binlog消息为例来说明该策略的实现。



MySQL在记录binlog时,按照事务的提交顺序将行的改动写入binlog文件,因此按照binlog文件记录事件的顺序进行串行重放,源端和目标端数据库实例状态一定会达到一致。

但是串行重放因为速度慢,在遇到如批量更新等大事务时,容易产生较大的同步时延,适应不了对数据实时性较高的同步场景。

为了提高并发度,consumer按照每个行记录的表名和主键值进行hash,根据hash值将消息投送到对应的同步线程中。

有些读者在这里可能会有疑问,这样乱序的重放难道不会导致数据不一致吗?答案是不会的,因为虽然是将顺序的消息序列打乱了,但是同一行的所有操作都是在同一个线程中是有序的,因此只要每个行的改动执行序列正确,最终数据是会一致。

目前,基于行级的并发单任务同步速率可以达到4W的QPS,已经可以满足绝大多数场景对同步速率的要求。



这里每个线程在重放的时候,都会将消息按照一定的数量封装成事务来进行重放。这种模式下的并发复制,实际上实现的是最终一致性,因为原有的事务结构已经被打破。当然因为并发复制速度够快,业务如果能够接受秒级的同步时延,基本上业务是感知不到不一致的数据。



2、row格式binlog事件的幂等容错


实现幂等逻辑的动机有三个:



  • 因为生产者实现的是at-least-once模式进行消息生产,因此consumer这里必须要能否处理消息重复的问题。

  • 支持幂等逻辑后,便于数据的修复,且在数据同步的过程中不需要记录镜像点,便于运维。

  • 支持自动容错,降低同步失败,卡住的概率。



这里幂等逻辑的设计原则就是,保证按照binlog事件的意图去对目标实例进行修改且一定要成功。

如insert事件,其意图就是要在数据库中有一条new值标识的记录;update事件的意图就是,数据库中没有old值标识的记录,只有new值标识的记录;delete操作也是同样,其结果就是要求目标数据库中,不包含old值标识的记录。

因此针对insert,update,delete操作,其幂等逻辑如下:



1)INSERT

当出现主键冲突时,insert操作会转变成delete+insert操作来保证insert动作执行成功。另外图中的影响行数小于0或者等于0标识执行SQL出错和主键冲突。

2)update


update操作的幂等处理,其实就是保证了在数据库中,只能有new值产生的记录。


3)delete


delete的幂等原则就是,确保目标DB中没有delete事件中标识的记录。



在实现了上述的幂等逻辑后,会带来很多便利。如在全量迁移数据时,无需在记录镜像点,只要保证增量日志获取的时间比全量镜像点早,即便有binlolg的重放,由于有幂等逻辑,也能保证最终的数据一致。



3、多唯一约束条件下的并发控制

在Kafka队列中,具有相同主键值的记录会被投送到相同的线程,且线程内是有序的。这样的并发方式在下面这样的场景中,会产生数据不一致的情况。以下是对该场景的详细描述。




4、优化与展望

目前,多源同步已在腾讯公有云、专有云等多家金融客户业务中运行,提供可靠的数据分发同步能力。后续会在异构平台接入等能力上做更多的投入,如DB2、SQLserver、大数据平台等,以适应更多业务场景。


相关文章

在线客服
淘宝购买
腾讯云直播申请 title=
+成为腾讯云VIP客户 腾讯云直播申请 客服电话

15818558013

0755-33940501-803

0755-33940501-808