TiDB 作为一款高效稳定的开源分布式数据库，在国内外的银行、证券、保险、在线支付和金融科技行业得到了普遍应用，并在约 20 多种不同的金融业务场景中支撑着用户的关键计算。在 TiDB 在金融行业关键业务场景的实践（上篇）中，我们介绍了 TiDB 在银行核心交易场景的应用，本篇文章将主要分享 TiDB 在核心外围的关键业务场景的实践。
我们在核心外围的关键业务场景也有很多的案例，例如现在比较典型的在线支付业务。TiDB 主要涉足的支付领域包括商业银行的网联/银联支付业务的联机交易数据库，第三方支付公司的移动支业务核心支付系统。通过 TiDB 提供的大规模吞吐，高性能大并发联机交易，多中心多活容灾，弹性扩展机制来支撑：
商业银行侧，来自网联/银联无卡的大并发支付交易指令和支付报文数据处理；
第三方支付侧，来自移动支付 App， 商户移动 POS，支付场景嵌入式的支付业务系统后台的交易指令和支付报文处理；
支付交易的联机处理类，主要为支付钱包数据的处理，支付交易数据联机插入与更新，交易状态实时查询，交易历史记录和账单查询；
支付交易中的费率等计算；
支付过程中的反洗钱系统的数据汇聚及规则计算。
自 2018 年投产以来，三年的时间里 TiDB 稳定的支持了北京银行的网联支付和银联无卡支付的核心系统，采用了北京同城+西安两地三中心的多活容灾结构，顺利的渡过了两次双十一，比较好的支撑这个业务。另外，我们在包括天翼支付的支付结算、账单、反洗钱平台，宝付的支付数据汇聚和日本排名第一的支付公司 PayPay 的联机支付核心及支付钱包核心平台，都有了具体的落地案例。
TiDB 主要落地股份制商业银行财富管理业务条线中的在线理财业务，通过 TiDB 提供的大规模吞吐、高性能大并发联机交易、多中心多活容灾以及弹性扩展机制来支撑理财业务中的：
今年上半年，我们和光大银行完成了理财交易核心库和联机批库交易的投产工作，比较好的支撑了整个光大银行理财业务的核心联机交易的处理以及日间和日终的数据批量计算。此外，我们也在北京银行的理财销售平台和微众银行企业同业的理财交易流水有了相关的场景落地。我们还有一大类关键的金融应用场景是实时风控业务。跟传统的风控不一样，随着互联网化的业务场景增多，银行和泛金融机构对于实时风控的要求是非常高的。TiDB 目前在风控业务中的实时风控数据汇聚、存储、管理、加工、计算场景方面已经有多个落地实践。通过 TiDB 分布式存储核心机制，应对海量数据的实时写入，同时分布式计算层以及行列混合引擎的设计能够针对风控指标的点查计算和批量汇总统计计算提供实时处理能力，将传统基于大数据手段的 “T+1” 风控业务处理能力直接提升到 “T+0” 级别，如高达秒级的风控数据计算查询。
在金融业务场景方面，我们有包括北京银行线上业务风控模型管理平台、微众银行 CNC 反欺诈系统、天翼支付反洗钱平台、拉卡拉金融实时风控平台等一系列的场景落地。同时在互联网及电商业务场景中，包括像东南亚知名电商 Shopee 的风控平台，小红书反欺诈系统及实时风控平台、拼多多风控平台等都有了一些落地。除了银行业务之外，TiDB 也广泛应用在保险行业。在保险行业，主要在前台、中台、后台三大领域有投产业务。
在前台，主要是偏向于互联网和移动端联机交易这一侧，包括保单的投保、财富增值、会员活动等一些在线联机交易的支撑。我们在去年成功的支持了平安产险暖宝保的业务，在很短的时间内完成了整个集群的投产上线以及平安财神节的一个高峰交易。
在中台，业务主要涉及到以中台业务群为前端的后台的数据支撑，包括像中台的微服务化、单元模块改造和业务的改造工作，TiDB 能够通过云原生的架构比较好的适配微服务的应用环境，消除应用对分布式数据存取框架的依赖，无需引入数据中间件，并且能够做到在线弹性扩展。我们在平安人寿的“金管家”业务和平安产险的“询价出单”业务中都有相关的落地。
在后台，由于 TiDB 本身超大规模的海量数据存储架构以及具备批量数据的处理能力，我们在认证、支付、结算、包括前面提到的风控类业务，都有若干的案例落地。在这类业务中，比较偏向于实时的 OLAP 分析，涉及到 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。
在这个版本当中，会积累我们所有在产品的核心，以及周围的配套工具上，针对金融核心场景的改善与打磨，包括进一步的提高吞吐量，降低延迟，以及提高整个存储的稳定性。同时，我们也会结合 HTAP 在引擎上的能力，把流处理和实时的计算充分的结合起来。另外，随着 Geo-partition 和对云原生环境的进一步适配，我们在私有云、混合云，甚至公有云的环境当中，都会有大幅度的增强和提高。
京公网安备 11010802041100号