作为国民经济的命脉和枢纽，金融行业对底层数据库的能力要求正在不断提高。在众多要求中，数据一致性无疑是重中之重，即数据不能出错，最好还能提高并发效率。

TDSQL 采用 MC(轻量级 GTM)+全局 MVCC 的全局读一致性方案。如果只使用全局事务管理器 GTM，除需维护全局序列外，还需要维护全局的事务冲突，这个过程的通信量及与 GTM 之间的通信频率都会成为瓶颈。TDSQL 引入全局 MVCC，将每个分片上 MVCC 版本和全局 GTS 做映射，通过全局 GTS 和全局的 MVCC 映射来管理每个分片上的镜像，进而实现全局的 MVCC，从而极大减少和 GTM 之间的通信量及避免全局的冲突事务检测。

上述方案确保了 TDSQL 无任何数据异常，且具备高性能的可扩展性，解决了分布式数据库在金融级场景应用的最核心技术挑战，使得国产分布式数据库实现在金融核心系统场景的可用、好用，进而推动国产基础软件产业化。基于此，TDSQL 是当前国内率先进入国有大型银行核心系统正式投产的国产分布式数据库。

在 WOT 全球技术创新大会 2022 的腾讯云数据库专场中，腾讯云数据库专家架构师汪泗龙分享了金融级分布式数据库 TDSQL 的一致性技术及应用实践，以下为详情内容：

一、TDSQL 产品介绍

1.1 发展历程

腾讯云数据库 TDSQL 诞生自腾讯内部百亿级账户规模的金融级场景。从内部自研蜕变成规模化商业产品，TDSQL 的发展历程可分为四个阶段：

第一阶段是 2007-2009 年，当时开源的 MySQL 已经越来越难以应对腾讯爆发式增长的业务，研制服务于计费、定位于金融场景的分布式数据库 TDSQL 逐渐提上日程。

第二阶段是 2009-2012 年，腾讯进入开放时代，海量业务群雄并起，以开心农场等为代表的众多亿级应用比比皆是。TDSQL 逐渐在性能瓶颈、数据可靠性保障、高可用等“不可能三角”的技术难题上取得突破。

第三阶段是 2012-2014 年，云计算兴起，数据库上云、多租户、标准化成为标配。腾讯云数据库的能力逐渐外溢，TDSQL 因其优异的性能已经拥有众多外部客户。在经过公有云的海量数字化、大规模高并发业务场景打磨以及内核级的深度自研优化后，TDSQL 逐渐形成标准化的国产分布式数据库产品，包括金融级分布式 TDSQL、计算与存储分离的云原生数据库 TDSQL-C 等产品，获得了云原生技术、多租户隔离能力。

第四阶段是 2014-2020 年，数字化升级成为行业趋势，TDSQL 深入金融核心，走向大规模应用阶段，比如作为微众银行分布式数据库底座承担核心作用，帮助张家港农商银行上线新一代核心业务系统，助力平安银行打造信用卡“A+”新核心系统等等。

目前，TDSQL 已服务金融、政务、工业制造等行业超过 50 万家客户，帮助 20 余家金融机构完成核心替换，国内 TOP 10 银行机构服务占比超过 60%。同时 TDSQL 也支持了第七次全国人口普查，以及腾讯会议、健康码等关系国计民生的数字化应用，有力推进国产数据库的技术创新和发展。

1.2 核心特性

随着云计算和数字化业务的发展，针对新型企业级信息化以及实现国产化的转型升级需求，TDSQL 逐渐形成 6 大核心特性：

• 数据强一致性：确保多副本架构下数据强一致，避免故障后导致集群数据错乱和丢失。

• 金融级高可用：确保 99.999%以上高可用；跨区容灾；同城双活；故障自动恢复。

• 高性能低成本：软硬结合；支持读写分离、秒杀、红包、全球同服等超高性能场景。

• 企业级安全性：数据库防火墙；透明加密；自动脱敏；减少用户误操作/黑客入侵带来的安全风险。

• 线性水平扩展：无论是资源还是功能，均提供良好的扩展性。

• 便捷的运维：完善的配套设施，包括智能 DBA、自助化运营管理台。

1.3 产品架构

TDSQL 的架构主要分为三层。最上层是管理层，包含赤兔管理平台、MC 以及 Keeper。中间层是 SQL 引擎，可以选择使用 TDSQL 附带的接入层，也可使用传统意义上的 F5 等接入层来进行接入。最下层是存储引擎层，即 TDSQL 内核。

