随着企业规模的扩大，对数据库可用性要求越来越高，更多企业采用两地三中心、异地多活的架构，以提高数据库的异常事件应对能力。

在数据库领域，我们常听的“两地三中心”、“异地多活”到底是什么呢？

“两地三中心”就是生产数据中心、同城灾备中心、异地灾备中心。这种模式下，两个地域的三个数据中心互联互通，当一个数据中心发生异常，其他数据中心可以正常运行并进行业务接管。

“异地多活”就是在多个地域建设多个数据中心， 业务数据能够在三个及以上的数据中心之间进行双向同步。异地多活架构具有更高的可用性，抗风险能力极强。

不同数据中心可以接管并恢复业务的前提是多个数据中心无差别，彼此之间可以实时同步数据。通过腾讯云 DTS 数据同步功能可以实现这一诉求。本文将向您介绍通过腾讯云 DTS 数据同步功能实现两地三中心架构的方案以及关键原理。

架构介绍

利用腾讯云DTS数据同步可构建下图中的两地三中心架构，其中1~4分别为一条单向的数据同步链路；A为生产数据中心，B为同城的灾备中心，C为异地的灾备中心。

图：两地三中心架构示例

关键问题

在上图所示的两地三中心架构中，数据同步需要解决以下四个关键问题：

• 单向链路中存量数据和增量数据的同步
• 通过单向链路构建的复杂拓扑中回环问题的处理
• 如何保证三个节点数据一致
• 同步延迟问题

解决方案

1. 单向链路中存量数据和增量数据的同步

单向同步链路是两地三中心、多活数据架构的基础。为了使单向链路的目标节点数据和源头节点一致，既要复制存量数据，又要持续同步增量数据。对于线上系统，源端往往不停地有业务数据写入，为了得到一份一致性的存量数据，往往需要对源端进行加锁，比如FTWRL或者备份锁，这也是mydumper，xtrabackup等备份工具采用的方案。加锁的弊端在于会影响源库的业务写入，这在一些场景下是无法接受的。针对这个问题腾讯云 DTS 提出了一种无锁方案，即存量数据导出时不对源库加锁，在回放增量数据时修复存量数据的不一致，最终达到源和目标数据的一致性。

DTS在发起数据同步任务的同时，会接管源端的Binlog，然后将Binlog在目标端进行回放，在同步任务期间源端的SQL操作，会重复在目标端执行一遍。

这跟MySQL Replication主从复制的原理是类似的，通常MySQL为一主多从的架构形式，主库Master负责数据写入，从库Slave负责数据读取，从库的IO线程将主库上的变化写入到本地Relay log，SQL线程读取Relay log在从库上进行回放，从而实现主从数据同步。

图：MySQL Replication主从复制原理图

MySQL这种读写分离的模式可以大大减少主库的访问压力，但灵活性较差，筛选功能不足。

DTS在主从复制架构的基础上，引入灵活的拓扑结构，支持一对多、多对一、联级单向、双向同步、联级环形同步等，可满足各种复杂的数据库同步场景的应用，如两地三中心、异地多活等。

2. 解决数据回环问题

数据同步中会遇到回环问题，以如下环形同步为例，对A进行SQL操作，A同步到B，B再同步到C，C又同步给A，A会重复处理该SQL操作，进而陷入无限循环中，所以如何进行数据破环，是双向同步、环形同步等必须要解决的问题。

图：数据回环问题

DTS通过在事务的Begin和Commit之间插入一个标记，记录事务经过的节点，以此来保证一个事务不会经过同一个节点两次，从而达到破环的目的。在其他的拓扑结构，如双向同步、联级环形同步都可以通过做标记来实现破环。

3. 保证三节点数据一致

在两地三中心数据架构中，会有两个或三个节点需要同时进行数据写入，保证多个节点的一致性至关重要。

3.1 规划主键分区

在两地三中心的场景中实现数据一致性，常见的方法就是规划主键分区。主键分区即多个写入的数据库“各司其职“，各自负责更新不同的主键数据，从源头上避免产生主键冲突。例如A节点上负责更新ID为1、3、5的主键数据，B节点上负责更新ID为2、4、6的主键数据。

如果实际业务部分数据存在耦合，无法进行主键分区，则可能产生主键冲突。DTS支持对冲突进行处理，并提供如下三种冲突策略：

冲突报错

同步任务中，源库插入（INSERT）主键数据与目标库存在冲突时，任务报错并暂停，需要用户手动处理后才能继续。

