共计 2926 个字符，预计需要花费 8 分钟才能阅读完成。
「咱们曾经用起来了」，是咱们最喜爱听到的话，简简单单几个字的背地代表着沉甸甸的信赖和托付。从明天开始，咱们将通过 「置信凋谢的力量」 系列深度案例分享，从业务的角度，看看一个数据库为各行业用户带来的业务价值。本篇文章将介绍 TiDB 助力微众银行金融外围场景的故事。
科技普惠公众，数据连贯智能
从一次惊喜，到每次陪伴
咱们让美妙产生
微众银行是国内首家停业的民营银行，由腾讯、百业源和立业等多家知名企业发动设立，于 2014 年 12 月取得由深圳银监局颁发的金融许可证，总部位于深圳。停业 5 年多来，微众银行始终保持普惠金融的定位不变，踊跃使用金融科技构建普惠金融新业态、新模式，初步走出了一条商业可继续的普惠金融倒退模式。
截至目前，微众银行服务集体客户已冲破 2.5 亿人；集体经营户超过 2000 万，企业法人客户超过 150 万家，累计发放了超过 3200 亿元的贷款，反对就业人口超过 400 万。这些客户全副为民营企业，散布在 27 个省的 200 余座城市，其中，约三分之二的企业客户和 37% 的集体经营贷款客户属首次取得银行贷款，充分体现了微众银行普惠金融的定位和特色。
客户收益
微众银行成立以来始终以科技作为驱动业务倒退的外围引擎，曾经具备齐全自主可控、反对亿级海量用户和高并发交易的外围零碎，已实现年均日交易超过 3 亿笔、单日交易峰值超过 6 亿笔；每账户运维老本不到行业均匀的十分之一。
从 2018 年开始调研并上线 TiDB 至今，微众银行曾经有数十个业务零碎在 TiDB 上投产，数据量从百 G 到几十 T 不等，目前也有多个重要的零碎正在 POC 或筹备投产阶段。明天这篇文章介绍两个 TiDB 撑持的比拟重要的场景：
- 资产证券化零碎批量场景下的 TiDB 实际。
- 交易数据存证 TiDB 实际。
面临挑战
自成立之初，微众银行就十分有前瞻性的意识到底层基础设施建设对银行倒退的重要性，抉择了建设分布式架构 IT 基础设施的路线。基于便宜通用的硬件设施和各类开源的软件产品，微众建设了基于单元化的松耦合、可扩大的分布式架构。
为了实现业务规模的程度扩大，微众银行设计了基于 DCN 的分布式可扩大外围架构，从而即实现了整体扩展性，也保障了单 DCN 数据库层面架构的简洁性。DCN，即 Data Center Node(数据中心节点)，是一个“自蕴含单位”，包含了残缺的应用层，接入层和数据库，每个 DCN 承载规定数据量的用户。能够艰深的了解为，一个 DCN，即为一个微众银行的线上的虚构分行，这个虚构分行只承载微众银行某个业务的一部分客户。
基于 DCN 能够实现集群规模的程度扩大，这种架构对于数据库来说，是比拟敌对的，每个 DCN 的用户规模是确定的，因而对数据库的容量和性能要求也是可确定的。不用再采纳简单的中间件分库分表的形式构建数据库，而只用单实例模式承载，极大简化了数据库架构，也升高了业务开发成本。
但同时也遇到一些瓶颈。因为一个 DCN 外部采纳的是单实例的部署模式，对于有些无奈通过 DCN 拆分进行扩大的业务场景，或者须要进行数据汇总类的业务场景，单实例的性能和容量就很容易达到瓶颈。
为何抉择 TiDB
为了解决下面提到的瓶颈，通过具体的调研和评测，比对了国内外多款 NewSQL 数据库产品，最终确定以国产开源 NewSQL 数据库产品 TiDB 作为切入点。2018 年，TiDB 作为一款新兴的开源 NewSQL 数据库产品，吸引了微众银行，并最终抉择：
架构理念先进
TiDB 的架构理念较为先进，原生分布式的架构可能很好解决程度扩大同时保持数据强统一的问题，同时兼容 MySQL 协定并能无缝的作为从库对上游 MySQL 进行实时同步，也让业务的迁徙老本降到最低；
开源的经营形式
TiDB 以开源形式经营，并且建设了十分沉闷的开源社区以及泛滥的用户。开源的经营模式，版本迭代疾速无效，与微众拥抱开源的理念相符合。尔后，在开源社区经营畛域也和微众有着较好的单干，为微众提供了不少开源社区的经营教训。
业余的售后服务
TiDB 的业余售后反对团队 PTC（PingCAP Tech Center）的优质服务，在数据库畛域和开源社区畛域都有着深厚的技术根底和教训积攒。针对客户的技术支持也十分疾速到位。对于任何一个重要业务的接入，从评估、测试到灰度上线，都会积极参与，并给出建设的计划和意见。
微众银行 TiDB 业务实际
资产证券化零碎批量场景下的 TiDB 实际
资产证券化零碎，目前每天要从上游零碎同步数千万级别的根底数据来反对业务开展，并且预计后续将接入更多的产品数据，这样不仅面临时效性要求的压力，DB 容量也将会成为瓶颈；此外因为零碎依赖上游零碎的表构造，常常须要追随上游零碎做 DDL 变更，PT-OSC 计划限度较多。
存在的问题：
- 单机 MySQL 数据库不反对容量程度扩大，随着业务的规模增大，DB 容量瓶颈问题将会日益凸显；
- 单机 MySQL 数据库不反对性能程度扩大，无奈通过扩容资源来线性晋升批量效率；
- 单机 MySQL 数据库对根底数据全表清库、数据高并发插入等场景，因为并发线程过高易引起主备提早等问题做了限流，这将会升高批量的整体时效；
- 单机 MySQL 数据库的在线 DDL 个性存在锁表，易引起主备提早、IO 突增等问题 而 PT-OSC 计划同样限度较多；
无疑 TiDB 是能够比拟不便地解决这些问题，并且将来随着 TiFlash 上线后，还可进一步的使用在离线报表统计逻辑上，缩减解决时长。
“借助 TiDB 的程度扩展性，整个批量耗时升高了 58% 左右。”微众银行数据平台室经理胡盼盼示意，将来微众银行将会联合本身的业务需要，以及 TiDB 的新个性，摸索更多的业务场景。
数据存证零碎 TiDB 迁徙实际
数据存证零碎是微众银行十分重要的零碎，存储了具备法律效力的证据类数据，这些数据对客户来说是十分重要的。
随着越来越多的业务零碎的接入，该场景的数据增长速度十分快，比方每一次转账都须要生成一个证据，并且不是简略的一条记录，而是产生纠纷时法院认可的证据，所以也决定了这些数据不能删除，这意味着这些海量的数据肯定须要一个分布式数据库计划承载。另外因为这些业务数据属于无奈依照 DCN 拆分的全局数据，没方法很好的横向扩大，于是在数据库层面遇到了很大的瓶颈。
如上图所示，基于这些场景特点，微众同样抉择了 TiDB 的解决方案。有几个根本的迁徙准则：
- 数据不能错、不能丢；
- 服务敏感度十分高，须要尽量无缝切换到 TiDB 架构上；
- 因为是比拟庄重的金融场景，如果在迁徙过程中有任何艰难，冀望可能随时回切到 MySQL。
迁徙整体计划步骤流程比拟长，但会更加平安。通过一系列迁徙操作与察看后，各方面的性能指标都十分稳固，因而微众银行决定将反向同步 MySQL 断掉，也就意味着数据存证零碎这样一个十分重要的零碎，齐全跑在了 TiDB 上。
“回顾整个迁徙过程，也是比拟晦涩且顺利的。”微众银行数据平台室经理胡盼盼示意。
与客户同行，置信凋谢的力量
每次数据库架构改善与落地，无论是 TB 级还是 PB 级，都须要付出致力，但这也值得每一个企业去做。在当下这个时代，不论企业的规模如何，都要学会借助开源的力量，防止去反复的造轮子。
每一个看似轻松的背地都有鲜为人知的致力，每一个看似光鲜亮丽的背地，都有鲜为人知的付出。分布式数据库建设之路道阻且长，TiDB 愿与微众银行及每个客户一起，携手并肩把事件做好。
