共计 3525 个字符，预计需要花费 9 分钟才能阅读完成。
作者介绍：陈振东，北京银行软件开发部
北京银行是一家城市商业银行，公司价值位列中国区域性倒退银行的首位，依靠于中国经济的大环境，北京银行的资产总量在寰球千家大银行中名列第 61 位，间断六年跻身寰球银行业百强。北京银行踊跃开拓多元化的业务经营，例如北京地区的社保缴纳和医保代发，都是由北京银行在提供服务，在你入职一家公司的时候，收到的医保折子就是来自北京银行。
业务转型驱动分布式架构建设
因为疾速的业务倒退需要，北京银行在业务转型中对系统架构进行了降级，逐步向分布式架构进行转移。早在 2016 年，北京银行就开始了对分布式数据库的摸索，并于 2018 年正式投产上线了 TiDB 分布式数据库，过后在业内还没有一个比较完善与成熟的体系，咱们也是依据银行的平安合规需要建设了两地三核心的部署计划。
如上图所示，在两地三核心部署了 TiDB 分布式数据库集群，采纳主从的多活架构，主集群作为生产集群承当日常的生产服务，从集群是建设在西安的异地灾备核心，主从之间是用 Kafka 同步 Binlog 模式进行数据的同步。
在这两年的建设过程中，北京银行与 PingCAP 进行专项的深度单干，这里简略介绍三个方面：
- 两地三核心 ：在两地三核心的部署计划中，异地核心的网络延时会对整个集群的性能产生较大影响，咱们在这层面上对 gRPC 的音讯格局进行了压缩，同时利用 Multi-Raft 个性将主节点都固定到北京 IDC 的节点。
- 增量备份 ：有一些系统对增量备份有需要，特地是审计、监管这类数据的导入和导出，北京银行和 PingCAP 独特开展增量备份和指定工夫数据恢复的计划钻研，将 Binlog 保留到本地，以 ProtoBuf 的模式存下来，再利用 Reparo 相干工具可能复原到指定的工夫节点。
- 事务 ：金融行业大家都比较关心数据库事务，例如大事务处理、RC 级别、乐观锁的利用等，北京银行在这些需要层面也与 PingCAP 进行了专项的单干，当然在 TiDB 4.0 版本外面曾经包含了这些性能个性。
TiDB 在金融交易场景中的利用实际
网联领取清理平台 & 银联无卡快捷领取零碎
在构建数据库之后，咱们来看看 TiDB 在北京银行交易场景中的利用工夫。首先给大家介绍的是网联领取清理平台和银联无卡快捷领取的场景，这两个是最早应用 TiDB 数据库的业务零碎。
依据过后中国人民银行“断直连”的要求，所有银行的三方领取交易都要进行集中的汇总。在此之前，银行对这种三方领取的建设计划会采纳一些通用平台去承载这些专用业务，比方支付宝有业余的支付宝零碎、微信领取、京东领取等等都有各自专用的领取零碎。在有了“断直连”汇聚三方领取的要求之后，北京银行对业务和零碎进行了整合，以便更好地迎接互联网金融带来的大数据量和高并发的挑战。
在这两个零碎投产之后，曾经胜利应答了两次双十一挑战，上图列出了 2019 年双十一巅峰的 QPS 达到了 7500，是平时 QPS 的十倍以上。IT 团队进行屡次线上的运维操作，包含版本升级、打补丁等，很好地利用了 TiDB 分布式数据库的多正本个性实现“运维零中断”的操作。随着北京银行零碎的降级，在网联这条业务链上，包含上游的手机银行到网联、银联无卡快捷领取这样的业务中台，再到后盾的金融日历、查问服务都曾经进行了分布式架构的降级，实现了与 TiDB 的对接。 在这里，手机银行指的是手机银行 App 的后盾治理端，并不是说您下载一个北京银行手机 App 就能取得一个 TiDB。
网贷业务平台
第二个比拟典型的利用场景就是网贷业务平台，网贷平台不同于网联平台的联机实时高并发的交易，次要进行的是一些批处理的业务，比方像借呗、花呗、度小满这类比拟热门的互联网金融明星产品，其实在银行侧就是一笔笔贷款与一笔笔借据，咱们须要对它们进行无差别的解决。
网贷平台跟下面提到的网联平台还是十分有渊源的，整个网贷平台采纳麻利化的建设形式，包含麻利的项目管理、麻利开发与麻利测试。最开始的时候，项目组是打算通过洽购实体服务器专门搭建一套数据库集群给网贷平台应用，然而因为整个洽购物流的周期太长， 咱们最终决定对网联、银联无卡这套比拟齐备的零碎进行一个 Scale-in 缩容，将缩容进去的五台 TiKV、两台 TiDB 给到网贷平台应用，PD 由网贷和网联两套零碎独特应用，咱们采纳这种形式疾速实现了零碎的构建。
在这个过程中，有几点教训分享给大家：
首先是对批处理构造的优化，起初网贷平台专门解决网贷借据、贷款核算等批处理业务，随着前期的一些生产贷、贷款查问、用户查问这类联机交易上来当前，对 TiDB server 层的批处理性能会产生较大的影响。于是，咱们将方才提到的两台 TiDB 其中的一台专门用于解决这些实时联机交易，另一台 TiDB 专门进行批处理。
另外一点，网贷平台在解决完本人的会计分录之后，由传统的外围总账零碎进行核算与账务解决。外零碎也是在这种交互过程中，因为 TiDB 的 SI 隔离级别，MVCC 多版本 有它的回收机制，之前开发测试中没有思考到这一点，前期在性能测试中发现了有 GC 超时的景象，咱们通过对事务的正当编排解决了这个问题。
在业务评估层面，当银行的业务人员说有一个 300 万的贷款合同、贷款借据，其实到网贷平台通过流水表、当日表与历史表这样一系列解决之后，就成了一个 3000 万行须要解决的数据，网贷平台须要去跑批处理的数据也就是这 3000 万，不再是业务人员的 300 万。再从 TiDB 数据库层面去看，加上了正本、索引等等之后，这样的数据量其实曾经远远大于最开始业务预期的评估，这就是一个金融场景大数据产生的过程。
而后跟大家分享一下 TiDB 的批处理效率，方才提到的 3000 万跑批是在一个小时左右实现的，前期随着版本的降级和系统优化，还有很大的晋升空间。
利用推广
除了下面两个比拟典型的交易系统之外， 北京银行也在减值计提筹备零碎、金融服务互联平台、金融渠道开放平台、城商行零碎等场景都用到了 TiDB，涵盖了包含领取、账务核算、金融渠道等方面所有的金融场景。
分布式数据库建设过程感触总结
简略总结一下分布式数据库建设过程中的一些感触。
- 业务转型 ：大家都提到在金融互联网的上半场，银行是一个完败的终局，其实互联网金融这个场景给了大家一个偏心的竞技场，只有以客户为核心，能力生存下来。方才提到的网联场景，用户就是喜爱零点抢购，咱们就要有应答策略，咱们须要搭建更灵便、更大容量的零碎去承载这些流量。
- 动静保护 ：随着架构的转型，分布式架构在灵便部署等方面逐步体现出劣势。咱们须要更智慧、更优雅地去解决可能带来的服务中断的状况。银行对业务连续性保障要求十分高，咱们当初能够充分利用分布式数据库的架构劣势，真正实现零停机的集群动静节点调整。
- 行内生态 ：随着 TiDB 散布式微服务架构的全面推广，北京银行外部也是以点带面，有越来越多的项目组参加进来，学会从分布式的架构登程，思考在这种架构和技术栈下，应该如何去进行业务层的布局和设计。
金融场景业务与分布式数据库的今天
接下来谈谈咱们对将来的瞻望，有点像昨天、明天和今天。
总体目标
在将来，北京银行的分布式数据库团队，次要是着手两方面的工作：
一方面是拓宽畛域 。首先从方才提到的这些业余零碎的领域登程，持续下沉去摸索分布式数据库在银行的账务类、客户信息类的外围业务场景中的利用。并从数据库技术角度登程，将分区表、乐观锁，甚至 HTAP 这种个性与银行零碎进行联合，一直推动分布式数据库在金融畛域的落地。并且随着往年北京银行顺义研发核心的投产应用，咱们也面临同城双核心计划制订的挑战。
另一个大方面就是协力共进 。这里的力，包含协内力和协外力两个方面。协内力方面方才我曾经提到，随着行内越来越多的项目组开始应用 TiDB，去进行微服务的转移，咱们的零碎开发人员须要拓宽思路，在分布式的架构下，应该怎么去设计和开发代码。随着 TiDB 分布式数据库的引入，对咱们的架构治理与运维治理都带来一些挑战，须要总结后期的教训，把已经掉过的坑进行演绎，化繁为简，造成一套比拟成熟的银行业的建设方法论。协外力方面，北京银行在分布式数据库建设的过程中，参加了金融业内的规范制订与交换，在将来咱们会持续放弃这样的姿势，为行业建设奉献一份力量。
分布式金融业务平台布局
最初，跟大家分享北京银行分布式金融业务平台的布局。
首先是分布式外围的下移的工作，包含下面提到的帐务核算、客户治理等一系列业务利用的迁徙工作。
另一个层面，钻研 HTAP 混合业务场景的试点利用，这也是 TiDB 4.0 外面比拟有亮点的性能。TiDB 4.0 公布之后，咱们在行内曾经开始对 TiFlash 进行初步的评测，咱们置信 HTAP 混合型的数据库是将来的技术倒退方向，咱们将持续去摸索，找到 HTAP 真正的归属之处。
本文整顿自陈振东在 TiDB DevCon 2020 上的演讲。
