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

原创祝欣鸿杨军达达集团技术

一、背景介绍

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

该业务在达达集团内部，由负责达达快送和京东到家资金清结算的账户团队设计研发，上线后的某个业务高峰期，当日提现单量超过平时的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个线程，风险可控。