金融级分布式数据库打造！TDSQL 在微众银行的大规模实践

微众银行在 2014 年成立之时，就非常有前瞻性的确立了分布式架构的基础架构。当时，腾讯有一款金融级的分布式数据库产品 TDSQL，其业务场景和对数据库的可靠性要求，和银行场景非常类似。微众银行和腾讯 TDSQL 团队合作，共同将 TDSQL 打造为适合银行核心场景使用的金融级分布式数据库产品，并将 TDSQL 用于微众银行的核心系统数据库。本文是对整个实践历程的总结。

一、背景介绍

微众银行在 2014 年成立之时，就非常有前瞻性的确立了微众银行的 IT 基础架构的方向：摒弃传统的基于商业 IT 产品的集中架构模式，走互联网模式的分布式架构。众所周知，传统银行 IT 架构体系非常依赖于传统的商业数据库，商业存储以及大中型服务器设备，每年也需要巨大的 IT 费用去维护和升级，同时这种集中式的架构，也不便于进行高效的实现水平扩展。从过往经验来看，当时除了 oracle 等少数传统的商业数据库，能满足金融级银行场景的数据库产品并不多。

当时，腾讯有一款金融级的分布式数据库产品 TDSQL，主要承载腾讯内部的计费和支付业务，其业务场景和对数据库的可靠性要求，和银行场景非常类似，同时也经受了腾讯海量计费业务场景的验证。

微众银行基础架构团队，经过多轮的评估和测试，最终确定和腾讯 TDSQL 团队合作，共同将 TDSQL 打造为适合银行核心场景使用的金融级分布式数据库产品，并将 TDSQL 用于微众银行的核心系统数据库。

二、Why TDSQL？

为什么会选用 TDSQL，作为微众银行的核心数据库呢？本章节将会详细介绍 TDSQL 架构、以及 TDSQL 的核心特性，看看 TDSQL 是如何满足了金融级场景的数据库要求。

1.TDSQL 架构介绍

TDSQL 是基于 MySQL/Mariadb 社区版本打造的一款金融级分布式数据库集群方案。在内核层面，TDSQL 针对 MySQL 社区版本和 Mariadb 社区版本的内核，在复制模块做了系统级优化，使得其具备主备副本数据强一致同步的特性，极大提升了数据安全性，同时相对原生的半同步复制机制，TDSQL 强一致复制的性能也有极大提升。

TDSQL 集成了 TDSQL Agent、TDSQL SQLEngineSQLEngine、TDSQL Scheduler 等多个模块，实现了读写分离、AutoSharding、自动主备强一致性切换、自动故障修复、实时监控、实时冷备等一系列功能。TDSQL 架构模型如下面两张图所示。

图 TDSQL 架构模型与 SET 模型

我们可以从横向和纵向两个维度来理解 TDSQL 的架构。

横向是 TDSQL 的请求处理路径：请求通过 APP 发出，经过负载均衡模块，转发到 TDSQL SQLEngine 集群；TDSQL SQLEngine 收到请求后，进行请求解析，然后转发到 set 单元内的数据库实例节点上（写请求到 master，读请求可以到 master 或 slave）；数据库实例处理好请求后，回包给 TDSQL SQLEngine，TDSQL SQLEngine 再通过负载均衡模块回包给 app。

纵向是 TDSQL 集群的管理路径：TDSQL 的一个管理单元称为一个 set，每个 set 单元的每个数据库实例上，都会部署一个 TDSQL Agent 模块。Agent 模块会收集所在数据库实例的所有监控信息（包括节点主备角色信息/节点存活状态/请求量/TPS/CPU 负载/IO 负载/慢查询/连接数/容量使用率等等），上报到 ZooKeeper 集群；ZooKeeper 相当于整个 TDSQL 集群元数据存储管理中心，保存了集群所有元数据信息；TDSQL Scheduler 模块会监控 ZooKeeper 的所存储的上报信息，并根据集群状态启动不同的调度任务，相当于 TDSQL 集群的大脑，负责整个集群的管理和调度。