下图是实现 GTM 全局唯一序列的图签。这里是 TDSQL 在实现分布式事务后在全局一致性读方面的优化点，该插件实现了轻量级的 GTM。

二、分布式事务处理

事务处理面临的挑战有两点：保障数据正确性及提高并发效率。这两点都是事务处理的关键点，如果为了提高并发效率而牺牲数据正确性，就背离了初衷，反之也是如此。为了解决这两个问题，我们需要用到很多技术，比如读写分离、物理时钟、时间戳机制、GTM 等。

2.1 分布式事务模型

不管是分布式数据库还是应用，都是在分布式事务模型下，进行分布式事务的实践和开发。对数据库而言，常用的分布式事务模型是 XA 模型；对应用而言，主要是 TCC、SAGA、AT 等模型。

Oracle、MySQL、TDSQL 等数据库，通常使用 XA 模型来进行分布式事务处理。在 XA 模型里，事务主要采用两阶段提交方式，先进行 PREPARE，再进行 COMMIT，也称之为两阶段事务。

2.2 数据异常问题

事务模型简化后划分为读写两类操作，组合下来有四种场景，即读写、写读、读读、写写。存在冲突（数据异常）的场景主要是写写、写读、读写，具体的冲突如下：

• 写写冲突：会出现脏写、丢失回滚。

• 写读冲突：会出现脏读、幻读、不可重复读、读偏序等。

• 读写冲突：会出现脏写、丢失更新等。

• 其他异常：主要是写偏序，即违背语义（约束）的异常。两笔事务同时发生，每笔事务都满足约束。但在分别进行的过程中，因为没有提前加锁，没有满足语义，导致最终事务完成后违背了语义约束。

针对上述问题，我们可以通过数据库的并发控制算法来解决：

• 基于锁（两阶段锁）进行控制：两阶段锁除我们常用的 2PL 外还有 S2PL、SS2PL，主要是锁定阶段的不同。在种类上主要有 S 锁、X 锁、U 锁、间隙锁。

• 基于 MVCC 的方案：将读写进行分离，支持多版本和快照。

• 基于时间戳进行控制：主要有三个时间戳，即事务启动时的时间戳、数据读的时间戳以及数据写的时间戳。

• 基于有效性确认来进行控制。

我们需要根据不同的场景来使用不同的算法。在分布式事务处理方面，TDSQL 使用的是 2PL 加上 MVCC 特性。

2.3 全局读不一致问题

我们以下图为例说明全局读不一致问题。有 A、B 两个账户，账户余额均为 100 元。有两个事务，事务 X 和事务 Y，事务 X 是 A 给 B 转 100 元，事务 Y 是读取 A 和 B 的余额。当事务 Y 发起查询时，事务 X 中(NA 分片属于 COMMITting 状态，NB 分片属于 COMMITed 状态)，这时读到两人余额总和为 300 元，这就是分布式事务进行过程中的全局读不一致问题。

出现这种全局读不一致的情况，主要原因在于这里没有全局一致的 MVCC 版本，而是依赖每个分片各自的 MVCC 特征进行实现，我们读到的 NA 片还没提交，因此读到的数据是不一致的数据。针对上述异常情况，主要有以下几种解决方案：

• 利用全局事务管理器 GTM，GTM 会提供一个全局序列来满足使用，还会维护全局的事务冲突列表。

• 以封锁机制实现全局可串行化，将所有的读写都变成相关的逻辑上的 DML 操作，实现全局封锁。这个过程可以解决所有的读写冲突，从而实现全局读一致性。但这种模式会带来性能上的问题，导致效率降低。

• 采用物理时钟排序，其缺点在于成本高，且效率比全局封锁的效率低。

• 采用混合时间戳机制实现局部偏序排序，但这个方案只限于特定场景。

• 两次读机制，第一次读发现数据不一致就会发起第二次读，直到可以给到客户一致性的版本。

TDSQL 的全局读一致性方案是 MC(轻量级 GTM)+全局 MVCC。只使用全局事务管理器 GTM 的方案，除需维护全局序列外，还需要维护全局的事务冲突，这个过程的通信量及与 GTM 之间的通信频率都会成为瓶颈。因此需要引入另一个特性——全局 MVCC，这时的读写冲突可通过 undo 的前镜像完成一个全局的 MVCC 来实现，解决各副本间的读写冲突。

