深度剖析数据库国产化迁移之路

随着国家有关部门近年来陆续出-台相关政策指导文件，推动探索安全可控的金融科技产品，加强银行业信息安全建设，国内众多金融政企机构纷纷开始探索改造原有IT系统，对国产化数据库的需求日益强烈。

腾讯自研的金融级分布式数据库TDSQL的金融政企用户数日前已突破600家。作为一款金融级国产化数据库，TDSQL不仅完全满足国家对金融安全可控的要求，也能解决过去传统金融数据库靠采购高端设备或进行资源堆砌才能解决的问题。
 

金融机构为什么

选择国产化数据库？ 
 

1. 张家港农商行采用TDSQL分布式数据库架构后的硬件成本，只有传统架构成本的1/5甚至更低。更重要的是，张家港行因此每年节省了20%的IT投入，数字化业务创新得到了快速推进。

2. 微众银行的单客户IT成本能节省为传统商业数据库架构的1/10。

金融数据如何

平滑迁移至国产化数据库？

分布式数据库TDSQL是腾讯打造的一款分布式数据库产品，具备强一致、高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性，同时提供智能DBA、自动化运营、监控告警等配套设施。

TDSQL多源同步（TDSQL-MULTISRCSYNC），是高性能、高一致，支持多种异构数据平台的数据分发服务。该服务支持以TDSQL作为源端的数据实时同步分发至MySQL、Oracle、PostgreSQL、消息队列等平台，同时也支持以TDSQL作为目标端，将MySQL或者Oracle的数据实时同步至TDSQL中,并且部署灵活，支持一对多，多对一等多种复制拓扑结构。

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

从上图可以看到，整个系统可以大致的分成三个部分：producer，store，consumer。

producer：增量日志获取模块，主要负责解析获取源端的增量数据改动日志，并将获取到的日志解析封装为JSON协议的消息体，投送至消息队列。当源端是MySQL或者TDSQL时，获取的增量日志为binlog事件，这里要求binlog必须是row格式且为full-image。当源端是Oracle，producer从Oracle的物化视图日志中获取增量数据并进行封装和投送。这里producer在向消息队列生产消息时，采用at-least-once模式，即保证特定消息队列中至少有一份，不排除在队列中有消息重复的情况。

store：消息队列中，因为数据库系统日志有顺序性要求，因此这里所有的topic的partition个数均为1，保证能够按序消费。

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

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

数据库系统在记录binlog时，按照事务的提交顺序将行的改动写入binlog文件，因此按照binlog文件记录事件的顺序进行串行重放，源端和目标端数据库实例状态一定会达到一致。但是串行重放因为速度慢，在遇到如批量更新等大事务时，容易产生较大的同步时延，适应不了对数据实时性较高的同步场景。为了提高并发度，这里consumer按照每个行记录的表名和主键值进行hash，根据hash值将消息投送到对应的同步线程中。这样乱序的重放会导致数据不一致吗？答案是不会的，因为虽然是将顺序的消息序列打乱了，但是同一行的所有操作都是在同一个线程中是有序的，因此只要每个行的改动执行序列正确，终数据是会一致。这个过程如下图所示：

实现幂等逻辑的动机有两个：

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

2、支持幂等逻辑后，便于数据的修复，且在数据同步的过程中不需要记录镜像点，便于运维。这里幂等逻辑的设计原则就是，保证按照binlog事件的意图去对目标实例进行修改。如insert事件，其意图就是要在数据库中有一条new值标识的记录；update事件的意图就是，数据库中没有old值标识的记录，只有new值标识的记录；delete操作也是同样，其结果就是要求目标数据库中，不包含old值标识的记录。因此针对insert，update，delete操作，其幂等逻辑如下：

insert
 

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

从上图可以看到，update操作的幂等处理，其实就是保证了在数据库中，只能有new值产生的记录。

delete
 

这个过程中，delete结束后大于0就成功；小于0就是失败；等于0的时候认为它可能没有匹配到行，这个时候我就按照主键操作——因为删除的操作终的结果就是目标一定没有了当前删除的消息主键所标识的这一行——这条操作完成后，DB里一定没有这行数据，因此仅仅是按照主键进行删除就可以了。这个时候如果影响行数大于0，则删除成功。如果等于0，就认为按照主键去匹配，本身删除不到，匹配不到——意思是本身目标就没有这条要删的主键所标识的数据——所以实际上它的结果跟要做完删除的结果，影响是一样，也就结束这一条删除的幂等。