2. TDSQL noshard 与 shard 模式

TDSQL 提供了 noshard 与 shard 两种使用模式，如下图所示。

图 TDSQL noshard 与 shard 模式

所谓 noshard 模式，就是单实例模式，不做自动的分库分表，在语法和功能上完全兼容于 MySQL，缺点是只支持垂直扩容，这会受限于单实例服务器的性能和容量上限，无法进行水平扩展。

Shard 模式即 AutoSharding 模式。通过 TDSQL SQLEngine 模块，实现数据库的 Sharding 和分布式事务功能，底层的数据打散在多个数据库实例上，对应用层还是统一的单库视图。Shard 模式可以实现容量和性能的水平扩展，通过两阶段 XA 支持分布式事务和各种关联操作，但是目前还不支持存储过程，同时在建表的时候需要业务指定 shard key，对部分业务开发来说觉得会有一定的侵入性 。

微众银行当时在做系统架构的时候充分考虑了是采用 shard 版本的纯分布式数据库还是从应用层的角度来做分布式，通过大量的调研分析，最终觉得采用应用做分布式是最可控，最安全，最灵活，最可扩展的模式，从而设计了基于 DCN 的分布式可扩展架构，通过在应用层做水平拆分，数据库采用 TDSQL noshard 模式，保证了数据库架构的简洁性和业务层兼容性，这个后面会详述。

3. 主备强一致切换与秒级恢复

TDSQL 通过针对 MySQL 内核源码的定制级优化，实现真正意义上的多副本强一致性复制，通过主备部署模式，可以实现 RPO=0，即数据 0 丢失，这对于金融场景是至关重要也是最基础的要求；同时基于 TDSQL Agent 和 Scheduler 等模块，也实现了自动化的主备强一致切换，在 30 秒内可以完成整个主备切换流程，实现故障 RTO 的秒级恢复。

4. Watch 节点模式

TDSQL slave 节点提供了两种角色，一种是 follower 节点，一种是 watch 节点。Fllower 节点与 watch 节点都从 master 节点实时同步数据，但 watch 节点不参与主备选举和主备切换，只作为观察者同步数据。Follower 节点和 watch 节点的角色可以在线实时调整。

5. 自动化监控与运维

TDSQL 配套提供了赤兔管理平台系统，来支持整个 TDSQL 集群的可视化、自动化的监控和运维功能。如下图所示，为 TDSQL 赤兔管理平台的运行界面。

图 TDSQL 赤兔管理平台

通过 TDSQL 赤兔管理平台，可以实现监控数据的采集与显示，告警和策略配置，日常运维操作（主备切换，节点替换，配置更改等），数据库备份与恢复，慢查询分析，性能分析等一系列功能，极大的提升了运维效率和运维准确性。

基于以上的 TDSQL 的架构和特性，我们认为 TDSQL 很好了满足金融业务场景中对数据库的高可用、高可靠、可运维的要求，同时基于 MySQL 和 X86 的软硬件平台，也能极大的降低数据库层面的 IT 成本，从而极大降低户均成本，非常适用互联网时代的新一代银行架构。

三、基于 DCN 的分布式扩展架构

前文提到，微众银行为了实现业务规模的水平扩展，设计了基于 DCN 的分布式可扩展架构，从而即实现了扩展性，也保证了数据库层面架构以的简洁性。

DCN，即 Data Center Node(数据中心节点)，是一个逻辑区域概念，DCN 是一个自包含单位，包括了完整的应用层，接入层和数据库。可以通俗的理解为，一个 DCN，即为一个微众银行的线上的虚拟分行，这个虚拟分行只承载微众银行某个业务的一部分客户。通过一定的路由规则（比如帐户号分段），将不同的客户划分到不同的 DCN 内。一旦某个 DCN 所承载的客户数达到规定的上限，那么这个 DCN 将不再增加新的客户。这时通过部署新的 DCN，来实现容量的水平扩展，保证业务的持续快速发展。

