TiDB x 中国电信翼支付 | 「效率提升 5 倍」，TiDB 在电信翼支付金融核心场景的应用

「我们已经用起来了」，是我们最喜欢听到的话，简简单单几个字的背后代表着沉甸甸的信任和托付。从今天开始，我们将通过「相信开放的力量」系列深度案例分享，从业务的角度，看看一个数据库为各行业用户带来的业务价值。本篇文章将介绍 TiDB 助力中国电信翼支付金融核心场景的故事。

“ 餐饮娱乐 、投资理财、商户服务......让大家尽情享受安全、便捷的金融新生活。”

中国电信翼支付（以下简称：翼支付）成立于 2011 年 3 月，是中国电信旗下的运营支付和互联网金融的业务品牌，是中国人民银行核准的第三方支付机构，是中国证监会核准的基金支付结算机构，支持各类线上线下民生支付应用，一直致力于为个人、企业提供“安全、便捷、时尚”的支付解决方案。

2019 年翼支付月活用户 5000 万，每月 2.3 亿笔交易，年交易金额超 1.75 万亿。目前累计接入华润、永辉、苏宁小店、物美、中百等超 800 万家线下商户门店及苏宁易购、京东、天猫、饿了么、中粮我买网、美团等 170 余家线上电商。

客户收益

面对业务快速增长及激烈的市场竞争压力，翼支付技术团队选择 TiDB，对业务系统尤其是支付系统数据库进行改造升级。经过不懈努力，反洗钱系统效率提升 5 倍，对账平台性能提升 2 倍，而处理时间减少 ⅔ ！目前，翼支付业务层以及核心平台层都采用 TiDB 提供服务。

“ 我们对系统的改造升级，不仅达到了监管部门的要求，也让财务部门运营的处理能效得到了很大的提升，还大大降低了技术团队的工作复杂度。新系统上线以后，我们对 TiDB 的表现比较满意。 ——翼支付基础架构技术团队”

• 风控监管：反洗钱系统超越监管要求，实测结果显示：整体批处理性能提高了 3 倍以上，时间也缩短至原来的 ⅓，平台整体有效处理能力提升到 5 倍以上。

• 伙伴结算：对账平台处理时间减少 ⅔ ，性能提高 2 倍，就经常使用的三种形式来看：

• 银联支付宝，以前使用 MySQL 用时两分钟，现在使用 TiDB 只要 40 秒，性能提高了 300%；

• 银联无卡支付，使用 MySQL 用时 3-5 分钟，TiDB 用时 1-2 分钟，性能提升 200% - 300%；

• 微信支付，MySQL 用时 3 分钟，TiDB 约 1 分钟，性能提升 300%。

• 个人账单：有效改善使用体验，增加了用户活跃度，解决了原有分库分表在容量、存储周期、查询效率等方面问题：

• 现在使用 TiDB 单表数据量近 100 亿，原来 MyCAT 只能按照月来分表，单表存储容量上限为 1 亿；

• 存储周期可以借助 TiDB 线性扩展能力延长至 3 - 5 年，甚至更长，原来 MySQL 只能存储半年；

• QPS 提升 50 %，延迟降低 20-30%，成功应对 525 大促。

面临挑战

优异成绩的得来，向来都不是一帆风顺。在项目启动之初，双方团队就面临了不小的难题。

反洗钱风控 时间紧 任务重

随着《中华人民共和国反洗钱法》修改工作正式启动，监管部门对处理时间的要求是 T+1 （次日）的时间内必须要完成可疑的规则和风险评级的计算要求。

之前跑批单的任务时间大概都在几百分钟，每天整体任务处理的时间都会在 15 小时甚至更长，随着数据量越来越大，业务系统面临了越来越大的风险，所以反洗钱系统在性能上也提出了比较强的要求：

• 满足 SQL 2003 的标准；

• 多表关联，能够查询数据集 1 千万以下，响应时间 5 秒以内；

• 数据文件批量加载，20G 大小，大概不能超过 30 分钟；

• 亿万数据中要删除 50 万数据，响应时间要在 10 秒之内；

• 3 亿数据中删除两千万，也要有 10 秒之内的响应时间；

• 3 亿数据量更新 100 万，响应时间 5 分钟左右。

交易激增 要扩展 提性能