冲突处理时SQL语句改写如下：

INSERT不改写
UPDATE 不改写
DELETE 不改写

冲突忽略

同步任务中检测到源库的主键插入（INSERT）数据与目标库发生冲突时，忽略源库的主键插入数据，以目标库的内容为准。

冲突处理时SQL语句改写如下

INSERT -> INSERT IGNORE
UPDATE 不改写
DELETE 不改写

冲突覆盖

同步任务中检测到源库的主键更新（INSERT和UPDATE）数据与目标库发生冲突时，用源库的主键数据覆盖目标的主键数据。

冲突处理时SQL语句改写如下：

INSERT -> REPLACE INTO
UPDATE -> DELETE + REPLACE INTO
DELETE 不改写

这里首先需要明确的是，DTS冲突策略的应用，仅针对发生主键冲突时的数据，应用后可以按用户设置的策略进行处理，使任务报错提醒给用户或者继续运行。不产生冲突的场景，如下图的UPDATE和所有的DELETE主键操作，源端的操作都会正常同步到目标端，DTS不会干预。

图：不产生冲突的场景下，DTS不干预

如果没有主键分区，多个源端INSERT同一条主键数据引起冲突时，DTS可以按照冲突策略来干预，但多个源端对同一条主键数据进行正常的UPDATE时（如上图，没有冲突），DTS不会干预，这样可能会出现，目标端的数据被重复刷新或者随意刷新（不能确定最终刷新的结果是哪个节点同步过来的），同一条主键数据在多个节点显示的不一致。

综上，要实现多节点数据一致性，进行主键分区是非常有效的方法，可以从源头上避免数据产生冲突。

3.2 两地三中心数据同步应用

下面结合两地三中心的数据架构，介绍数据一致性如何保证，以及通过设置冲突策略来处理冲突问题。

图：两地三中心架构示例

图中1-4为DTS的一条单向同步链路，1、2构成A<->B的双向同步，3、4构成A->C之间的双向同步。

A、B同时负责数据写入，提前规划好A、B各自负责更新的主键数据，例如A负责更新主键ID为1-100的数据，B负责更新主键ID为101-200的数据。

冲突策略给出如下推荐，用户在实际的场景中可以根据业务的情况进行灵活选择。

• 如果希望发生INSERT主键冲突时DTS给出提示用户手动处理，则4条链路都设置冲突报错。
• 如果希望INSERT主键时以A的为准，则A->B、A->C设置为冲突覆盖，B->A、C->A设置为冲突忽略。（不能保证UPDATE主键和DELETE主键操作也以A的为准）

4. 同步延迟问题

目标数据库相对于源数据库的延迟也是DTS 关注的一个重要问题，当 DTS 同步数据的速度达不到源端写入速度，就会出现延迟，这在某些场景下会影响业务对目标数据库的使用。

腾讯云 DTS 采用全新自研内核，通过行级并发机制，对同步性能做了极致的优化，能满足大部分实际业务场景下对同步性能的需求。

行级并发机制同MySQL 8.0新引入的WriteSet复制机制有相似之处，基于数据行本身的主键/唯一键等信息进行并发。但相对于原生主从复制内嵌到MySQL Server（相当于网络延迟为0），DTS只能外部写入，这就存在写入网络延迟的问题，会影响到写入性能。为此，腾讯云DTS进行了进一步优化，使得DTS理论并发度相对于WriteSet进一步提高，以此弥补网络延迟带来的影响。网络延迟3ms以下，压测（Sysbench Update Index）TPS可达 2.2W；网络延迟更大的情况下，可以通过调整并发度来一定程度弥补高延迟带来的影响。经过优化，腾讯云DTS能满足大部分业务场景对性能的需求。

如下为当前DTS同步任务中不同规格的RPS参考（RPS表示DTS每秒同步至目标表的数据行数）。

表：DTS同步任务中不同规格的RPS上线参考

在实际业务场景中，RPS可能会受源和目标数据库的运行负载、DTS 访问源和目标数据库的网络延时、网络带宽等多种因素的影响。腾讯云 DTS 经过优化，对网络延时的容忍度较高，在一些跨地域的场景中也能保持较好的性能。如果用户需要更高的传输性能，也可以通过专线接入、VPN接入等方式，保证数据传输过程中的网络延时和带宽质量。

总结

腾讯云DTS已具备实时数据同步、回环处理、数据冲突处理、高性能传输等能力，可根据企业需求灵活定制多种同步拓扑架构，用于两地三中心、异地多活等场景的数据同步。