不同的客户保存在不同的 DCN，那么就需要有一个系统来保留全局的路由信息，记录某个客户到底在哪个 DCN，这个系统就是 GNS（Global Name Service），应用模块会先请求 GNS，拿到对应客户的 DCN 信息，然后再去请求对应的 DCN。GNS 使用了 redis 缓存，以保证较高的查询 QPS 性能，同时采用 TDSQL 做持久化存储，以保证数据的安全性。

RMB（Reliable Message Bug），可靠消息总线，是 DCN 架构的另一个核心模块，主要负责各个业务系统之间高效、准确、快速的消息通信。DCN 的整体架构如下图所示。

图 DCN 架构模型

四、微众银行 IDC 架构

有了基于 DCN 的基础架构模型，下一步就是基础物理环境的建设。微众银行经过 4 年多的发展，目前已发展成为两地六中心的架构，如下图所示。

图 微众银行 IDC 架构

其中两地位于深圳和上海，深圳作为生产中心，在深圳同城有 5 个 IDC 机房，上海作为跨城异地容灾，有 1 个 IDC 机房。深圳 5 个同城 IDC，通过多条专线两两互联，保证极高的网络质量和带宽，同时任何两个 IDC 之间的距离控制在 10~50 公里，以保证机房间的网络 ping 延迟控制在 2ms 左右。这一点非常重要，是实现 TDSQL 同城跨 IDC 部署的前提。

五、基于 TDSQL 的同城应用多活

基于以上的 DCN 架构和 IDC 架构，我们设计了 TDSQL 数据库在微众银行的部署架构。如下图所示。

图 微众银行基于 TDSQL 的同城多活架构

我们采用同城 3 副本+跨城 2 副本的 3+2 noshard 部署模式。同城 3 副本为 1 主 2 备，分别部署同城的 3 个 IDC 中，副本之间采用 TDSQL 强一致同步，保证同城 3 IDC 之间的 RPO=0，RTO 秒级恢复。跨城的 2 副本通过同城的一个 slave 进行异步复制，实现跨城的数据容灾。基于以上架构，我们在同城可以做到应用多活，即联机的业务流量，可以同时从 3 个 IDC 接入，任何一个 IDC 故障不可用，都可以保证数据 0 丢失，同时在秒级内可以恢复数据库服务。

在同一 IDC 内，服务器之间的 ping 延迟通常在 0.1ms 以内，而同城跨 IDC 之间服务器的 ping 延迟会大大增加，那是否会影响 TDSQL 主备强同步的性能呢？另外 IDC 之间的网络稳定性能否保证呢？

我们通过以下几个措施来消除或者规避这个问题。

首先，在基础设施层面，我们会保证同城的三个 IDC 之间的距离控制在 10~50 公里左右，控制网络延迟在 2ms 左右；同时在 IDC 之间建设多条专线，保证网络传输的质量和稳定性；其次，TDSQL 针对这种跨 IDC 强同步的场景，作了大量的内核级优化，比如采用队列异步化，以及并发复制等技术。通过基准测试表明，跨 IDC 强同步对联机 OLTP 的性能影响仅在 10%左右。

从我们实际生产运营情况来看，这种同城跨 IDC 的部署模式，对于联机 OLTP 业务的性能影响，完全是可以接受的，但对于集中批量的场景，因为累积效应，可能最终会对批量的完成时效产生较大影响。如果批量 APP 需要跨 IDC 访问数据库，那么整个批量期间每次访问数据库的网络延迟都会被不断累积放大，最终会严重影响跑批效率。为了解决这个问题，我们利用了 TDSQL 的 watch 节点的机制，针对参与跑批的 TDSQL SET，我们在原来一主两备的基础上，额外部署了一个与主节点同 IDC 的 WATCH 节点，同时保证批量 APP 与主节点部署在同一 APP。如下图所示。

图 TDSQL 带 WATCH 节点的部署模式