这一套同步服务，一定是高可用的，体现在两个方面：

1、灾难的情况下，本身消费者的服务能够在假如机器出现一些不可恢复的故障时能够及时地感知并且自动迁移和切换；

2、要应对本身常规的扩容——垂直扩容或者水平扩容的伸缩性需求，这也是比较强调，这一套同步服务要能够兼容各种灾难情况和常规的运维场景下各种各样的要求来做到服务的高可用。

重点针对数据库迁移同步的场景而言，TDSQL多源同步提供多机容灾保护机制：

消费者高可用保障层面，一方面消费者服务本身无状态，所有的任务下发通过MetaCluster实现，可以通过多台机器去部署同步服务，这套容灾机制通过manager进程来实现，也就是说当整个机器掉电，运营这个机器的consumer已经不存活，这个时候这些consumer在MetaCluster上的存活节点的失效就会被其他机器的manager节点感知——认为另外一些机器的consumer已经不存活，这个时候就会把任务接管过来，并且在自己机器上重新拉起这些服务。

二是要做到同一个数据同步的链路不能在两台机器上同时拉起，这是一个互斥的要求。高可用机制会通过一些像标识或者当前的分派节点做到，同一个数据同步的任务在被拉起的时候一定是发生在不同的机器上来实现漂移与互斥的操作，这个多机容灾保护总体上就是通过MetaCluster和监控的进程，比如说manager这样的服务进行协调完成，保证在机器级别灾难或者其他灾难情况下这些任务能够在十秒以内成功迁移到其他的存活节点上。

TDSQL多源同步解决方案，过去几年中，已经帮助众多金融政企机构高效平稳地实现国产数据库迁移替换。

用户可以通过多源同步对业务进行分布式的改造，直接通过实时同步将单实例往分布式的架构上迁移。比如说保险客户通过多个分库、多个分片区或者多个单的业务、逻辑上的划分，把这些数据通过TDSQL这套服务同步到全量库里面。

以某大型互联网保险公司为例，基于TDSQL多源同步迁移方案，实现了多对一的一拓扑结构，可以非常高效、稳健地将公司多套大区的业务数据汇总到一个全量库里面，继而实现了对整体数据进行报表分析和抽取。

2019年，张家港行基于TDSQL打造的新一代核心业务系统，成功上线后便成为业界关注的焦点。将银行传统核心系统数据库迁移到腾讯云TDSQL数据库后实现了代差级的降本增效。
 
在这样的金融级高度敏感业务系统迁移实践中，TDSQL的性能和安全的迁移服务策略得到良好的验证。
 
在张家港行数据库迁移实践中，核心交易集群是TDSQL，TDSQL多源同步方案通过内部的局域网，将存量和增量数据，写入到备份机房，同时也通过全量的数据校验服务保证数据源、目标是完全一致来进行风险控制。当核心交易系统如果出现一些小概率不可恢复的灾难时候，系统可以在短时间内将交易的服务全部切换到备份机房的Oracle上，作为银行传统核心系统数据库迁移的安全兜底方案，后确保数据库顺利迁移。

数据库迁移涉及大量核心数据信息，“快”和“稳”缺一不可。多源同步服务作为TDSQL内置功能特性，以某省广电局迁移案例为例，TDSQL多源同步迁移服务通过重新部署业务系统的迁移方式，从迁移准备、迁移评估、方案设计、资源准备及数据库改造、迁移实施、结果验证一共只使用30天。其中为关键的资源准备及数据库改造环节用时7天！将客户的业务系统数据库从Oracle迁移到TDSQL，TDSQL的性能满足了客户面临的现有的业务压力。而业务系统迁移过程中对数据完整性保障，为后续新业务系统运维提供了良好的数据基础。

以某互联网人寿保险公司为例，该用户在公有云TDSQL上的实例是其核心的生产环境，云下同时也部署了一套TDSQL系统，通过多源同步这套系统，用户实现了云上的生产环境和云下的生产环境灾备同步，这相当于是，实现了跨城同时也是跨数据中心的数据灾备功能。

结语