微众银行数据库架构编年史

转眼间，已在微众工作近七载。这期间，一直负责微众银行数据库平台的建设和运营。微众银行在成立之初，IT基础建设就没有选择传统的IOE集中式架构路线，转而选择采用了基于单元化的分布式架构。在这种大的背景下，微众银行的数据库的架构演进，也是走出了一条不同寻常的路线。

本文将以编年史的形式，和大家分享一下微众数据库架构的演进过程，既是对自身工作的一个总结，也希望可以为同行业带来一些价值和参考。

在微众银行IT建设的第一阶段，基于成本和效率的考虑，IDC的建设采用了两地三中心的架构（简称IDC 1.0架构）。两个同城数据中心作为生产中心，一个异地容灾中心作为灾备。

IDC 1.0架构

在IDC 1.0架构的基础上，我行设计了基于DCN的单元化分布式架构（DCN，即Data Center Node的简称）。一个DCN，可以理解为一个从应用层到中间件层，到数据库层的完整的自包含的逻辑单位。

不同的业务产品被归类到不同类型的产品DCN；同一个业务产品，再通过一定的计算规则（比如客户号的hash），分配到每一个小的DCN产品单元中；每一个DCN单元会有一个核定的用户承载量；当一个DCN的用户承载量用满时，便可以发起新的DCN单元扩容，以此来实现水平扩展的特性。

在实际两地三中心的部署架构中，每个DCN都会有同城主DCN、同城备DCN、异地备DCN三种角色，即每个DCN也都实现了两地三中心的架构。同时，不同的DCN主分片，在同城的两个IDC之间是交叉部署的，以此可以实现DCN单元粒度上的同城双活。

DCN主备交叉部署架构

那么，基于这种IDC和DCN架构的前提下，数据库如何选型？架构如何设计呢?

客观的讲，在2014的时候，满足金融级要求的国产分布式数据库产品并不多，可选范围也非常有限。经过充分的调研也评估，微众最终选择了腾讯的数据库产品TDSQL，作为DCN架构下的核心数据库。

TDSQL有以下几个特性吸引了我们：

1. TDSQL基于MySQL内核做了定制优化，实现了主备强一致的数据同步，同时还保证了性能上的极小损失。数据的一致性保证是金融场景的最基本要求。

2. TDSQL全兼容MySQL协议，通用性强，适用面广大，迁移难度低。

3. TDSQL已在腾讯内部的计费场景中大量实践应用，并取得了较好的效果。

基于TDSQL，我们设计了如下的数据库部署架构：

两地三中心的数据库部署架构

可以看到，TDSQL的部署架构也遵循了两地三中心的原则，分为同城主数据库SET，同城备数据库SET和异地备数据库SET。同城主数据库SET和同城备数据库SET由三个数据副本构成（一主二备），异地备数据库SET由两个数据副本构成（一主一备）。

SET内部基于TDSQL的主备强一致数据同步功能，可以实现数据的高可靠和零丢失。

IDC 1.0时代的架构基本满足了我行的业务发展需求，但还是存在以下几个问题：

1. 同城双中心之间的数据库同步是准实时的，在极端场景下是有可能出现数据丢失的（同城RPO不为0）

2. 只实现了DCN分片单元粒度的多活，还没有实现真正意义上的应用跨同城数据中心多活；

3. 在单个DCN或者IDC出现故障时，需要做人工的同城容灾切换，耗时太久（RTO约二小时）

4. 同城有6份数据库副本，资源成本较高。

既然有问题，那就得继续优化架构。所以我们提出了第二阶段的架构优化目标：

• 实现应用系统的同城跨数据中心多活；

• 数据库同城RPO=0，同城RTO接近于0；

• 降低数据库副本数，减少成本。

首先，我们在同城新增了一个数据中心，由同城的两中心，变为了同城三中心（IDC 2.0），这是实现同城应用多活架构的前提。

IDC 2.0架构图

基于IDC2.0，我们设计了同城三中心多活方案，应用层和数据库的架构都做了相应的调整。

同城多活架构

数据库层面，由原来的双中心主备SET的架构模式，调整为单SET三副本跨三中心部署的模式，主节点可以进行读写，备节点只读，通过TDSQL的数据强一致同步功能，保证三副本跨中心的数据一致性；通过TDSQL的高可用一致性秒级自动切换功能，保证了在数据库主节点，甚至是一个数据中心宕机的情况，可以在秒级时间内，将数据库主节点切换到另一个IDC，继续提供服务。

以上两点，可以实现数据库层面的同城跨IDC的RPO=0，RTO达到秒级。以此为前提，应用层就可以实现真正的跨同城数据中心多活。也就是应用层可以在同城的三个数据中心内各部署一套对等的应用系统，接入业务流量，经过接入层转发，最终到数据库的主节点上（开启读写分离的情况下，读流量可以转发到备节点上）。