WATCH 节点与主节点同 IDC 部署，从主节点异步同步数据。因为是 WATCH 节点是异步同步，所以主节点的 binlog 会确保同步到跨 IDC 的另外两个备节点事务才算成功，这样即使主节点所在的 IDC 整个宕掉，仍能保证数据的完整性，不会影响 IDC 容灾特性。当主节点发生故障时，scheduler 模块对对比 watch 节点和其他 2 个强同步备机的数据一致性，如果发现 watch 节点的数据跟另外 2 个 idc 数据一样新（这是常态，因为同 IDC 一般都比跨 IDC 快），则优先会将这个 watch 节点提升为主机。这就保证了批量 APP 与数据库主节节点尽量处于同一个 IDC，避免了跨 IDC 访问带来的时延影响。

通过以上部署架构，我们实现了同城跨 IDC 级别的高可用，以及同城跨 IDC 的应用多活，极大提升了微众银行基础架构的整体可用性与可靠性。

六、TDSQL 集群规模

微众银行成立 4 年多以来，业务迅速发展，目前有效客户数已过亿级，微粒贷，微业贷等也成为行业的明星产品。在业务规模迅速增长的过程中，我们的数据库规模也在不断的增长。当前微众银行的 TDSQL SET 个数已达 350+（生产+容灾），数据库实例个数已达到 1700+，整体数据规模已达到 PB 级，承载了微众银行数百个核心系统。在以往的业务高峰中，最高达到日 3.6 亿+的金融交易量，最高的 TPS 也达到了 10 万+，如下图所示。

图 微众银行 TDSQL 业务规模

在过去 4 年多的运营中，TDSQL 也从未出现过大的系统故障，或者数据安全问题，同时基于 TDSQL 的 X86 的软硬件架构，帮助微众银行极大的降低 IT 户均成本，极大提升了微众银行的行业竞争力。微众银行通过实践证明，TDSQL 作为金融级的核心数据库，是完全胜任的。

七、微众银行数据库现状及未来发

目前，TDSQL 承载了微众银行 99%以上线上数据库业务，同时我行也大量采用了 redis 作为缓存，以解决秒杀，抢购等热点场景，另外还有少量的 MongoDB 满足文档类的存储需求。同时我行从去年开始，也尝试引入了 NEWSQL 数据库 TiDB，解决少部分无法拆分 DCN，但同时又对单库存储容量或吞吐量有超大需求的业务场景。整体来看，我行目前的数据库主要有 TDSQL，TIDB 以及 Redis/MongoDB，TDSQL 主要承载核心系统业务，TIDB 作为补充解决单库需要超大容量或超大吞吐量的非联机业务需求，Reids 和 MongoDB 则主要是提供缓存及文档型的存储。

当然我们并不会止步于此，微众银行数据库团队和腾讯云 TDSQL 团队未来会有更加深入的合作。比如我们和腾讯云 TDSQL 团队合作的 TDSQL 智能运维-扁鹊项目，目前已在微众银行灰度上线，可以实时分析 TDSQL 的运行状态和性能问题，是提升运维效率的利器。我们和也在和 TDSQL 研发团队共同调研和评估 MySQL 8.0 版本，以及 MySQL 基于 MGR 的高可用功能，未来可能会尝试将 MySQL 8.0 和 MGR 集成到 TDSQL 系统中，并尝试在银行核心系统中试用。

作者介绍：

胡盼盼，微众银行数据库平台负责人。硕士毕业于华中科技大学，毕业后加入腾讯，任高级工程师，从事分布式存储与云数据库相关的研发与运营工作；2014 年加入微众银行，负责微众银行的数据库平台的设计规划和运营管理。

黄德志，微众银行数据库平台高级 DBA。2009 年加入平安科技，先后担任数据库资深开发工程师及资深运维工程师。2016 年加入微众银行任高级 DBA，负责 TDSQL 相关运维工作。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/9qjX1SLBcBzPBZSib02Lag