TiDB 实战分享丨第三方支付企业的核心数据库升级之路

导读

本文介绍了一家第三方支付企业在面对市场竞争和监管压力的态势下,通过升级核心数据库来提升业务能力的实践。该企业选择 TiDB 分布式数据库,成功将其应用于核心业务、计费、清结算和交易查询等关键系统。TiDB 的水平扩展能力、高可用性和简化数据栈等优势,使该企业在处理高并发交易和保障数据安全方面取得了显著进展,提升了业务处理的敏捷性,同时降低了运维复杂度 。

在数字时代,网络购物已经成为人们生活的重要组成部分,第三方支付行业迎来了前所未有的发展机遇。 第三方支付是指第三方支付机构在付款人与收款人之间提供的银行卡收单、网络支付和预付卡的发行与受理,以及人民银行确定的其他货币资金转移服务。 在网络购物、社交红包、线下扫码等多元化场景的推动下,中国第三方支付市场凭借便捷、高效、安全的支付体验,领先于全球。

业务挑战驱动数据库升级

某头部第三方支付企业是一家金融科技公司,拥有全面的支付牌照,为用户提供安全、便捷的支付和金融服务。用户可以通过移动应用、POS 终端、网站等多种渠道进行支付和转账。除支付服务以外,该企业还提供票务预订、充值缴费等多元化金融服务。

面对支付平台层出不穷、市场竞争异常激烈的局面,第三方支付企业在监管日益严格的背景下,纷纷聚焦产品质量提升,打造差异化竞争优势,探索服务模式创新。随着人工智能、区块链、数字货币等新兴技术的融合与应用,如何提升刷脸支付、声纹支付、车载支付等新兴支付的交易处理效率,持续拓宽新兴支付方式的切入场景并优化用户体验,成为第三方支付企业提升市场份额和竞争力的重要抓手。

为了更好地满足多变环境下业务高速发展的需求,该支付企业于 2020 年开始探索分布式数据库。经过充分的调研测试,TiDB 数据库凭借其原生分布式架构、应用的无侵入性和独立数据库厂商的中立性赢得了该企业的信任。从 2020 年开始, 该企业逐步将 TiDB 数据库应用于业务核心、计费、交易查询、清结算等多个核心系统。经过三年多的深入实践,目前核心系统运行平稳,不仅提升了业务的处理能力和敏捷性,还大幅降低了运维复杂度。截止到 2023 年 7 月, 该企业已上线 100 多个 TiDB 节点,投产超过 50% 的核心业务。

业务核心系统的数据库升级经历了四个阶段:

代码改造 :整个核心系统基础架构的迭代遵循技术领先和开源透明的思路,新的业务系统基于 MySQL 兼容的数据库进行业务改造,充分利用数据库的内核能力,避免对单一产品形成过度依赖和绑定。

并行验证 :实际生产流量跑在原有数据库 Oracle,通过网关把所有流量在 TiDB 回放,主要验证 TiDB 数据库性能及承载业务压力的稳定性,该阶段运行时间 6 个月。

流量切换 :核心业务的流量逐步按比例迁移到 TiDB,历时一个月左右,成功将近亿级别的全量交易切换到 TiDB。第三方支付企业的交易生命周期包括交易发生、计费、清算、结算、查询统计等环节,面向交易客户、商户、清算机构等群体。由于交易链路长且复杂,为了更好地把控风险和确保业务可回退,整个迁移过程中,将迁移到 TiDB 的流量在 Oracle 侧进行回放。

业务流量切换示意图

● 下游改造:将原先由多个 Oracle 实例通过 ETL、CDC 和业务写入等多种方式汇聚到 TiDB 集群中,提供包括清 算,结算,计费,商户交易统计查询等服务。

TiDB 在核心系统的应用

1 业务核心

业务核心是该企业的核心业务集群,负责存储并处理所有核心交易数据,包括各种扫码渠道和 POS 刷卡交易。每日交易笔数达到亿级别,呈现出明显的商户交易高低峰分布,涵盖了早、中、晚三个高峰时段。为了满足监管机构的要求,需要确保三方支付所有历史交易数据的可追溯性。由于原先公有云上的 RDS 数据库受到性能和容量的限制,处理能力无法达到预期,因此该企业选择使用 TiDB 替换公有云的 RDS 数据库。

TiDB 原生分布式架构设计,可以根据业务实际情况,灵活扩展计算或者存储节点,提供多副本的读写能力来解决读吞吐问题,提升响应延迟,优化 C 端和 B 端用户的使用体验。从上线至今,业务核心处理的数据量已接近 100 TB,日常交易高峰峰值 QPS 达到 60,000+,交易 99 线延迟稳定在 60 毫秒左右,充分展现了 TiDB 在规模化场景下出色的 OLTP 性能。

业务核心架构示意图