细心的同学可能会发现，这个同城多活会带来两个跨数据中心流量的问题：

1. 应用层到数据库主节点之间会产生跨数据中心流量（当应用层和数据库主节点不在同一个数据中心时）

2. 数据库的主备节点之间也会产生跨数据中心流量（TDSQL主备强一致同步）

跨数据中心流量首先对数据中心间的网络质量要求很高，同时也会带来业务整体响应时间上的增加。

针对这些问题，我们在数据中心和网络建设方面，确立了一些原则，比如尽量保证数据中心之间的距离在20~50公里之间；数据中心之间采用专线互联，并且进行多路径备份；数据中心进行万兆改造等等。这些措施可以保证数据中心之间的网络包延迟控制在2ms以内，并且提供较高网络稳定性。

同时，在数据库层面，TDSQL也针对主备节点跨数据中心强同步的场景，做了性能上的优化，尽量降低性能和响应时间的损耗。

从最终上线运行的结果来看，虽然跨数据中心流量确实带来了业务整体联机交易耗时的增加，但都在可预期和可接受的范围内。

同城应用多活的架构改造，进一步提升了整体的可用性，简化了容灾架构，同时也将数据库的六副本缩减为三副本，极大的降低了资源成本，可以说很好的完成了架构优化目标。

随着业务的快速发展，DCN的数量也在快速增加，DCN的水平扩展特性很好的支撑了业务的快速增长。但在某些非DCN架构的中后台业务场景中，单实例架构的TDSQL逐渐遇到了容量或者性能上的瓶颈。

一个比较典型的场景就是安全存证类的数据存储。这个场景属于中后台业务，需要持续存储交易行为类的数据，以供随时审计或者举证，所以一般是不能删除的。随着业务规模增涨，存证数据也会持续的增涨。

然而对于单实例的TDSQL或者MySQL实例来说，是要求不能超过3TB的存储容量的，一个原因是硬件层面的限制（SSD的单盘容量），另一个原因是单实例过大的容量，会带来数据库性能上的不确定性和运维的复杂性。

按照比较传统的解决方案，可以选择基于中间件的分库分表方案来解决这个问题（TDSQL也有提供分库分表的版本）。

然而分库分表事实上是对业务开发和DBA都不太友好的一种方案。对业务开发来说，因为分库分表一般在语法和SQL使用层面都会有一些限制和限定，所以一般需要重构代码和SQL，以适配分库分表环境下的数据库使用；对于DBA来说，分库分表的扩展性不是那么灵活，DDL等日常操作也比较得复杂，使得整体的运维工作量增加。

我们不想走回分库分表的老路，所以也在探寻有没有更优雅、更先进的解决方案。2018年下半年开始，NEWSQL的概念逐渐兴起，带来了一种全新的share nothing的分布式架构的数据库（基本上是以Google Spanner分布式架构为原型）。

经过充分的调研和评估，我们最终选取国产开源的NEWSQL数据库产品TiDB进行尝试。TiDB主要有以下几个特性吸引了我们：

1. TiDB采用了标准的Share Nothing架构，计算与存储分离，并且都可以做到水平扩展，且对业务层透明。

2. TiDB采用MySQL协议体系，与我们当前的协议体系兼容度高，降低业务的开发和迁移成本以及接入门槛。

3. TiDB采用开源的模式进行运营，社区较为活跃，版本迭代较快，并且已有一部分的互联网用户开始使用。

TiDB整体架构

可以说，TiDB的特性可以很好的解决我们的需求和瓶颈，但当时TiDB还是属于一个非常新兴的数据库产品，稳定性和成熟性不够，所以我们也是非常谨慎的进行充分的测试和验证，在生产上首先选取的比较边缘的业务场景进行灰度，并且准实时同步一份数据到TDSQL进行兜底。

TiDB在微众的部署架构也类似于TDSQL，利用同城三机房的硬件优势，采用同城三副本跨三中心部署，可以有效的支持应用同城多活架构。

TiDB部署架构

经过近两年多的运营，我们已将TiDB应用在安全、智能监控、数据归档、反欺诈、反洗钱、历史交易明细查询等各类中后台业务中。随着TiDB的版本逐渐成熟，整体的稳定性和可运维性也提升了不少。

回头来看，虽然我们冒着吃螃蟹的风险，采用了NEWSQL的方案而主弃了分库分表的方案，但带来的收益也是巨大的。

目前，TDSQL继续作为核心数据库，承载DCN架构下的核心系统；TiDB作为补充，承载非DCN架构下的、对容量和扩展性要求较高的中后台系统。TiDB作为微众整个单化元架构的补充，很好的补齐了数据库层面的短板。

经过两年多对TiDB数据库的使用，踩了不少坑，也积累了不少经验。TiDB本身随着版本迭代也更加成熟稳定，逐渐形成企业级的数据库产品。