与此同时，翼支付团队还需要解决两个问题：第一，现有数据库架构是否支撑未来业务的成长，包括功能、可扩展性、稳定性、服务支持能力等方面的需求；第二，性能始终是难题，在现有架构上提升一点都非常困难，何况数倍提升的要求。

解决方法

经过双方团队对业务系统的深入分析和研判，做出了三步走的策略，首先评估现状考虑数据库架构的调整方法，接下来在营销业务进行试点，然后聚焦解决核心支付业务的问题。

基于业务场景 建立数据库评估模型

在进行了大量的测试之后，最终确定了翼支付基于业务场景构建数据库选型评估模型，双方经过仔细研判后决定：对于新采用的项目，在关系型数据库的选型上，不再考虑使用 Oracle，按照容量阀、性能阀、大表的数量、分区规则、 HTAP 能力，以及拓扑结构这几个纬度进行容量筛选。得出结论在翼支付的业务场景中对于容量大于 3T，QPS 大于 20000，大表数量比较多，而且分片规则很难定义，以及一些实时分析场景，优先选择使用 TiDB 。

场景试点 提升用户体验

个人账单系统在翼支付 APP 客户端内，是为个人用户提供所有交易的账单数据的管理、查询功能，以及数据的分类和统计功能，以便用户能更好的掌握自己通过翼支付所做的所有交易。根据评估模型，也是属于典型的 TiDB 适用场景，团队按照应用切换原则，选用了 TiDB 的数据同步工具在短时间内进行了应用切换和迁移工作。

切入业务 提升 TB 级支付效能

同样基于评估模型，团队选择了对账平台系统及反洗钱系统进行核心攻关。

对账平台系统涉及到多张表，单表的规模超 10 亿，整体数据规模超过 8T+，业务应用的逻辑相对复杂，数据并发量中等。改造后，核心支付系统产生交易流水，通过文件形式传输到文件解析服务，文件解析服务将数据的解析结果保存到分布式数据库，对账系统基于分布式数据库完成对账的流程，同时向 WEB 端提供查询页面和查询服务。

在反洗钱系统方面，随着监控数据的数量和类型发生许多变化，反洗钱业务需求数据日益增大，监控的范围不断的扩大。团队按照 TiDB 的形式进行架构升级，一方面通过（OGG for MySQL client )，将数据从原来的 Oracle 同步到 TiDB；另一方面使用大数据的发布功能，从 Hive 直接去同步到 TiDB。

挺进核心 布局未来

下一阶段翼支付将会扩大 TiDB 的应用范围，将业务发展快、规模大的核心链路的系统，逐步往 TiDB 迁移，而这需要做几方面工作，一方面是外部环境变化，未来可能在数据库上也会做很多的限制，必须提前做一些准备；另一方面是考虑性能规划可以满足未来业务不断增长的需求。

目前的核心库都会有上亿数据量的规模，单库总数据量 10T 以上，核心业务要求停机时间非常短或不能停，这就对数据库提出了较高的要求，同时需要在开发模式上进行更新，包括：采用 Oracle 和 TiDB 共存的双模式开发，支持灰度或者双写的切换过程，提升业务校验能力，进行模块和批次进度的设计。另外，在运维管理上也有更高的要求，包括窗口的切换操作的过程、回退的预案等。

为何选择 TiDB

“ 从中国电信翼支付的项目不难看出，我们就是看重了 PingCAP 团队对于核心业务的理解，以及对分布式数据库架构的设计及改善能力。 ——翼支付基础架构技术团队”

降风险 促业务

对于运营商尤其是支付业务来说，风控是第一位的，只有规避的风险，才能保障业务运行；而在此之上，要适应于业务发展及场景要求，更要为业务发展做好规划，预设技术路线及预留发展空间，这对技术团队的数据库建构设计能力及数据处理效能的改善能力提出了较高要求，毫无疑问，TiDB 及其团队值得客户信赖！

与客户同行，相信开放的力量

每次数据库架构改善与落地，无论是 TB 级还是 PB 级，都需要付出努力，但这也值得每一个企业去实践。在当下这个时代，不管企业的规模如何，都要学会借助开源的力量，避免去重复的造轮子。

每一个看似轻松的背后都有不为人知的努力，每一个看似光鲜亮丽的背后，都有不为人知的付出。分布式数据库建设之路道阻且长，TiDB 愿与翼支付及每个客户一起，携手并肩把事情做好。

延伸阅读

下一篇精彩案例，coming soon…