完全重新开发一套全局 MVCC 的成本较高，且和 InnoDB 的兼容性是个问题。因此我们采用了折中方式，我们将每个分片上 MVCC 版本和全局 GTS 做映射，通过全局 GTS 和全局的 MVCC 映射来管理每个分片上的镜像，进而实现全局的 MVCC。这样就可极大减少和 GTM 之间的通信量及避免全局的冲突事务检测。

三、TDSQL 分布式事务实践

3.1 TDSQL 分布式事务模型

下图为 TDSQL 分布式事务的实现模型，主要有三个角色：

• TM：SQLEngine 充当事务管理器角色，负责发起分布式事务。

• RM：DB 节点相当于分布式事务的资源节点(RM)，作为分布式事务的重要参与者。

• TC：XID_LOG 作为分布式事务协调者的角色，确认 PREPARE 状态的完成。

通过 Client 发起一个事务 BEGIN 后，会往后端发起一个插入语句到 Proxy，此时 Proxy 发起 XA Start，到后端的两个 SET 上，两个 SET 返回正常后则插入成功。获取到 XID 后，开始正式进入 COMMIT 阶段。Client 发起 COMMIT 后，Proxy 往后端发时就会带着全局的 XID 往后提交，这时进入 PREPARE 和 COMMIT 阶段。

当所有参与者 PREPARE 成功后，会插入全局的 XID_LOG。XID_LOG 是 PREPARE 阶段的一个平衡点，解决悬挂等待的高成本及超时回滚等问题。一旦事务进入到这个阶段，写入全局的 XID_LOG 成功后，即使后面的操作失败，我们依然会认为事务是成功的。针对没有提交成功的事务，Agent 参与进来，扫描 XID_LOG 表进行后续处理；如果执行超时，Agent 会参与进来，终止掉超时的事务，之后 Agent 会更新 XID_LOG 的状态。

Proxy 和 Agent 是协作模式，XID 同一时间点只能有一种状态，我们可以通过这种状态来协调 Proxy 和 Agent。如果 Proxy Crash 掉，Agent 进行任务接管，根据 XID_LOG 的信息决定对事务进行补提交或回滚。在此过程中，Proxy 本身是无状态的，这就使得 TDSQL 具备良好的业务体验。

如果在主备过程中，一个 SET 发生主备切换，另外一个 SET 正常，这时 Agent 会根据全局 XID_LOG 的状态进行相关补偿或者回滚。如果 XID_LOG 写成功，我们会进入到最终的 COMMIT 阶段，两个分片分别 COMMIT 成功后，会正常反馈给 Client 端。以上就是 TDSQL 基于 XA 两阶段提交的分布式事务模型和原理。

3.2 TDSQL 全局一致性读实现方案

分布式数据库，不仅要解决分布式事务的问题，还要解决全局写读冲突，从而实现全局的一致性读。TDSQL 具体的实现方案如图所示：

与前面提到的 TDSQL 分布式事务模型相比，整体架构较为相似，区别在于多了一个 MC 组件。

MC 是全局的轻量级 GTM，负责生成全局的唯一序列。以上述两个 SET 的插入的事务模型为例，整个过程中只是多了两次和 GTM 之间的获取步骤，其他流程是一致的。

当我们发起一个分布式事务，在 CLIENT 启动及提交时，我们会在这里再加入一个阶段，获取全局最大的 GTS。GTS 是标识的全局唯一序列，XID 是唯一标识全局事务的标签，两者相互独立分别保证分布式场景下读取一致性和事务一致性。在 COMMIT 发起后进入两阶段提交，这里需要对 PREPARE 阶段进行判定，通过 XID_LOG 日志来作为全局提交成功的标识。在 PREPARE 成功后，PROXY 和 MC 会进行第二次交互，重新获取 COMMIT_GTS，并伴随事务的 COMMIT 写入到 TDSQL REDO 日志和缓存中。相对于 XA 的 START 和 COMMIT，TDSQL 为了实现全局的 MVCC 特性，改写了 XA 的语法，增加部分关键词，同时对内核做微量调整，以上就是 TDSQL 实现全局一致性读的方案。

