共计 5003 个字符，预计需要花费 13 分钟才能阅读完成。
编者按
本文由微众银行数据库负责人胡盼盼撰写，介绍了微众银行自 2014 年以来从传统 RDBMS 到 NewSQL 的架构演进，以及 TiDB 在微众银行外围批量场景的利用。
转眼间，已在微众工作近七载。这期间，始终负责微众银行数据库平台的建设和经营。微众银行在成立之初，IT 根底建设就没有抉择传统的 IOE 集中式架构路线，转而抉择采纳了基于单元化的分布式架构。在这种大的背景下，微众银行的数据库的架构演进，也是走出了一条不同寻常的路线。
一、2014 ~ 2016，两地三核心时代
在微众银行 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，咱们设计了如下的数据库部署架构：
两地三核心的数据库部署架构
能够看到，TDSQL 的部署架构也遵循了两地三核心的准则，分为同城主数据库 SET，同城备数据库 SET 和异地备数据库 SET。同城主数据库 SET 和同城备数据库 SET 由三个数据正本形成（一主二备），异地备数据库 SET 由两个数据正本形成（一主一备）。
SET 外部基于 TDSQL 的主备强统一数据同步性能，能够实现数据的高牢靠和零失落。
二、2016 ~ 2018，同城多活架构革新
IDC 1.0 时代的架构根本满足了我行的业务倒退需要，但还是存在以下几个问题：
同城双核心之间的数据库同步是准实时的，在极其场景下是有可能呈现数据失落的（同城 RPO 不为 0）
只实现了 DCN 分片单元粒度的多活，还没有实现真正意义上的利用跨同城数据中心多活；
在单个 DCN 或者 IDC 呈现故障时，须要做人工的同城容灾切换，耗时太久（RTO 约二小时）
同城有 6 份数据库正本，资源老本较高。
既然有问题，那就得持续优化架构。所以咱们提出了第二阶段的架构优化指标：
实现利用零碎的同城跨数据中心多活；
数据库同城 RPO = 0，同城 RTO 靠近于 0；
升高数据库正本数，缩小老本。
首先，咱们在同城新增了一个数据中心，由同城的两核心，变为了同城三核心（IDC 2.0），这是实现同城利用多活架构的前提。
IDC 2.0 架构图
基于 IDC 2.0，咱们设计了同城三核心多活计划，应用层和数据库的架构都做了相应的调整。
同城多活架构
数据库层面，由原来的双核心主备 SET 的架构模式，调整为单 SET 三正本跨三核心部署的模式，主节点能够进行读写，备节点只读，能够实现数据库层面的同城跨 IDC 的 RPO = 0，RTO 达到秒级。
以此为前提，应用层就能够实现真正的跨同城数据中心多活。也就是应用层能够在同城的三个数据中心内各部署一套对等的利用零碎，接入业务流量，通过接入层转发，最终到数据库的主节点上（开启读写拆散的状况下，读流量能够转发到备节点上）。
同城利用多活的架构革新，进一步晋升了整体的可用性，简化了容灾架构，同时也将数据库的六正本缩减为三正本，极大的升高了资源老本，能够说很好的实现了架构优化指标。
三、2018 ~ 2020，引入 NewSQL 数据库
随着业务的疾速倒退，DCN 的数量也在疾速减少，DCN 的程度扩大个性很好的撑持了业务的快速增长。但在某些非 DCN 架构的中后盾业务场景中，单实例架构的数据库逐步遇到了容量或者性能上的瓶颈。
一个比拟典型的场景就是平安存证类的数据存储。这个场景属于中后盾业务，须要继续存储交易行为类的数据，以供随时审计或者举证，所以个别是不能删除的。随着业务规模增涨，存证数据也会继续的增涨。
然而对于单实例的数据库来说，是要求不能超过 3 TB 的存储容量的，一个起因是硬件层面的限度（SSD 的单盘容量），另一个起因是单实例过大的容量，会带来数据库性能上的不确定性和运维的复杂性。
依照比拟传统的解决方案，能够抉择基于中间件的分库分表计划来解决这个问题。
然而分库分表事实上是对业务开发和 DBA 都不太敌对的一种计划。对业务开发来说，因为分库分表个别在语法和 SQL 应用层面都会有一些限度和限定，所以个别须要重构代码和 SQL，以适配分库分表环境下的数据库应用；对于 DBA 来说，分库分表的扩展性不是那么灵便，DDL 等日常操作也比拟得简单，使得整体的运维工作量减少。
咱们不想走回分库分表的老路，所以也在探寻有没有更优雅、更先进的解决方案。2018 年下半年开始，NewSQL 的概念逐步衰亡，带来了一种全新的 Share Nothing 的分布式架构的数据库（基本上是以 Google Spanner 分布式架构为原型）。
通过充沛的调研和评估，咱们最终选取国产开源的 NewSQL 数据库产品 TiDB 进行尝试。TiDB 次要有以下几个个性吸引了咱们：
TiDB 采纳了规范的 Share Nothing 架构，计算与存储拆散，并且都能够做到程度扩大，且对业务层通明。
TiDB 采纳 MySQL 协定体系，与咱们以后的协定体系兼容度高，升高业务的开发和迁徙老本以及接入门槛。
TiDB 采纳开源的模式进行经营，社区较为沉闷，版本迭代较快，并且已有一部分的互联网用户开始应用。
TiDB 整体架构
能够说，TiDB 的个性能够很好的解决咱们的需要和瓶颈，但过后 TiDB 还是属于一个十分新兴的数据库产品，稳定性和成熟性不够，所以咱们也是十分审慎的进行充沛的测试和验证，在生产上首先选取的比拟边缘的业务场景进行灰度，并且准实时同步一份数据到 TDSQL 进行兜底。
TiDB 在微众的部署架构也相似于 TDSQL，利用同城三机房的硬件劣势，采纳同城三正本跨三核心部署，能够无效的反对利用同城多活架构。
TiDB 部署架构
通过近两年多的经营，咱们已将 TiDB 利用在平安、智能监控、数据归档、反欺诈、反洗钱、历史交易明细查问等各类中后盾业务中。随着 TiDB 的版本逐步成熟，整体的稳定性和可运维性也晋升了不少。
回头来看，尽管咱们冒着吃螃蟹的危险，采纳了 NewSQL 的计划而放弃了分库分表的计划，但带来的收益也是微小的。
目前，TDSQL 持续作为外围数据库，承载 DCN 架构下的外围零碎；TiDB 作为补充，承载非 DCN 架构下的、对容量和扩展性要求较高的中后盾零碎。TiDB 作为微众整个单化元架构的补充，很好的补齐了数据库层面的短板。
四、2020 ~ 2021，NewSQL 在外围批量场景的利用
通过两年多对 TiDB 数据库的应用，踩了不少坑，也积攒了不少教训。TiDB 自身随着版本迭代也更加成熟稳固，逐步造成企业级的数据库产品。
2020 年初，咱们收到了贷款科技部门针对贷款外围的日终批量零碎的优化需要。
过后，贷款外围零碎的日终批量零碎是部署在业务 DCN 外部的，和联机系统复用 DCN 内的 TDSQL 数据库资源。随着交易数据的与日俱增，贷款外围零碎的批量面临着以下几个问题：
批量的耗时继续增涨（优化前已近三小时），如果因为某种原因批量须要重跑，有比拟大的超时危险。
批量零碎和联机系统都在 DCN 内部署，批量零碎带来的数据库高负载，会对联机系统产生影响。
受限于 MySQL 的主备复制的原理限度以及单实例的性能瓶颈，无奈持续通过进步应用层并发来晋升批量效率。
批量效率逐步成为单个 DCN 的用户容量瓶颈，而非理论的用户量。
贷款外围批量架构（优化前）
基于以上问题，业务部门也提出了优化指标：
将整个批量零碎重构（包含应用层和数据库层），外围业务微粒贷的整体批量耗时缩短到半小时内以（在限定的资源内）。
将批量零碎的资源和联机系统齐全解耦（包含应用层和数据库层）
批量零碎的数据库须要具备可程度伸缩的个性。
最后看到这个优化指标，感觉还有挑战的。特地是每天数亿条帐务的批量计算解决，须要优化到半小时以内实现，应该没有那么容量。
通过评估，咱们最终决定尝试用 NewSQL 数据库 TiDB 来承载贷款外围的批量零碎（优化后的架构如下图）。批量数据每天通过 DCN 内的 TDSQL 近实时的同步到 TiDB 集群进行汇总，而后由批量应用程序在 TiDB 集群进行批量计算和加工。通过近一年的继续优化、调整和灰度验证，最终我的项目顺利上线，并且齐全达到了既定的优化指标。
贷款外围批量架构（优化后）
下表是微众 5 个次要贷款业务的外围批量优化前后的耗时比照，优化成果非常明显。
在整个我的项目的施行的过程中，踩坑不少，也总结了不少的优化教训和教训，次要有以下几点：
- 利用 SQL 模型的整体重构和优化
针对批量利用的 SQL，进行 SQL batch 化的革新，晋升单个 SQL 的效率；
对于频繁拜访的热点静态数据进行缓存，缩小 SQL 的申请次数；
对简单 SQL 进行内存占用优化、执行打算优化等，升高 SQL 的耗时。
- 基于 TiDB 的热点数据打散机制优化
在 Share Nothing 架构的数据库中，数据热点是常常会遇到的一个问题，如果分片规定或者利用的写入的规定不合理，很容易就造成针对某一个数据库分片的热点，导致数据库响应变慢，甚至假死。
贷款外围的批量数据表，都是数亿级别的数据量导入，热点问题更加显著。针对这种超大表的数据导入，咱们联结数据库厂商，开发了数据表预打散的性能，完全避免了热点问题。
- TDSQL 到 TiDB 数据同步的一致性校验机制优化
贷款外围批量的数据正确性至关重要。在优化后的架构，批量数据表须要从多个 TDSQL 源近实时的汇总同步到一个 TiDB 集群中，并进行合表处理。为了保证数据同步的可靠性和准确性，咱们在三个层面做了优化：
对数据同步工具做了高可用架构优化，确保没有单点问题，并且在某个同步节点故障后，能够主动进行替换和复原；
对数据同步减少全方位的监控，包含同步状态、同步提早、数据源存活状态、指标端存活状态等；
在应用层减少数据分片同步的实时校验。针对每一个数据分片，应用层都会计算一个 CRC 校验值，并由上游的 TDSQL 同步到上游的 TiDB，待此分片数据同步完后，在上游再进行一次 CRC 计算，并和上游同步过去的 CRC 值进行比对；除了分片校验，还会有数据行数的最终一致性测验。
- 故障 SOP 预案和兜底机制的建设和演练
针对日常的服务器故障，或者数据库 bug，导致的批量中断，筹备了批量断点续跑的预案，并在生产环境定期演练；
针对可能的数据错乱导致批量须要重跑的场景，通过批前的 rename 备份表的形式，能够实现疾速的批量重跑。
针对极其的劫难场景下，须要重建数据库进行批量重跑的场景，通过批前的冷备数据，进行疾速的数据库重建和导入，从而实现批量重跑。
TiDB 数据库在贷款外围批量零碎的利用，是对微众整个单元化架构的又一次补充和欠缺。咱们常常说，数据库没有银弹，没有一种数据库可能实用所有的业务场景。针对每个场景，用最适宜的数据库产品和数据库架构，才是价值的最大化。
除了关系数据库产品，咱们也大量应用了 Redis 来适宜大部分须要高并发、低提早响应的读场景。在尽量保障架构一致性的前提下，咱们依据业务的理论需要，也大量引入了 Monggo DB、PostgreSQL、Oracle 等数据库产品。
将来，咱们也将在数据库的云原生、数据库的智能运维、数据库的硬件国产化、HTAP 场景的利用实际等方向持续摸索，一直晋升和欠缺咱们的架构，为国产数据库在金融场景的利用实际奉献本人的一份力量。
本文内容来自微众银行根底科技产品部公众号 TCTP《微众银行数据库架构编年史》一文，作者胡盼盼，微众银行数据库负责人。