2020年初，我们收到了贷款科技部门针对贷款核心的日终批量系统的优化需求。

当时，贷款核心系统的日终批量系统是部署在业务DCN内部的，和联机系统复用DCN内的TDSQL数据库资源。随着交易数据的日积月累，贷款核心系统的批量面临着以下几个问题：

1. 批量的耗时持续增涨（优化前已近三小时），如果因为某种原因批量需要重跑，有比较大的超时风险。

2. 批量系统和联机系统都在DCN内部署，批量系统带来的数据库高负载，会对联机系统产生影响。

3. 受限于MySQL的主备复制的原理限制以及单实例的性能瓶颈，无法继续通过提高应用层并发来提升批量效率。

4. 批量效率逐渐成为单个DCN的用户容量瓶颈，而非实际的用户量。

贷款核心批量架构（优化前）

基于以上问题，业务部门也提出了优化目标：

1. 将整个批量系统重构（包括应用层和数据库层），核心业务微粒贷的整体批量耗时缩短到半小时内以（在限定的资源内）；

2. 将批量系统的资源和联机系统完全解耦（包括应用层和数据库层）；

3. 批量系统的数据库需要具备可水平伸缩的特性。

   
   

最初看到这个优化目标，感觉还有挑战的。特别是每天数亿条帐务的批量计算处理，需要优化到半小时以内完成，应该没有那么容量。

经过评估，我们最终决定尝试用NEWSQL数据库TiDB来承载贷款核心的批量系统（优化后的架构如下图）。批量数据每天通过DCN内的TDSQL近实时的同步到TiDB集群进行汇总，然后由批量应用程序在TiDB集群进行批量计算和加工。经过近一年的持续优化、调整和灰度验证，最终项目顺利上线，并且完全达到了既定的优化目标。

贷款核心批量架构（优化后）

下表是微众5个主要贷款业务的核心批量优化前后的耗时对比，优化效果非常明显。

在整个项目的实施的过程中，踩坑不少，也总结了不少的优化经验和教训，主要有以下几点：

• 针对批量应用的SQL，进行SQL batch化的改造，提升单个SQL的效率；

• 对于频繁访问的热点静态数据进行缓存，减少SQL的请求次数；

• 对复杂SQL进行内存占用优化、执行计划优化等，降低SQL的耗时。

在share nothing架构的数据库中， 数据热点是经常会遇到的一个问题，如果分片规则或者应用的写入的规则不合理，很容易就形成针对某一个数据库分片的热点，导致数据库响应变慢，甚至假死。

贷款核心的批量数据表，都是数亿级别的数据量导入，热点问题更加明显。针对这种超大表的数据导入，我们联合数据库厂商，开发了数据表预打散的功能，完全避免了热点问题。

贷款核心批量的数据正确性至关重要。在优化后的架构，批量数据表需要从多个TDSQL源近实时的汇总同步到一个TiDB集群中，并进行合表处理。为了保证数据同步的可靠性和准确性，我们在三个层面做了优化：

• 对数据同步工具做了高可用架构优化，确保没有单点问题，并且在某个同步节点故障后，可以自动进行替换和恢复；

• 对数据同步增加全方位的监控，包括同步状态、同步延迟、数据源存活状态、目标端存活状态等；

• 在应用层增加数据分片同步的实时校验。针对每一个数据分片，应用层都会计算一个CRC校验值，并由上游的TDSQL同步到下游的TiDB，待此分片数据同步完后，在下游再进行一次CRC计算，并和上游同步过来的CRC值进行比对；除了分片校验，还会有最终的数据条目数量的最终一致性校验。

• 针对日常的服务器故障，或者数据库bug，导致的批量中断，准备了批量断点续跑的预案，并在生产环境定期演练；

• 针对可能的数据错乱导致批量需要重跑的场景，通过批前的rename备份表的方式，可以实现快速的批量重跑。

• 针对极端的灾难场景下，需要重建数据库进行批量重跑的场景，通过批前的冷备数据，进行快速的数据库重建和导入，从而实现批量重跑。

TiDB数据库在贷款核心批量系统的应用，是对微众整个单元化架构的又一次补充和完善。我们经常说，数据库没有银弹，没有一种数据库能够适用所有的业务场景。针对每个场景，用最适合的数据库产品和数据库架构，才是价值的最大化。

除了关系数据库产品，我们也大量使用了Redis来适合大部分需要高并发、低延迟响应的读场景。在尽量保证架构一致性的前提下，我们根据业务的实际需求，也少量引入了Monggo DB、PostgreSQL、Oracle等数据库产品。

未来，我们也将在数据库的云原生、数据库的智能运维、数据库的硬件国产化、HTAP场景的应用实践等方向继续探索，不断提升和完善我们的架构，为国产数据库在金融场景的应用实践贡献自己的一份力量。

作者简介

基础科技产品部/数据库运维室