在该方案中，我们和 MC 的通信量非常少，整个过程中基本只有 2 次非常轻量的通信，某些场景下当我们进行一个不涉及多分片的事务时，即如果只涉及一个分片，我们会对第二次获取 COMMIT_GTS 进行优化，进一步减少和 MC 通信。实际上，TDSQL 实现分布式事务和分布式全局一致性的方案，是把 InnoDB 自身的 MVCC 和全局 GTS 进行全局映射，从而实现全局轻量级的 GTM+全局的 MVCC。

下图是 InnoDB 的 MVCC 模型，共有六个事务，当前事务 ID 是 trx6，为活跃状态。众所周知，InnoDB 会将 trxid 直接排序，通过全局事务链表管理维护。我们以下图为例来说明可见性算法是如何对外可见的。

我们过滤时需要过滤事务本身的可见性情况，要看哪些事务对外已经能看到属于活跃事务。我们可以过滤掉 trx7 和 trx5，活跃事务为 trx8、trx4、trx3。根据活跃的 trxid，我们可以获取到两个 id，一个是比较旧的快照即 up_limit_id；另一个是比较新的快照地址即 low_limit_id。如果当前事务的 id 小于 up_limit_id，说明这属于比较老的快照地址，对当前查询来说事务可见；如果当前事务的 id 大于等于 low_limit_id，说明是非常新的快照地址，事务不可见。当处于两者之间时，就需要判断是否为活跃状态。

我们以下图为例，来说明如何把全局可见性视图串起来。有四行记录，分别是 ROW0 到 ROW3，需要查询一个比较老的快照(up_limit_id:76)，我们可以看下每一条记录的查询情况。ROW0 行有两个版本，trxid:100 和 trxid:62。ROW1 行有 trxid:80、trxid:75、id32 三个版本。ROW2 只有 trxid:20 一个版本。对于 ROW0，满足条件的是 trxid:62。对于 ROW1，满足条件的是 trxid:75 和 trxid:32，因为我们找快照时是根据列表找到满足条件的第一个快照，而非找到最老的 trx:32，要找的是 trx75。另外对于 ROW2，当前只有一个版本，且只有 20，这时已经满足条件。

InnoDB 本身是使用 MVCC 机制来解决读写并发问题，通过 Undo log 来对应事务中的读写语句。Undo log 记录的是每个旧的镜像版本，当事务需要读取旧版本时，可以通过链表去回溯旧的版本。当需要回滚时，也可以基于 Undo 来进行相关的数据回滚。

TDSQL 实现全局 MVCC 的原理与 InnoDB 相似，将全局的 trxid 和全局事务序列对应，将 trxid 和全局 GTS 进行关联，从而实现全局的 MVCC。如下图所示，全局场景下会存在全局序列 GTS。对于 trx6，其 GTS 值为 150，对它可见的 GTS 必须小于等于 150，如果比它大则不可见。因此 trx7 和 trx8 对其不可见；trx5 的 GTS 是 100，小于 150，因此可见；trx4 是大于 100，在 100-150 之间因此可见；trx3 的 GTS 值是 300，也不可见。

对于 trx8、trx7、trx4 和 trx3，我们要分别找到对应记录行的 Undo 历史版本。如果找到的 Undo 项的 GTS 值依然大，就继续往前找。对于 trx8 关联的记录行通过 undo 链的回溯，最终找到的记录所绑定的 GTS 是 30，以此类推对于 trx7“最终记录行”是 70，trx4 是 40，trx3 是 20。这样 trx6，trx8、trx7、trx5、trx4、trx3 对应“可见的记录行”的 GTS 值分别是 30、70、100、40 和 20。

回到前文流程，这时全局事务还在 COMMTTING 过程中，一个事务已经提交，另一个事务没有提交，在另外一个读事务扫描记录行的过程中，读取到前两个写事务时，我们可能都要通过 undo 获取他们的历史版本。TDSQL 的全局可见性算法是把节点局部的 trxid 和全局 GTS 进行映射关联，实现全局 MVCC，从而消除读写冲突和一致性问题。

我们以一个写事务和读事务的场景为例，开启 MC 后，TDSQL 对 PREPARE 状态进行了相关处理。当写事务进行 UPDATE 操作后，这个事务可能为 ACTIVE、PREPARE 或 COMMIT 状态，此时需要判断这些状态是可见还是不可见。

