达达集团技术

达达快送二清打款性能优化

一、背景介绍

作为业内领先的本地即时配送平台,达达快送拥有上百万的活跃骑士。在骑士提现业务中,达达集团积极响应国家发布的《关于规范支付创新业务的通知》政策要求,需要通过与有资质的银行(以下简称银行)合作,加入国家安全监管体系,规范资金清分、结算支付的业务流程。

该业务在达达集团内部,由负责达达快送和京东到家资金清结算的账户团队设计研发,上线后的某个业务高峰期,当日提现单量超过平时的3倍,导致部分骑士的提现在20:00才到账,这严重低于账户团队定义的到账时效。经过此次优化,在相同情况下,18:00前就能完成所有的发薪付款任务。

二、流程概述

在骑士提现的打款环节,先由达达财务进行统一审批,再由“二清服务”以Job方式和银行系统进行指令交互,最终完成发薪付款。

名词解释:
1. 清分:银行网络交易清算的数据准备工作。
2. 出金: 资金由交易账户划入到银行账户的过程。
举个例子:清分好比制作工资单,出金就是按工资单实际打款,也就是说出金之前必须先完成清分。

三、现状分析

在月初和月末,以及节假日前的提现高峰期,骑士提现总流程耗时超过4小时,这带来了哪些问题?

1. 骑士的经验到账时间一般在18:00-19:00之间,如果晚于这个时间,将严重影响骑士体验,降低骑士对平台的满意度,同时会造成大量骑士集中进线咨询,占用客服资源。

2. 随着公司业务的快速发展,骑士提现的总笔数和频次都在持续增长,在不久的未来,现有方案还能支撑多久?
通过对整体流程的梳理、监控以及分析日志发现:

1. 财务人工参与的环节已经是安全合规要求下的最简版本,达达内部系统耗时并不多,优化空间不大。

2. 和银行系统的交互过程 消耗了 87.5%的时间 ,银行系统主要存在以下问题:

显然,银行系统达不到高并发请求交互的性能要求,那该怎么解决呢?银行系统若保持现状,该如何缩短交互时间?

四、优化思路

针对上述问题,达达系统分别做出了相应的调整:

1. 异步并发

虽然银行接口API最大容量限制为18,但通过分析RPC请求发现:实际在单线程串行请求方式下只占了最大容量的13.9%(采样10000笔的计算结果)。怎样才能占满TPS=18的最大阈值?能使用多线程并发的请求方式吗?银行系统扛得住吗?

测试环境使用jmeter模拟并发请求,经反复验证,在适当的线程数下基本接近了最大阈值。

因此,和银行接口的交互由之前串行同步方式改成独立线程池来异步执行,线程池核心数和最大线程数均设为18,可最大化使用接口容量。

2. 扩大超时时长

在timeout设置为3s、单线程串行RPC请求银行接口时,接口超时率高达10.5%,而Job调度频率为每10分钟一次,因此,将timeout从3s延长到20s,多等几秒可降低接口超时率,胜过再等10分钟进入下次调度。此处存在一个系统隐患,即银行系统出现问题时,可能造成线程阻塞,但在之前提过,和银行交互设有独立线程池,最坏的情况全量阻塞仅影响18个线程,风险可控。

3. 幂等重试

由于银行接口不幂等、错误码不确定等因素,清分和出金超时后不能重试,只能通过反查接口查询验证以实现逻辑上的“幂等”。但如果反查接口也超时,则需要再等10分钟进入下一轮Job调度。因此,针对反查超时,则进行多次重试,尽量在一次调度中拿到明确结果。

4. 资金安全

多线程并发请求方式下,为了保障资金安全,防止重复付款或漏付,采取了如下措施:

1. 业务隔离:隔离清分和出金两个付款环节。

2. 金额校验:每个环节结束后校验操作前后账户差额等等。

此处,如果合并清分和出金2个Job,理论上效率会有明显提升,但合并2个Job相当于重构了核心流程,改动非常大,本着“小步快跑”的原则,先看看能否满足业务要求,结合实际效果再做决定。 综上所述,优化后的部分流程图如下:

部分时序图如下:

五、线上验证

1. 业务高峰期实际结果

清分JOB:

  • 首次清分耗时约14min
  • 针对首次清分超时的,再次清分耗时约2min
  • 12:10~12:40清分总耗时30min

出金JOB:

  • 首次出金耗时约16min

  • 针对首次出金超时的,再次出金耗时约2min

  • 14:00~14:30出金总耗时30min

2. 效果对比

六、总结反思

优化后骑士提现的打款环节,效率较之前有明显提升。整体方案从技术角度上说并不复杂,无需大刀阔斧的对现有流程做重大改造,带来的好处就是开发成本较低,可快速交付,实际上从讨论方案到开发测试,仅花费了一周时间。按照当前处理效率,现有系统能力可支撑未来业务4倍增长。
反观上线之初的1.0版本,并没有对系统处理效率做过多设计,原因是当时的业务体量并不大,本着业务先行的原则,系统效率在满足业务目标的前提下有一定冗余即可,但随着业务量不断增长,之前的系统架构也需要齐 驱 并进。