雷海林
腾讯云数据库专家工程师、TDSQL 首席架构师、Tech Lead
2007 从中南大学计算机系毕业后年加入腾讯，持续专注于金融级分布式数据库研发，带领团队实现多次业界领先的分布式数据库技术突破，在分布式事务、SQL 兼容性、内核安全、智能运维方面持续创新，产品获得大量金融客户的认可，市场规模大幅领先同业。
TP 场景是数据库应用中非常重要的业务场景之一。作为国内自研数据库的代表品牌之一，TDSQL 在 TP 领域有着很多积累和探索成果。在 2022 年第六期 DBTalk 技术公开课中，腾讯云数据库专家工程师雷海林带来了主题为《TDSQL 在 TP 领域的技术探索和实践》的分享，在这一主题上做了深入探讨。
TDSQL 产品介绍
腾讯公司 2002 年就形成了数据库团队，最初是解决腾讯内部的各种业务场景的需求。2013 年的时候我们开始对外输出，最早是自有云的形式，慢慢拓展了公有云，最后形成 TDSQL-TCE 版本。近两年我们每年都会发布大量产品配套工具。比如 TDSQL-A 主要做在线分析，22 年发布了纯自研的分析引擎 TDStore。我们在大客户方面做了很多拓展，一些大行、中小银行、股份制银行开始大规模应用 TDSQL。
整个 TDSQL 的产品形态包含三大分类，第一个是典型的 TDSQL 分布式产品，有三种引擎分别解决不同的应用场景需求，比如基于 MySQL 的引擎重点解决在线交易需求，PG 引擎会做 Oracle 兼容，还有自研的引擎提供更加智能的弹性伸缩能力。第二个是 TDSQL-A 分析引擎，针对检测分析场景。第三个是 TDSQL-C 云原生产品。
TDSQL 整体架构
简单来看一下针对 TP 场景的产品核心架构，整体分为三层，第一是计算层。SQL 引擎负责接受用户请求做 SQL 的下推、聚合、协议转换等，数据存储是由专门的存储服务负责，所以我们整体来看也是一个计算存储分离的架构。
存储层有我们自研的腾讯 TXSQL 内核，采用全局数据管理器负责全局事务的管理，保证整个分布事务的数据一致性。这些存储节点也需要综合的调度系统来做资源调度，包括主备自动切换、数据自动路由、自动分布，对外有一个专门的云端平台用来做健康管理，等等。
针对 TP 场景的关键特性
数据库针对 TP 场景需要具备六大关键特性：
1.
数据强一致。确保多副本架构下数据强一致，避免故障后导致集群数据错乱和丢失，实现全局一致性读。
2.
金融级高可用。确保 99.999%以上高可用；具备跨区容灾、同城双活、故障自动恢复能力。
3.
高性能低成本。为此腾讯研发了专门的 TXSQL 内核解决分布式场景需求，并实现软硬结合，还可支持读写分离、秒杀、红包、全球同服等超高性能场景。
4.
企业级安全性。具备数据库防火墙，支持透明加密、自动脱敏等，减少用户误操作/黑客入侵带来的安全风险。
5.
分布式设计。无论是资源还是功能均提供良好的扩展性、兼容性、业务使用便利性。
6.
便捷运维。拥有完善的配套设施，包括智能 DBA、自助化运营管理台。
针对于这些能力接下来会重点做介绍，首先来介绍主备一致性。现在 TDSQL 是通过 Raft 协议实现多数派的自动化选取，可以做 3 个或者 3 个以上节点的高可用。一个典型的部署案例采用 3 个 IDC，主 IDC 部署 2 个，这样 IDC 故障时可以快速切换。如果只是单个节点的故障，在同一个 IDC 内部就可以做选取，通过这样的架构可以满足任意挂掉 2 个节点对整体的可用性和数据一致性没有任何影响。我们最终达到的效果是在这种跨 IDC 的场景下的强同步模式，我们的性能跟异步是相当的，客户就可以放心使用。
第二，在分布式数据库里面非常难的一个点，是要解决全局一致性读的需求。比如一个转账场景可能会操作多个账户，在操作多个账户时会发现，一个账户要减，一个账户要做加，因为牵涉了两个账户其实是两个独立的数据库。MVCC 机制会把整个数据的交易、事务调节分成多个阶段。接下来我们要做两阶段提交，所以需要去进入 prepare 的状态，后面会进入 committed 状态。但因为会牵涉多个节点，所以各个节点进入这三个状态的时间是不一致的。
如果我们采用原生态去做数据读的时候会出现一些情况，可能有些节点已经提交了，有些节点还没有提交，最后会出现一个后果，如果两个账户都是 10 块钱，转账时，比如一个减 10 块，一个加 10 块，在大压力情况下我们会看到总账不准，有时候是 10，有时候 20，有时候 30，这样就说明系统不满足全局一致性读的要求，就是因为多个节点缺少全局协调。
怎么解决这个问题？首先肯定是要对内核进行改造，要做全局事务管理，所以在我们 TDSQL 的产品里提供一个 MC 或者全局 GTM。它提供一个全局事务 ID，通过事务 ID 可以确保分布在多个节点的事务都用同一套 ID。这样整体的事务流程会多两支网络交互，在提交的时包括 binlog 生成也要置上 GTS，同时我们还要对内核改造，将原生的事务 ID 映射成 GTS。
映射的效率是非常关键的指标，因为对于 MySQL 来说，所有的数字读取采用 MC 模型，原先是读取事务 ID，事务 ID 是存在记录条数行上的，但我们现在要做一个映射，所以要设置一个非常高效的映射算法。另外引入 MC 之后势必会对整体的流程增加一些交互，所以我们也优化了异步化、流水线等技术来确保这些技术对整体的性能影响控制在 5%以内。通过这个技术让事务交易不多、不错。
全局事务 ID 自身的可用性、性能是非常关键的指标。通过一系列优化，我们可以轻松实现单个集群上千万事务的吞吐能力。
接下来我们看高可用性的问题。比如数据库一年要分几个版本，我们希望升级版本过程对用户来说是无损的，对业务不产生影响，这样就可以加大升级频率，确保我们的产品竞争力持续提升，新功能快速推给用户使用。
对于 SQLEngine 来说，因为我们是无状态的应用，可以做快速的容量管理、扩缩容。因为不需要去搬迁数据所以它可以做到很轻量。上图就是我们的实现原理。
除了计算层要升级，存储层也要升级。存储层借鉴我们在做扩容、做主备切换的思路，采用主备切换的方式。这个切换的过程跟故障切换不一样，可以做到对业务完全没影响。我们新产生一个进程，先完成数据拷贝、数据校验，进行追数据的阶段。整个追的阶段可以分成几个环节，比如第一个延迟很低，接下来要短暂冻结我的一个事务，等待我们的事务全部结束，结束完成之后就可以切路由到新节点。这里 100 毫秒左右就可以完成路由切换，对业务的影响是非常少的。
另外一点，在 TP 层级就要做自动化切换。我们会把整个数据切换分成多个流程，再做好批量化操作的优化工作。比如一个集群有 1000 个节点，某一个 IDC 故障可能会影响几百套 set，我们可以确保这几百个 set 的切换能够同时在 60 秒内完成，这是非常强大的能力。通过这一点保证在可用性层面可以主动干预，比如要去做分级、流量调度，或者出现故障，不管是单个还是多个故障都可以做平稳、快速的切换，保证百分之百的成功率。
TDSQL 在高可用能力方面有一个非常强大的内核：TXSQL。这个内核是 TDSQL 的底座，做了很多性能优化。内核还针对分不是场景做了很多特性开发，并响应客户需求做了 SQL 兼容性、字段压缩、秒杀等优化。该内核在安全能力侧也有很多增强，对接了 KMS、国密算法，支持 SQL 防火墙、SQL 审计、字段加密等。TXSQL 还为 DBA 提供更佳的运营特性，如数据延迟删除，统计会话的 IO 信息，锁占用信息等等。我们还会及时解决客户遇到的内核 Bug，不需要等待社区缓慢解决。
下面抽几个典型的能力给大家做一些简单的介绍。
TDSQL 一个非常大的特点就是我们是线程池的模型，可以接受数万的连接。在这种大的并发场景下，线程池模型是非常大的优势。
TDSQL 里自始至终要去做数据的高可用，所以我们很早就提供强同步能力，要求数据在做同步的时候不阻塞业务线程，强同步的性能还要接近原生异步性能，还要保证数据一致性。
很多场景中用户会有秒杀类需求，或者并发量较大但要操作的 key 相对集中，这是锁冲突的问题。原生做法遇到锁冲突要做搜索检测，会成为非常大的热点。在 TDSQL 里会自动化识别这种热点 key，根本就不会让它进到 InnoDB 层，在 second 层会做一些排队、聚合，能显著降低压力，提高并发。
数据库里面除了并发之外，还有一个大的优化点就是锁的管理，无论是乐观锁还是悲观锁，总要有一个锁管理模块。这个锁管理模块自身也是用了很多 mutex 来实现的，一些管理锁的会话会产生一些 Hash 表，锁 Hash 表的引入也会存在瓶颈。所以优化的核心要点是做无锁化或者拆锁，最好就做一个无锁化。一方面将一些能拆的锁拆小，能无锁化的数字结构完全做无锁化。我们在这里做了很多工作，把整个事务链条做成无锁化，做完优化之后就很少出现主备之间因为锁冲突带来的问题，这样也能充分利用 CPU。
除了原生的逻辑复制外，我们马上就会做物理复制。原生 MySQL 的数字同步是通过 Binlog，Binlog 是设备层写的，同时设备层写的数字有 Binlog，Binlog 一般在事务提交阶段才会写。比如更新一百万行的数据，这一百万行要等到事务提交的时候。在数据做 recovery 的时候，InnoDB 自身也会写一个 redo log 的数据，比如一百万行可能每更新一条都会有一定概率会刷出去，MySQL 要做一个数据之前，我们要协调两个异步的同时写，这个叫内部差异。
现在如果我们不依赖于 server 层的 binlog，做成 InnoDB 层的 redo log 来复制，我们会发现主备没有什么延迟了，数据同步会特别实时。我们也会发现瓶颈主要是在 binlog 的提交，因为 binlog 是串行写的，而且量也特别大，所以这里是非常大的瓶颈。我们把它换成物理复制，性能有 3 倍的提升。
另外非常重要的点，我们有延迟删除，也有慢速删除。延迟删除类似于实现一个回收站，一些 drop 操作不小心做了，通过命令可以帮你快速恢复，DBA 也明显会踏实很多。对于一些大表的删除，比如 500G 大文件可能会引起文件系统稍微卡顿一下，对 redo log 的支付提交出现一些阻碍。我们也会有专门的优化，将整个删除操作做成平滑的技术，采用类似于 trancate 的机制帮我们实现慢速均匀化的删除。
TDSQL 还有非常强大的分布式能力，对于用户来说会屏蔽底层数据分布的一些细节，用户看起来其实是一张逻辑表，但 TDSQL 内部会把它分成多张表，分布式数据背后这些复杂的操作交给 TDSQL 帮你解决。
整个 SQL 架构来看，我们是完全兼容 MySQL 的协议，对用户来说屏蔽分布式的一些细节。另外我们也提供一些兼容 Oracle 的虚拟化能力，支持防火墙等的读写分离和各个分支表。整体来看是一个多模块、多线程的架构，分层、输入、管理、序列的解释分成多个模块。这里采用纯异步化的思路，确保整个 SQL 的执行是可以逐个并行化的，有下推，有汇聚。
TDSQL 还有做得非常好的一个点是运营能力。我们希望为用户提供一些非常清晰的指标。比如通过自主平台可以实时关注请求量、投放、告警，我们还提供一个强大的 DBA 系统去做性能诊断、问题诊断、故障诊断等等。我们希望问题能够得到自动化治愈，尽量给用户清晰化的、智能化的交互方式。
另外 TDSQL 的一个重点是支持我们很多客户去做自主可控、国产化。整个国产化工作分成多个模块，比如我们的内核是采用自研的 TDSQL 内核，对内核的掌控度是非常高的。第二个，我们支持的国产 OS、芯片支持得特别好。目前我们的很多银行客户也是在使用这种国产化的软硬件一体化架构，实质性能不会比 x86 差，有时候会更好。
标杆实践案例
最后来看两个案例。
TDSQL 除了提供分布式的能力之外，我们也提供单元化的架构，这样用户可以根据自己的需要去做后续的选择。比如有些场景、应用希望要做单元化、微服务，这样应用可以更少依赖数据库本身的能力，同时也可以做更智能化的调度。有一些场景做完单元化之后要去做数据的汇总、统计，也可以用分布式来完成。TDSQL 原生提供这种单元化到分布式的同步，叫做 DBbridge。比如平安银行信用卡中心就采用单元化的架构。它的业务系统是单元化的架构，自己业务有一个路由层，路由层接下来把客户分成叫做 DSU 的模块，每个 DSU 模块里面有独立的业务，完整的应用系统，有各种应用服务，不同的 DSU 之间的用户是不相交的，一个用户路由到一个 DSU，应用层去解决分布式的问题。比如他去做一个转账是在每个 DSU、应用层去做，这样对于整个应用的要求还是比较高的。但是采用这种架构，我们也可以看到它的效果确实是非常好的，相对于传统架构，性能得到接近 10 倍的提升，足够支撑未来很多年的业务容量。
第二个好处是故障隔离，每一个单元的故障最多就影响这个单元。比如一个银行分成 32 个单元，有故障也最多影响这 1/32。当然我们还有很好的容灾机制，基本上不会出现整个单元故障的。第三个好处是容量管理，30 来个单元不够了，可以快速去做扩容，系统具备很好的数据迁移、校验等能力。灰度升级也是一个好处，比如我先搞一套灰度体验的集群，TDSQL 的量可能会比较少，可以快速去做一些演练。高可用环节我们也做了很多工作，可以做各个模块的无损升级，用户的体验是非常好的。
很多客户不希望采用微服务架构，希望将整个复杂度交给 TDSQL 来解决，采用 TDSQL 原生的分布式技术。比如某国有大行采用我们的分布式数据库，这个分布式数据库是典型的多 set 化，多个 set 之间对用户、应用来说是无感知的。我们整体实现了 RTO 能够小于 30 秒，同时整个架构也提供非常强大的运营管理平台，既可以直接使用，也可以做快速对接。因为我们整个自动化架构是一个开放的架构，所有接口都提供很容易使用的 API，方便用户去做 IP 的集成。
同时 TDSQL 对国产化的配套支持是做得非常好的，软硬件各种芯片、架构、OS，包括数字库是完全做到可控。同时采用分布式架构相对传统架构有非常大的好处就是容量的管理，比如原来四套不够我可以扩容到八套，快速完成数据搬迁，这样业务接进来可以自动化快速完成容量管理操作，有效提升系统效率，节约成本。我们的银行客户等各行业的案例现在数量很多，而且还在快速增长中。