2 计费

支付行业的计费系统扮演着至关重要的角色,专门用于处理交易、计算费用并生成账单,与支付交易共同构成了支付生态的两翼。计费系统以严谨的逻辑和高效的算法,确保费用计算的准确无误。同时,它以清晰易懂的方式呈现账单信息,让用户和商户一目了然。目前整个计费数据库的 99 平均延迟稳定在 4ms 左右,峰值 QPS 10K,TPS 5 K,TiDB 完美的在一套系统中同时满足了高频的交易请求和实时的分析业务需求,有效保证了计费的时效和准确性。

3 清结算

清结算是金融机构用于处理交易结算和清算的系统。清算指按照约定的规则,计算并核实参与方的债权和债务关系,最终确定支付的义务;而结算则是履行清算结果,完成实际的支付过程。清结算系统的关键任务是确保交易的安全、准确和及时,包括处理交易、计算费用、生成结算单据以及实际的资金转移。TiDB 的水平扩展能力能够较好地应对清结算对于数据并发写入和瞬时 100K 的查询需求。

4 交易查询平台

为满足海量交易数据的查询需求,该支付企业构建了首个 TiDB 集群作为交易查询平台。该平台经历了从多个上游 Oracle 数据库同步到一套庞大中心化 Oracle 数据库的演进。然而,传统的中心化数据库体系无法满足该支付企业日益增长的交易数据量和扩展性需求,该支付企业将 Oracle 数据迁移到 TiDB 分布式数据库集群。同时,利用 TiDB 提供的 TiCDC 工具将数据同步到 Kafka 消息系统,实现了实时数据更新和多维度分析。

交易查询平台数据流转示意图

升级后,该支付企业交易查询平台在宽表组合、多表数据关联、多列数据截取等复杂操作方面展现出更为灵活的能力。TiDB 原生分布式架构使得平台能够高效地处理海量交易数据。同时,TiCDC 工具确保了数据同步的实时性和可靠性。得益于 TiDB 和 TiCDC 的加持,交易查询平台实现了多维度数据查询和分析能力的提升,为商户和内部管理提供了更全面、更精准的数据分析服务。通过实时获取业务洞察,企业能够做出更敏捷的业务响应,提升市场竞争力。

为什么选择 TiDB?

从过去三年该支付企业使用 TiDB 的实践经验来看,TiDB 带来的具体收益包括:

水平扩展能力

业务快速发展背景下,传统单机数据库难以应对高并发读写请求,性能无法水平扩展。分库分表方案的实施往往需要对业务进行大量的改造,带来了不小的成本和风险。原生分布式数据库具备灵活的弹性伸缩能力,可匹配业务的特点分别或同时扩展计算能力与存储能力。在引入 TiDB 之前,为确保核心业务系统的稳定运行,企业经常需要定期清理历史数据,过程繁琐且容易造成数据丢失。TiDB 的自动均衡能力有效解决了该问题,并满足了监管要求。

原生高可用能力

从刷卡收单、计费到后续的清结算和交易查询,每个环节都至关重要。TiDB 集群内部各个组件采用冗余设计,避免单机故障,存储节点默认采用 3 副本,通过 Multi Raft 协议保证各副本数据的一致性和高可用性。在 TiDB 集群之间,可通过 TiCDC 或者 TiDB binlog 的方式搭建灾备集群保障集群级别的高可用。TiDB 强大的高可用能力为用户提供更为可靠和稳定的交易体验。

简化数据栈,降低成本

TiDB 用一个数据平台满足实时交易与实时分析的场景需求,通过丰富的技术生态实现与 Oracle、DB2 等传统数据库的打通,实现与 Hadoop、Spark、Flink、Kafka 等大数据技术栈的广泛融合,为上层业务提供统一数据服务,在简化企业数据栈的同时大幅降低维护成本。

相关推荐
努力遇见美好的生活9 分钟前
Mysql每日一题(行程与用户,困难※)
android·数据库·mysql
卫生纸不够用37 分钟前
远程链接mysql步骤
数据库·mysql
夏小花花1 小时前
postgresql 创建序列
数据库·postgresql
Allen Bright1 小时前
Redis介绍
数据库·redis·缓存
engchina1 小时前
Oracle ADB 导入 BANK_GRAPH 的学习数据
数据库·学习·oracle·graph
不爱学习的YY酱1 小时前
【计网不挂科】计算机网络第二章< 物理层 >习题库(含答案)
java·数据库·计算机网络
CCSBRIDGE2 小时前
sql文件
数据库·oracle
柯南二号2 小时前
HarmonyOS ArkTS 下拉列表组件
前端·javascript·数据库·harmonyos·arkts
液态不合群2 小时前
Mysql篇-三大日志
数据库·mysql
喝醉酒的小白2 小时前
数据库参数备份
数据库