对于处于 ACTIVE 状态的事务，InnoDB 下对非当前事务不可见，转换为 COMMIT 状态后，通过比较 GTS，再根据全局层面的可见性来进行判定。同样地，一个 PREPARE 中的事务，对于 InnoDB 或 TDSQL 都处于等待状态。如果等的时间久了，则全局的分布式事务效率会降低，需要进行优化。所以每笔请求时，SELECT 都会带上 GTS，当扫描到这一行时，会比较数据行的 GTS 和当前 SELECT 的 GTS，如果 SELECT 的 GTS 大于数据行的 GTS 则可见，否则不可见。当数据行处于 PREPARE 状态时，我们还不知道它提交的 GTS，此时可见性无法判断，需要等到进入到提交状态，才能进行可见性判断。

下图所示的场景中，存在两个 UPDATE 事务，当第一个节点 COMMIT 之后，另一个节点仍处于 PREPARE 状态，这时我们需要等它提交及返回结果。这个过程中它的状态不可知，因此无法比较 GTS 值，则需要等待，不会读取到中间状态。

3.3 TDSQL 全局一致性读的设计优化

TDSQL 主要从三个方面针对全局一致性读进行设计优化：

• 在全局的 trxid 到 GTS 进行映射后，每次访问都需要获取一个 MAX_GTS 和 COMMIT_ GTS，对事务来说需要增加两次访问。访问频次提高后，如何实现高效映射这是首先需要考虑的事情。

• 处于 PREPARE 状态的记录，会触发等待机制导致吞吐量下降，需要想办法降低等待开销。

• 对于没有走两阶段提交的非分布式事务，需要尽可能减少和 MC 的交互，在提交阶段可以将操作进行合并，合并后只获取一次 COMMIT_GTS。

下图主要介绍 TDSQL 在开启 MC 之后的优化。首先是 tlog，tlog 实现了本地 MVCC 和全局 MVCC 之间的映射关系，主要存储的是 GTS 和 trxid。tlog 的整体设计非常简洁，一个 tlog 里包括 4K 的数据页，每一页包含 4K 个字节，一个 GTS 是 64 位的无符号整型，占 8 字节，整个页面是 128 个字节，128 字节中最后的 111 字节是 checksum 值。因此每个页面能存储约 496 个 GTS。

第二是 trxid 和 GTS 映射。要实现高效的映射，就需要有快速定位的方法。实际上，每个 trxid 对应到 tlog 时都有偏移，文件起始的 trxid 称为 start_id，当前的 trxid 减去 stard_id 乘以 8，就是偏移值。基于这个算法，我们可以快速定位到文件的地址和偏移值，实现快读定位。

第三是 tlog 和 redo。tlog 可实现了全局 MVCC 和 GTS 映射，这个过程中也需要对 XA 语句进行调整。我们对这块进行了微调兼容 XA 语法，每次 XA Start 和 XA COMMIT 时，都会携带 GTS 值，把 GTS 写到 redo 的同时也写到 tlog 中。为了避免 tlog 刷新带来频繁的随机读写问题，TDSQL 采用 WAL 机制，tlog 文件以内存映射方式提供读写能力。

如图所示，左侧是 tlog 的 buffer，其中 tlog buffer 和 tlogdatafile 对应。每次读 GTS 时，其实是从 tlog buffer 页面去读。写 GTS 时也是写 tlog buffer 同时写入 Redo，这样可以保证 tlog 的持久化。同样当实例 crash 后，可以在启动阶段构读取到 tlog buffer，整个 tlog 也能构造出一致性。

第四是针对 PREPARE 的优化。以下图中的场景为例，在 T1 启动后，当前 MySQL 节点已经提交的最大 GTS 为 99，所以 PREPARE 的 GTS 一定大于 99，至少为 100，所以此时为 PREPARE 的记录行绑定了 100 的 GTS。

同时又有活跃事务 T2 进行了 COMMIT 操作，其 COMMIT 的 GTS 为 150 和 200，所以 T2 提交后把 SET1、SET2 两个节点局部缓存的 MAX_COMMIT_GTS 推进到了 150 和 200。

同时存在的活跃事务 T3 为一个只读事务，其 GTS 为 250，那么它读取到 T1 的 PREPARE 的记录行时事务将会被阻塞，但是如果 T3 启动时绑定的 GTS 为 99，那么它将直接跳过 PREPARE 记录，因为通过 PREPARE 绑定的 100 GTS 就可以确定，即使将来该记录提交也一定对 T3 事务不可见。

