TDSQL在微众银行的大规模实践之路

作者 | 胡盼盼、黄德志

一、2014 年:基于分布式的基础架构

微众银行在 2014 年成立之时,就非常有前瞻性的确立了微众银行的 IT 基础架构的方向:摒弃传统的基于商业 IT 产品的集中架构模式,走互联网模式的分布式架构。

众所周知,传统银行 IT 架构体系非常依赖于传统的商业数据库,商业存储以及大中型服务器设备,每年也需要巨大的 IT 费用去维护和升级,同时这种集中式的架构,也不便于进行高效的实现水平扩展。从过往经验来看,当时除了 oracle 等少数传统的商业数据库,能满足金融级银行场景的数据库产品并不多。

当时腾讯有一款金融级的分布式数据库产品 TDSQL,主要承载腾讯内部的计费和支付业务,其业务场景和对数据库的可靠性要求,和银行场景非常类似,同时也经受了腾讯海量计费业务场景的验证。微众银行基础架构团队,经过多轮的评估和测试,最终确定和腾讯 TDSQL 团队合作,共同将 TDSQL 打造为适合银行核心场景使用的金融级分布式数据库产品,并将 TDSQL 用于微众银行的核心系统数据库。

二、Why TDSQL?

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

TDSQL 架构介绍

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

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

图 1 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 集群的大脑,负责整个集群的管理和调度。

TDSQL noshard 与 shard 模式

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

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

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

图 2 TDSQL noshard 与 shard 模式

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

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

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

Watch 节点模式

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

自动化监控与运维

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

图 3 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 的整体架构如图所示

图 4 DCN 架构模型

四、微众银行 IDC 架构

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

图 5 微众银行 IDC 架构

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

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

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

图 6 微众银行基于 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。如下图所示:

图 7 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 万 +。如图 8 所示:

图 8 微众银行 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 相关运维工作。

活动推荐

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190816A0J82100?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券