共计 3957 个字符，预计需要花费 10 分钟才能阅读完成。
TiDB 作为一款高效稳固的开源分布式数据库，在国内外的银行、证券、保险、在线领取和金融科技行业失去了广泛利用，并在约 20 多种不同的金融业务场景中撑持着用户的要害计算。本篇文章将为大家介绍分布式关系型数据库 TiDB 在金融行业要害应用领域的实际。
金融要害业务场景
银行的业务零碎非常复杂，包含从外围上的账户、账务、结算等业务到外围的各种存、贷、票、汇以及面向互联网场景的各类金融业务。
随着科技的倒退，整个银行的外围交易系统走在本人的一个演进路线上，从传统的集中式利用构造逐渐向服务化、分布式这样的体系在演进。在国内，曾经有若干家在科技方面比拟当先的银行机构启动了对于外围的革新工作，在他们整个外围交易利用以及背地的数据处理层引入了十分多分布式的技术来撑持他们业务的倒退。在将来，整个倒退方向会更多的向单元化、服务化倒退，并且一些利用撑持的框架，例如云、微服务、将来的 serverless 等，都会逐步的向外围交易引入。
分布式外围零碎架构对整个数据库有以下几点比拟明确的要求：
- 平安，稳固，牢靠；
- 提供分布式计算与分布式数据管理及在线弹性扩大能力；
- 提供高并发，低提早，大吞吐的数据库解决能力；
- 反对联机交易及批量(日间 / 终) 批量混合负载；
- 反对外围上的报表和数据报送业务负载；
- 提供牢靠和高性能的分布式联机交易事务；
- 须要反对至多达到“两地三核心”的双核心多活及多核心容灾保障能力；
- RPO = 0, RTO 要达到监管及银行科技部门对外围零碎的高可用要求；
- 外围业务利用开发 / 革新难度低；
- 欠缺与便捷的运维治理能力。
现有架构痛点
目前，很多银行采纳的外围零碎数据库计划次要为传统的集中式数据库架构和基于 MySQL 的分库分表计划，但无论是集中式数据库架构，还是基于 MySQL 的分布式数据库架构，都会存在一些问题。集中式数据库架构次要有以下几点问题：
- 重大依赖专有高端硬件；
- 无奈弹性横向扩大；
- 与新一代分布式服务化外围利用架构匹配度低；
- 建设及保护老本昂扬；
- DB2 / Oracle 数据库技术锁定；
- 无奈利用云计算体系倒退成绩。
基于 MySQL 的分布式数据库架构也存在以下几点问题：
- 数据库分布式中间件成熟度与可靠性仍须要考验；
- 利用侵入水平高，革新复杂度大；
- 利用模型和数据模型的锁定，就义灵活性；
- 批量负载解决能力限度；
- 分布式事务能力低下，须要人为利用开发侧和布局侧深度躲避；
- 强一致性保障的危险；
- 不足弹性扩大能力和在线扩大主动均衡的能力；
- MySQL 高可用技术的危险；
- 两地三核心同城多活复杂度。
基于 TiDB HTAP 架构的银行外围数据库解决方案
计划一：TiDB 外围交易系统撑持架构
第一个是比拟含糊其辞的计划，以 TiDB 作为外围交易库的主库。
在这种形式下，整个 TiDB 近似传统单机集中式数据库的拜访模式与业务利用开发模式，对利用的拜访是通明的。同时，无论是利用模型、数据模型还是整个事务交易模型，不须要做人为的切分。因为在外围交易利用的倒退过程中，除了以账户为角度，咱们还会以用户视图为角度，因而简略的通过找到用户的账户分片去做切分的话，实际上是就义了整个外围交易的灵活性。
另外以 TiDB 作为主库，内置的多核心、多活容灾的机制也简化了部署的复杂性、治理复杂性和老本；并且齐全的分布式联机交易事务反对，不须要利用干涉和提前锁定事务处理布局，用户基本上在 TiDB 上做联机交易的过程当中，跟单机数据库的应用是一样的；另外 TiDB 在后盾提供了一个动静的调度机制，所以在线的进行节点的扩容，齐全不会影响业务，无论是后盾数据均衡，还是外部引擎之间的负载平衡的主动调配，都是在引擎外部本人做的，不须要用户在利用侧有特地多的关注。
以 TiDB 作为外围交易库的主库，次要有以下几点价值：
- 在外围零碎数据库侧分布式革新大幅度降低革新难度与危险；
- 业务模型和数据模型无需反向适配数据库架构；
- 通明的计算和数据管理分布式，升高保护复杂度与老本；
- 吞吐量及性能能够随在线横向通明扩大；
- 规范 SQL, 分布式事务，多表简单关联计算，联机与批量混合负载解决能力，保障业务灵活性及适配分布式外围利用；
- 内核反对强统一数据局部机制及高可用机制 (RPO=0,RTO <30s）；
- 内核反对多核心多活容灾机制。
长亮外围交易系统测试
咱们与城商行一级的零碎做了比拟残缺的对接，包含长亮科技，咱们在他的外围交易系统上，包含账户、账务、贷款、发卡、现金管理、资产负载等这些外围模块做了充沛的适配。
从性能、正确性、交易的性能等方面做了充沛的适配和优化，实现了 2000 多个外围交易的功能测试，包含全量的近 200 个批处理测试。接下来，咱们正在跟长亮科技打算进行 V8 版本对接测试和基于 ARM 国产化平台的测试。
计划二：外围交易 MySQL + TiDB 后置库计划
第二种计划是以 TiDB 作为整个外围交易的后置库计划。
架构如上图所示，整个外围交易的利用侧依据应用逻辑做一个拆分，这也是当初新一代外围利用构造的演进趋势。
用户在外围联机交易库应用 MySQL + 中间件的形式来承当联机交易的前置库，在这下面实现最根本的联机交易，而后通过 TiDB 提供的 CDC 同步工具做准实时的同步，解析 MySQL 分片对的 binlog，并通过主动合库的形式汇聚到 TiDB 的分布式集群下面。
在 TiDB 分布式集群上能够克服原来由繁多的 MySQL Sharding 计划带来的一些限度，比方后面提到的简单计算、简单的实时查问业务，这些业务负载就能够从联机交易主库下线到 TiDB 后置库上进行实现。这样能够说是取长补短，在整个计划当中可能将整个交易的联机局部、批量局部、实时查问局部和简单的报表局部做一个辨别。
计划三：外围交易 MySQL(业务单元化) + TiDB 后置库计划
第三种计划和第二种计划相似，但随着外围交易技术以及架构路线的倒退，有不少的解决方案会在外围交易的利用侧进行利用维度的微服务化或者单元化的革新。
在整个外围交易当中，把交易链路上都会用到的客户核心、产品核心、核算核心与整个交易拆散，将这部分独自拎进去；对于联机交易和账户这部分，例如贷款零碎与贷款零碎，通过业务逻辑上的切分，把他们切分成独立的单元，能够了解为虚构的分行零碎，通过这种形式在利用的业务层实现横向的扩大；同时在整个交易链路上，例如公共服务中心，能够通过微服务形式抽取进去，在不同模块之间通过标准接口来作为调用的公共服务区。
这样的构造产生后，肯定会产生多个数据库对应联机交易库。作为业务单元化架构下外围交易联机库背地的后置库，TiDB 同样能够通过 CDC，将诸如客户核心、产品核心、核算核心等对立全局维度的库进行一比一的入库。同时，对于在应用层曾经不是依附 MySQL 分库分表，而是靠应用层切割的垂直分库，可能通过 CDC 工具间接在 TiDB 层汇聚成一个全局的汇总库，在这个汇总库上咱们能够实现跨服务单元数据后盾的批量操作，包含简单查问以及报表类的业务；同时，又能够保障在整个业务当中，原来共享服务的库仍旧是以逻辑独自库的状态在 TiDB 的大集群当中存在，对业务提供服务。
微众银行新一代外围零碎架构
微众银行就采纳了这种计划作为外围零碎架构。微众银行在国内的外围交易业务单元化方面有本人的翻新之处，在过来三四年的倒退过程中，他们整体的外围交易采纳了 DCN 的分布式可扩大框架，在应用层实现了扩展性，同时在数据库层的数据处理界面上又保障了十分好的简洁性。
DCN 是一个逻辑区域概念，能够等效认为是一个独立的分支机构，例如一个银行的分行或者网点，通过 DCN 的横向扩大来解决业务的扩张问题。他们同样也采纳了以 MySQL 分库分表为后盾的联机库，并将交易和核算拆散，通过分布式数据库 NewSQL 的技术，将批量和核算通过后置库的形式移到分布式集群当中。
TiDB 作为外围交易后置库的价值
TiDB 作为外围交易后置库的价值次要有以下几点：
- 解决 MySQL 分布式计划中数据汇总计算解决的挑战。
- 规范 SQL，分布式事务，多表简单关联计算能力提供了跨节点海量数据的高性能批量解决能力。
- HTAP 架构提供行列混合计算能力，海量数据的高性能实时计算。
- 提供残缺工具，实现全量同步联机库集群数据，随时成为联机库集群的备选切换保障。
- 吞吐量及性能能够随在线横向通明扩大。
- 内核反对强统一数据局部机制及高可用机制 (RPO=0,RTO <30s）。
- 内核反对多核心多活容灾机制。
TiDB 对外围交易场景的潜在价值
TiDB 为外围交易场景也带来了一些潜在价值。
首先咱们深信云肯定是将来，TiDB 云原生架构及产品能力 (K8s 容器集群) 就绪，为上云 (公有云) 提供了技术根底。同时，咱们在最近曾经实现了对商业云根底平台 (开源 OpenShift、开源 Rancher）的对接适配，加上 TiDB 基于云资源调度和数据库自身的调度机制，可能比拟好的实现云中数据库多租户的反对能力。
在内核上，TiDB HTAP 行列混合架构可能撑持将来更多的在线新业务场景，拓宽业务实用面；同时，咱们的产品团队也在跟包含 Flink 的团队单干，实现了包含流解决的计划适配，为实时处理类业务提供能源。
另外，咱们也初步实现了跨数据中心的调度能力，实现多核心间数据感知调度。在多核心的架构下，通过 TiDB 的散布式调度机制与行级数据调度能力，将数据与核心站点进行动静关联，以地理位置为根据关联数据表(行汇合)，缩小跨地区拜访，升高查问提早，进步利用的整体性能。同时，利用这样的外围伎俩，咱们能够对冷热数据进行比拟灵便的调度，对冷热数据进行拆散。
解决方案的劣势剖析
对于外围联机交易，从传统计划到 MySQL 的分布式计划，再到以 TiDB 为主库的计划或者是作为后置库的计划，TiDB 无论从交易的性能、吞吐、汇总、扩大各方面都有比较显著的劣势。并且，相比传统的构造，引入 TiDB 当前在整体硬件、软件，包含整个运维部署的老本方面都有显著的劣势。
未完待续 ……