综上所述，TDSQL 针对该流程进行了优化，在进行查询时，如果当前读事务绑定的 GTS 值比 PREPARE 的 GTS 值要小，这时我们不用等 PREPARE 完成，可以直接去找其 undo 前镜像，因为该记录“将来的”COMMIT_GTS 一定比当前 PREPARE 的 GTS 要大。

第五是针对 XA 的优化。以下图为例，有 SET1 和 SET2，SET1 进行单机事务插入，SET2 也在进行单机事务插入，即 SET1 和 SET2 插入的事务并没有任何因果关系。如果在同一 SET 上同时发起三笔单机事务，需要为这三次 COMMIT 请求三次 MC 获取全局 GTS 吗？

TDSQL 采用了一个优化措施，此时没有请求三次 MC 获取 COMMIT_GTS，而是复用当前 MySQL 节点上最大的“快照 GTS”。如下图第三阶段所示，三个先后开启的非分布式事务，“同时”提交，此时不再请求 MC 而是本地获取全局最大的快照 GTS 253。SET1 的 GTS 与 SET2 本身没有依赖关系，对 SET1 而言，发生的是自身的一阶段的分布式事务，所以这里无需通过 MC 获取全局最新 GTS 只需要保证事务的局部时序性，这样可以减少和 MC 之间的通信的开销。

TDSQL 在 MC 开启之后进行多种优化来提升性能。我们在内外部进行多次测试、验证，得出的结论是 MC 开启之后有一定损耗，但可以有效的控制在 10%左右，对业务来说影响比较小。在一些 INSERT 和 UPDATE 场景下我们对相关模型也进行了优化调整，所以带来的性能提升非常高。

图中可以看到，我们在一些混合的 TPMC 场景测试下，在一台 16C 64G 的机器下测试模型，开启和关闭 GTS 对性能影响较小。TDSQL 使用全局 MVCC，再加上轻量的 MC 特性，可以将 GTS 的通信次数降低，从而带来较大的收益。

四、TDSQL 应用实践

分布式事务或分布式一致性，不仅仅是数据库要去解决的问题，很多场景下应用下也会面临相同的挑战。对于热点账户的入账或者面对面收账等高并发的场景，数据库仍然存在自身极限，我们认为需要结合应用数据库一起做优化。

常规方案是将账户系统进行切割，包括做单元化、大小账户分离等。但是在这些场景中，一个比较极端的场景是：热点账户，只有一行记录，怎么进行拆分？这种场景下，我们就要结合应用优化配合 TDSQL 来实现。

以下图为例，有两个账户，账户 C 和账户 B 之间进行转账，这个过程中一个减少、一个增加。如果我们通过数据库的分布式事务来进行实现，就会有上限值。如果要谋求更低的处理时效，就需采用异步消息的方式。

比如热点商户账户收单等场景下，仅靠数据库层分布式事务已经不能满足海量的并发场景，采用异步消息优化的同时我们也会采用多级对账机制。应用层会有一个交易订单，交易订单标记着这笔分布式事务成功与否。当交易订单形成后，即使该事务在过程中出错，也可以通过应用层的补偿机制对这个事务进行处理。从而实现实时出账+异步批量入账，减少行锁竞争。

在下图的红包转账场景下，还需要分布式缓存+全局缓存来进一步深入优化。这种场景下，除了采用异步账户外，我们还需要将一个热点账户拆成多个平行子账户，使用消息队列和分布式缓存，通过多级缓存机制，分别实现多级对账、多级缓存、平行热点账户、单元化等实现实时出账、批量异步入账。这样可以将转账逻辑从频繁的网络之间的交互变成一次批量请求，也极大提高了系统的并发能力和事务处理的响应速度。

总的来说，在上述这些极限的高并发场景下，我们需要在应用侧和数据库侧做优化和结合，包括采用异步消息、多级缓存机制等。

作为领先的国产分布式数据库，TDSQL 针对新型企业级信息化以及快速实现国产化的转型升级需求，具备数据强一致、金融级高可用、高性能低成本、线性水平扩展、企业级安全、便捷智能运维等核心特性。

目前，TDSQL 已服务金融、政务、工业制造等多个行业领域。未来五年，TDSQL 将帮助 1000 家金融机构实现核心系统国产化转型，持续助力国产数据库未来发展。