共计 3277 个字符，预计需要花费 9 分钟才能阅读完成。
TiDB 作为一款高效稳固的开源分布式数据库，在国内外的银行、证券、保险、在线领取和金融科技行业失去了广泛利用，并在约 20 多种不同的金融业务场景中撑持着用户的要害计算。在 TiDB 在金融行业要害业务场景的实际（上篇）中，咱们介绍了 TiDB 在银行外围交易场景的利用，本篇文章将次要分享 TiDB 在外围外围的要害业务场景的实际。
TiDB 在领取业务中的实际
咱们在外围外围的要害业务场景也有很多的案例，例如当初比拟典型的在线领取业务。TiDB 次要涉足的领取畛域包含商业银行的网联 / 银联领取业务的联机交易数据库，第三方领取公司的挪动支业务外围领取零碎。通过 TiDB 提供的大规模吞吐，高性能大并发联机交易，多核心多活容灾，弹性扩大机制来撑持：
- 商业银行侧，来自网联 / 银联无卡的大并发领取交易指令和领取报文数据处理；
- 第三方领取侧，来自挪动领取 App，商户挪动 POS，领取场景嵌入式的领取业务零碎后盾的交易指令和领取报文解决；
- 领取交易的联机处理类，次要为领取钱包数据的解决，领取交易数据联机插入与更新，交易状态实时查问，交易历史记录和账单查问；
- 领取交易中的费率等计算；
- 领取过程中的反洗钱零碎的数据汇聚及规定计算。
自 2018 年投产以来，三年的工夫里 TiDB 稳固的反对了北京银行的网联领取和银联无卡领取的外围零碎，采纳了北京同城 + 西安两地三核心的多活容灾构造，顺利的度过了两次双十一，比拟好的撑持这个业务。另外，咱们在包含天翼领取的领取结算、账单、反洗钱平台，宝付的领取数据汇聚和日本排名第一的领取公司 PayPay 的联机领取外围及领取钱包外围平台，都有了具体的落地案例。
TiDB 在互联网理财业务中的实际
TiDB 次要落地股份制商业银行财产治理业务条线中的在线理财业务，通过 TiDB 提供的大规模吞吐、高性能大并发联机交易、多核心多活容灾以及弹性扩大机制来撑持理财业务中的：
- 理财交易的联机事务交易外围解决；
- 理财交易系统的日间及日终的数据批量计算；
- 理财交易系统数据的批量计算输入到监管报送，数仓等上游业务零碎；
- 两核心多活容灾部署，提供高等级业务连续性保障。
往年上半年，咱们和光大银行实现了理财交易外围库和联机批库交易的投产工作，比拟好的撑持了整个光大银行理财业务的外围联机交易的解决以及日间和日终的数据批量计算。此外，咱们也在北京银行的理财销售平台和微众银行企业同业的理财交易流水有了相干的场景落地。
TiDB 在实时风控业务中的实际
咱们还有一大类要害的金融利用场景是实时风控业务。跟传统的风控不一样，随着互联网化的业务场景增多，银行和泛金融机构对于实时风控的要求是十分高的。TiDB 目前在风控业务中的实时风控数据汇聚、存储、治理、加工、计算场景方面曾经有多个落地实际。通过 TiDB 分布式存储外围机制，应答海量数据的实时写入，同时分布式计算层以及行列混合引擎的设计可能针对风控指标的点查计算和批量汇总统计计算提供实时处理能力，将传统基于大数据伎俩的“T+1”风控业务解决能力间接晋升到“T+0”级别，如高达秒级的风控数据计算查问。
在金融业务场景方面，咱们有包含北京银行线上业务风控模型治理平台、微众银行 CNC 反欺诈零碎、天翼领取反洗钱平台、拉卡拉金融实时风控平台等一系列的场景落地。同时在互联网及电商业务场景中，包含像东南亚出名电商 Shopee 的风控平台，小红书反欺诈零碎及实时风控平台、拼多多风控平台等都有了一些落地。
TiDB 保险行业典型场景
除了银行业务之外，TiDB 也广泛应用在保险行业。在保险行业，次要在前台、中台、后盾三大畛域有投产业务。
在前台，次要是偏差于互联网和挪动端联机交易这一侧，包含保单的投保、财产增值、会员流动等一些在线联机交易的撑持。咱们在去年胜利的反对了安全产险暖宝保的业务，在很短的工夫内实现了整个集群的投产上线以及安全财神节的一个顶峰交易。
在中台，业务次要波及到以中台业务群为前端的后盾的数据撑持，包含像中台的微服务化、单元模块革新和业务的革新工作，TiDB 可能通过云原生的架构比拟好的适配微服务的应用环境，打消利用对分布式数据存取框架的依赖，无需引入数据中间件，并且可能做到在线弹性扩大。咱们在安全人寿的“金管家”业务和安全产险的“询价出单”业务中都有相干的落地。
在后盾，因为 TiDB 自身超大规模的海量数据存储架构以及具备批量数据的解决能力，咱们在认证、领取、结算、包含后面提到的风控类业务，都有若干的案例落地。在这类业务中，比拟偏差于实时的 OLAP 剖析，波及到 TiDB 提供多种上游数据源汇聚计划。
如何从原有架构迁徙到 TiDB
从金融行业，传统的业务迁徙到 TiDB，有几点想跟大家分享一下。
TiDB 的整体架构是多核心的构造，尤其是对于外围交易和要害业务场景来说，这个是刚需。咱们也是在包含北京银行、光大银行的两个外围交易库下面实现了多核心的架构。
TiDB 外围交易系统迁徙投产布局治理
因为波及到整个金融机构里十分重要并且要害的零碎，外围交易系统 TiDB 投产的技术准则是处处有核验，步步可回退。有以下几种投产策略能够供大家参考。
第一种策略是双写策略。通过在利用侧实现一个双写路由，来对传统组库、交易组库和对 TiDB 作为一个集群的镜像库做双路的转发。它的长处就是管制颗粒十分精密，TiDB 无论从工夫维度还是交易的负载维度上，都失去了全副的交易负载和特色，割接窗口短投入。但须要结构双写路由机制以及数据校验的机制，当然咱们也有一些工具和技术手段能够提供。
第二种策略就是作为主从级别形式来进行投产和迁徙。交易组库，例如 Oracle，持续承当所有交易组库的读写流量。TiDB 通过 Golden Gate 等业余的第三方工具，能够十分不便的去捕捉到 Oracle 整个数据全量和增量的实时变动。这个策略的长处是投产周期十分短，整个业务的革新工作量非常低。但也须要做一些额定的工作，首先是须要做更加粗疏的数据校验，因为是通过主从的构造来取得数据的一些变动；另外，当主从校验中，如果发现有数据问题，那在割接前须要通过技术手段进行修改。当然，咱们有一些相干校验和修整的技术手段，可能在割接、交付、投产之前帮忙用户去做校验和修整的机制。
第三种策略是间接把 TiDB 作为主库，把传统的库作为托底计划。这个计划是借助于咱们与国内次要的数据库头部计划厂商迪思杰 (DSG) 在产品下面的一个残缺适配。当初 TiDB 可能基于 DSG 把 Oracle 零碎作为托底的一个集群。这个策略的长处是投产迅速，有托底保障，但也须要结构数据校验及修改伎俩，整体回退工夫较长。
最初一个策略是做一个灰度，通过交易模块的切分，依照模块的边界来把一部分的交易承当在主库上，另一部分的交易放在 TiDB 上。这个策略的益处是灰度依照业务模块迁徙，对整个业务的整体的危险有比拟好的把控，但可能须要须要更加简单的利用模块级细分迁徙计划和配套工具。
数据备份复原保障
去年咱们实现了对于存储引擎层的物理层的分布式备份的计划，叫做 BR(Backup & Restore)。BR 可能实现在数量固定的状况下，节点越多，备份速度越快，实现了一个在非逻辑层和物理层的备份。
除了 TiDB 原生的两地三核心的 Raft based 计划外，去年咱们也在产品当中实现了两核心强统一的备份计划。因为一些银行机构或者金融机构的业务中，可能不须要两地三核心，只须要两核心的灾备容灾计划就足够了。咱们在 Raft 的框架下面，实现了两核心的强统一的计划，适配同城及近距离异地核心，且核心间通信提早较好场景，可能实现金融级的 RPO=0 的要求。
TiDB 5.0 要害布局
在明年的上半年，会推出咱们的下一步里程碑版本 —— TiDB 5.0。
在这个版本当中，会积攒咱们所有在产品的外围，以及四周的配套工具上，针对金融外围场景的改善与打磨，包含进一步的进步吞吐量，升高提早，以及进步整个存储的稳定性。同时，咱们也会联合 HTAP 在引擎上的能力，把流解决和实时的计算充沛的联合起来。另外，随着 Geo-partition 和对云原生环境的进一步适配，咱们在公有云、混合云，甚至私有云的环境当中，都会有大幅度的加强和进步。
