CN113298513A

CN113298513A - 代付请求处理方法及系统

Info

Publication number: CN113298513A
Application number: CN202110686622.4A
Authority: CN
Inventors: 毕坚; 殷凇; 罗子辉
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2021-06-21
Filing date: 2021-06-21
Publication date: 2021-08-24
Also published as: WO2022267395A1

Abstract

本发明涉及金融科技(Fi ntech)技术领域，公开了一种代付请求处理方法及系统，当接收到代付请求时，确定对应的商户和当前代付方案，判断当前代付方案是否为批量方案；若不是批量方案，则将商户TPS与当前代付方案的TPS阈值进行比较，以确定商户的方案切换方向；判断商户的预设代付可选方案中是否存在与方案切换方向相匹配的待定可选方案；若存在，则确定目标代付方案，并将当前代付方案切换为目标代付方案；执行目标代付方案，以完成对应的代付处理流程。通过动态地对商户进行方案切换处理，将商户的当前代付方案切换到适配的目标代付方案，以及时处理不同并发程度的代付请求，提高代付请求的处理效率。

Description

代付请求处理方法及系统

技术领域

本发明涉及金融科技(Fintech)技术领域，尤其涉及代付请求处理方法及系统。

背景技术

随着计算机技术的发展，越来越多的技术(大数据、分布式、人工智能等)应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性、通用性要求，也对代付请求处理技术提出了更高的要求。

目前，为了保证代付请求处理过程中账户数据的准确性，银行机构在进行记账处理时，会先对账户的资源加锁，待记账处理完毕后自动释放锁。而随着处理业务量的增大，数据库中的账户常常会在短时间内产生多个并发操作，但在实际的代付处理过程中，只有一个线程能够持有当前账户的资源锁，而其他线程必须等待该锁被释放后再逐一进行记账处理，使得该账户被频繁加锁释放锁，即高频进行扣款、入账处理等代付处理流程，从而成为代付请求处理系统中的热点账户，这会严重影响到其他账户代付请求的处理速度，导致代付请求的处理效率低下。

发明内容

本发明的主要目的在于提出一种代付请求处理方法及系统，旨在提高代付请求的处理效率，尤其是高并发代付请求对应的处理效率。

为实现上述目的，本发明提供一种代付请求处理方法，所述方法包括如下步骤：

当接收到代付请求时，确定所述代付请求对应的商户，以及所述商户的当前代付方案，并判断所述商户的当前代付方案是否为预设批量方案；

若当前代付方案不是预设批量方案，则将所述商户的TPS与当前代付方案对应的预设TPS阈值进行比较，并根据比较结果确定所述商户的方案切换方向，所述商户的TPS为单位时间内处理的所述商户的代付请求数；

获取所述商户的预设代付可选方案，并判断所述预设代付可选方案中是否存在与所述方案切换方向相匹配的待定可选方案；

若存在，则从所述待定可选方案中确定所述商户的目标代付方案，并将所述商户的当前代付方案切换为所述目标代付方案；

执行所述目标代付方案，以完成所述代付请求对应的处理流程。

优选地，所述根据比较结果确定所述商户的方案切换方向的步骤包括：

若比较结果为所述商户的TPS大于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更大的预设代付可选方案切换；

若比较结果为所述商户的TPS小于或等于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更小的预设代付可选方案切换。

优选地，所述方案切换方向为向预设TPS阈值更大的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：

根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更大的待定可选方案，并判断当前获取到的待定可选方案是否为预设批量方案；

若当前获取到的待定可选方案不为预设批量方案，则将所述商户的TPS与当前获取到的待定可选方案对应的预设TPS阈值进行比较；

当所述商户的TPS小于或等于当前获取到的待定可选方案对应的预设TPS阈值时，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案，若能切换，则将当前获取到的预设代付可选方案确定为所述商户的目标代付方案；

当所述商户的TPS大于当前获取到的待定可选方案对应的预设TPS阈值，或者不能将所述商户的当前代付方案切换为当前获取到的待定可选方案时，获取下一个预设TPS阈值更大的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。

优选地，所述方案切换方向为向预设TPS阈值更小的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：

根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案；

若当前获取到的待定可选方案不属于所述预设的TPS总值限制方案，则将当前获取到的待定可选方案确定为所述商户的目标代付方案。

优选地，所述判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案的步骤之后，还包括：

若当前获取到的待定可选方案属于所述预设的TPS总值限制方案，则根据当前获取到的待定可选方案的TPS总值和所述商户的TPS，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；

若能切换，则将当前获取到的待定可选方案确定为所述商户的目标代付方案；

若不能切换，则获取下一个预设TPS阈值更小的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。

优选地，所述判断所述商户的当前代付方案是否为预设批量方案的步骤之后，还包括：

若当前代付方案是预设批量方案，则获取所述商户的预设代付可选方案，并从所述商户的预设代付可选方案中筛选出比当前代付方案对应的预设TPS阈值更小的待定可选方案；

根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；

若能切换为当前获取到的待定可选方案，则将当前获取到的代付可选方案确定为所述商户的目标代付方案；

若不能切换为任一待定可选方案，则维持所述商户的当前代付方案。

优选地，应用于代付请求处理系统，所述代付请求处理系统包括存款核心，所述执行所述目标代付方案，以完成所述代付请求对应的处理流程的步骤包括：

对所述代付请求对应的代付流水进行状态初始化处理，以将所述代付流水的当前处理状态初始化为预设初始处理状态；

将所述代付流水存储至预设数据库，并将所述代付流水对应的请求信息发送给所述商户对应的消息队列；

通过所述消息队列对应的监听线程从所述预设数据库中取出所述代付流水，并将所述代付流水发往所述存款核心，以供所述存款核心根据所述目标代付方案对所述代付流水进行代付处理，完成所述代付请求对应的处理流程。

优选地，所述方法还包括：

从所述预设数据库中取出当前处理状态为预设初始处理状态的待处理代付流水，并对所述待处理代付流水进行代付处理，得到对应的代付处理状态；

将所述待处理代付流水的当前处理状态更新为所述代付处理状态；

当所述预设数据库中的代付流水对应的代付处理状态均为预设处理完成状态时，则将处理完成后的待处理代付流水发往所述存款核心，以供所述存款核心对所述处理完成后的待处理代付流水进行代付处理。

优选地，所述目标代付方案为预设批量方案，所述将所述代付流水存储至预设数据库的步骤之后，还包括：

从所述预设数据库中查询当前处理状态为预设初始处理状态的批量代付流水，并生成所述批量代付流水对应的统一批次号；

获取所述批量代付流水中的商户号，将所述统一批次号和所述商户号发送给预设目标消息队列；

通过所述预设目标消息队列对应的监听线程根据所述统一批次号和所述商户号从所述预设数据库取出所述批量代付流水，并组装所述批量流水对应的批量请求发往所述存款核心，以供所述存款核心根据所述批量请求对所述批量代付流水进行代付处理。

此外，为实现上述目的，本发明还提供一种代付请求处理装置，所述代付请求处理装置包括：

第一判断模块，用于当接收到代付请求时，确定所述代付请求对应的商户，以及所述商户的当前代付方案，并判断所述商户的当前代付方案是否为预设批量方案；

比较确定模块，用于若当前代付方案不是预设批量方案，则将所述商户的TPS与当前代付方案对应的预设TPS阈值进行比较，并根据比较结果确定所述商户的方案切换方向，所述商户的TPS为单位时间内处理的所述商户的代付请求数；

第二判断模块，用于获取所述商户的预设代付可选方案，并判断所述预设代付可选方案中是否存在与所述方案切换方向相匹配的待定可选方案；

方案切换模块，用于若存在，则从所述待定可选方案中确定所述商户的目标代付方案，并将所述商户的当前代付方案切换为所述目标代付方案；

代付执行模块，用于执行所述目标代付方案，以完成所述代付请求对应的处理流程。

此外，为实现上述目的，本发明还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上所述的代付请求处理方法的步骤。

此外，为实现上述目的，本发明还提供一种代付请求处理系统，所述代付请求处理系统包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的代付请求处理程序，所述代付请求处理程序被所述处理器执行时实现如上所述的代付请求处理方法的步骤。

此外，为实现上述目的，本发明还提供一种存储介质，所述存储介质上存储有代付请求处理程序，所述代付请求处理程序被处理器执行时实现如上所述的代付请求处理方法的步骤。

本发明提出的代付请求处理方法，当接收到代付请求时，确定对应的商户和当前代付方案，判断当前代付方案是否为批量方案；若不是批量方案，则将商户TPS与当前代付方案的TPS阈值进行比较，以确定商户的方案切换方向；判断商户的预设代付可选方案中是否存在与方案切换方向相匹配的待定可选方案；若存在，则确定目标代付方案，并将当前代付方案切换为目标代付方案；执行目标代付方案，以完成对应的代付处理流程。通过动态地对商户进行方案切换处理，将商户的当前代付方案切换到适配的目标代付方案，以及时处理不同并发程度的代付请求，提高代付请求的处理效率。

附图说明

图1是本发明实例方案涉及的硬件运行环境的系统结构示意图；

图2为本发明代付请求处理方法第一实施例的流程示意图；

图3为本发明代付请求处理方法较佳实施例的商户配置表；

图4为本发明代付请求处理方法较佳实施例的商户属性扩展表；

图5为本发明代付请求处理方法较佳实施例(方案一)的代付处理流程图；

图6为本发明代付请求处理方法较佳实施例(方案二)的代付处理流程图；

图7为本发明代付请求处理方法较佳实施例的方案切换处理流程图；

图8为本发明代付请求处理方法较佳实施例(方案三)的代付处理流程图；

图9为本发明代付请求处理方法较佳实施例(方案三)的并发控制流程图；

图10为本发明代付请求处理方法较佳实施例(批量方案)的代付处理流程图；

图11为本发明代付请求处理方法较佳实施例(批量方案)的并发控制流程图；

图12为本发明代付请求处理方法较佳实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，图1是本发明实施例方案涉及的硬件运行环境的系统结构示意图。

本发明实施例系统可以是管理服务器、PC端、移动设备等。

如图1所示，该系统可以包括：处理器1001，例如CPU，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的系统结构并不构成对系统的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及代付请求处理程序。

其中，操作系统是管理和控制代付请求处理系统与软件资源的程序，支持网络通信模块、用户接口模块、代付请求处理程序以及其他程序或软件的运行；网络通信模块用于管理和控制网络接口1002；用户接口模块用于管理和控制用户接口1003。

在图1所示的代付请求处理系统中，所述代付请求处理系统通过处理器1001调用存储器1005中存储的代付请求处理程序，并执行下述代付请求处理方法各个实施例中的操作。

基于上述硬件结构，提出本发明代付请求处理方法实施例。

参照图2，图2为本发明代付请求处理方法第一实施例的流程示意图，所述方法包括：

步骤S10，当接收到代付请求时，确定所述代付请求对应的商户，以及所述商户的当前代付方案，并判断所述商户的当前代付方案是否为预设批量方案；

本实施例代付请求处理方法运用于各大金融机构的代付请求处理系统中。为描述方便，以银行机构的代付处理过程为例进行阐述，那么，在本实施例中的代付，是指客户从本行的账户向指定的银行卡账户进行款项划付的业务。目前，为了保证代付请求处理过程中账户数据的准确性，银行机构在进行记账处理时，会先对账户的资源加锁，待记账处理完毕后自动释放锁。而随着处理业务量的增大，数据库中的账户常常会在短时间内产生多个并发操作，但在实际的代付处理过程中，只有一个线程能够持有当前账户的资源锁，而其他线程必须等待该锁被释放后再逐一进行记账处理，使得该账户被频繁加锁释放锁，即高频进行扣款、入账处理等代付处理流程，从而成为代付请求处理系统中的热点账户，这会严重影响到其他账户代付请求的处理速度，导致代付请求的处理效率低下。

在本实施例中，可预先根据本银行机构的合作商户所提供的初步预估的代付请求并发量来配置一张商户配置表，如图3所示，可在商户配置表配置商户号、代付方案类型、消息队列主题topic、代付方案是否可动态切换等内容，其中，不同商户号对应不同的商户。为描述方便，若按照商户并发量升序的方式进行排序，以本实施例的代付方案类型包括方案一、方案二、方案三和批量方案为例进行阐述，其中，方案一和方案二用于处理低并发或正常并发情况的代付请求，方案三和批量方案用于处理高并发情况下的代付请求。当接收到代付请求时，可根据代付请求中携带的商户号确定该代付请求对应的商户，并查询商户配置表中该商户对应的代付方案类型，即可确定该商户对应的当前代付方案，当然，在对商户进行方案切换处理之前，需要先查询商户配置表，以确定该商户是否可以动态切换方案，即确定该商户是否拥有方案切换权限。如图3的商户配置表所示，商户号为0000001的商户可进行动态切换，即说明该商户拥有方案切换权限，则可将该商户的当前代付方案切换为另一个代付方案；而商户号为0000002的商户不能进行动态切换，即说明该商户不拥有方案切换权限，则无论该商户的TPS如何变化，都会维持当前代付方案。因此，只有在商户配置表中查询到该商户能动态切换方案，即该商户拥有方案切换权限时，才能对该商户进行方案切换处理，故本实施例中的方案切换处理流程主要是针对具有方案切换权限的商户提出的。

另外，若商户的预设代付可选方案包括方案一、方案二、方案三和批量方案，可分别为方案一、方案二和方案三设置对应的TPS阈值，由于批量方案(预设批量方案)对应的吞吐量最大，故批量方案没有对应的TPS阈值，因此在对该商户进行方案切换处理时，还需要判断该商户的当前代付方案是否为预设批量方案，以将不需要将该商户的TPS和当前代付方案对应的TPS阈值进行比较的批量方案和其他方案(方案一、方案二和方案三)区分开来。

需要说明的是，和方案三不同的是，批量方案的消息队列只有一个，也即，当前代付方案为批量方案的所有商户，其对应的代付请求都共用同一个消息队列，所以无需为每个商户配置一个消息队列。但是，在设置商户配置表时，如对于方案三，也可为每个商户配置一个消息队列，从而达到各商户之间隔离的目的。当然，代付方案的类型和数量可根据实际情况进行设定，本发明对此不作具体限制。

步骤S20，若当前代付方案不是预设批量方案，则将所述商户的TPS与当前代付方案对应的预设TPS阈值进行比较，并根据比较结果确定所述商户的方案切换方向，所述商户的TPS为单位时间内处理的所述商户的代付请求数；

在本实施例中，单位时间内处理的商户的代付请求数，即商户的TPS(Transactions Per Second)，商户的TPS可以代表商户当前的并发量；TPS阈值指的是TPS上限值。由于预设代付可选方案中包含该商户的当前代付方案，该商户可能存在吞吐量比当前代付方案的吞吐量更大和/或更小的其他预设代付可选方案，因此，该商户对应的方案切换方向包括向吞吐量更大的预设代付可选方案切换或向吞吐量更小的预设代付可选方案切换。具体的，若确定商户的当前代付方案不是批量方案，即该商户的当前代付方案是方案一或方案二或方案三，则将商户当前的TPS与当前代付方案对应的TPS阈值进行比较，以根据比较结果确定该商户的方案切换方向，从而提高代付请求的处理效率，并提升用户体验。

进一步地，所述根据比较结果确定所述商户的方案切换方向的步骤包括：

步骤a1，若比较结果为所述商户的TPS大于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更大的预设代付可选方案切换；

步骤a2，若比较结果为所述商户的TPS小于或等于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更小的预设代付可选方案切换。

在本实施例中，若商户的TPS大于当前代付方案对应的预设TPS阈值，则确定该商户的方案切换方向为向预设TPS阈值更大的预设代付可选方案切换，也即，将该商户的当前代付方案往吞吐量更大的方案进行切换；若商户的TPS小于或等于当前代付方案对应的预设TPS阈值，由于需要对该商户进行方案切换处理，则确定该商户的方案切换方向为向预设TPS阈值更小的预设代付可选方案切换，也即，将该商户的当前代付方案往吞吐量更小的方案进行切换，以确定该商户最适配的代付方案。例如，假设某商户配置的代付可选方案包括方案一、方案二、方案三和批量方案，且当前商户在方案一配置的TPS阈值为100，在方案二配置的TPS阈值为200，在方案三配置的TPS阈值为300，在批量方案不需要配置TPS阈值，因为批量方案无TPS上限值，且商户的当前代付方案是方案三，即当前商户的TPS小于300，如果检测到该商户的TPS升到400了，则直接切到批量方案；若该商户的TPS又下降到280，则将当前代付方案切换到方案三，如此类推。另外，如果该商户的TPS由280下降到50了，也可以直接将当前代付方案切换到方案一，也可以逐步将商户当前的TPS与待切换的方案对应的TPS阈值进行比较，从而确定商户当前的最适配方案。

步骤S30，获取所述商户的预设代付可选方案，并判断所述预设代付可选方案中是否存在与所述方案切换方向相匹配的待定可选方案；

在本实施例中，确定该商户往吞吐量更大/更小的方案进行切换之后，可从预先配置的商户属性扩展表中获取该商户的预设代付可选方案，如图4所示，商户属性扩展表中包括各个预设商户对应的预设代付可选方案，一般来说，预设代付可选方案包括商户的当前代付方案，然后判断预设代付可选方案中是否存在与该商户的方案切换方向相匹配的待定可选方案，具体的，若该商户的方案切换方向为向预设TPS阈值更大的预设代付可选方案切换，则判断该商户的预设代付可选方案中是否存在比当前代付方案吞吐量更大的代付方案；若该商户的方案切换方向为向预设TPS阈值更小的预设代付可选方案切换，则判断该商户的预设代付可选方案中是否存在比当前代付方案吞吐量更小的代付方案。例如，图4中商户号为0000004的商户拥有方案切换权限，且其对应的预设代付可选方案包括方案一、方案二和方案三，由于方案一、方案二和方案三对应的吞吐量是越来越大的，若该商户的当前代付方案为方案二，当确定该商户需要进行方案切换处理时，可根据该商户的方案切换方向，将方案一或方案三作为该商户对应的目标代付方案，如向吞吐量更小的方向进行切换时，将方案一作为待定可选方案；若向吞吐量更大的方向进行切换时，可将方案三作为待定可选方案。

步骤S40，若存在，则从所述待定可选方案中确定所述商户的目标代付方案，并将所述商户的当前代付方案切换为所述目标代付方案；

在本实施例中，若预设代付可选方案中存在与方案切换方向相匹配的待定可选方案，即说明理论上可将该商户的当前代付方案切换到另一待定可选方案，且待定可选方案至少包括一个代付方案，因此，可从待定可选方案中确定商户待切换的代付方案，即目标代付方案，并将该商户的当前代付方案切换为目标代付方案。为需要进行方案切换处理的商户动态切换到适配的方案，可尽可能地保证不同并发量的商户代付请求被及时处理，从而提高代付请求的处理效率。

进一步地，所述判断所述预设代付可选方案中是否存在与所述方案切换方向相匹配的待定可选方案的步骤之后，还包括：

步骤b，若不存在与所述方案切换方向相匹配的待定可选方案，则维持所述商户的当前代付方案，并执行当前代付方案，以完成所述代付请求对应的处理流程。

在本实施例中，若商户的预设代付可选方案中不存在与方案切换方向相匹配的待定可选方案，则说明该商户的当前代付方案已经是最适配的代付方案，只需要维持带钱代付方案即可，从而执行当前代付方案，以完成代付请求对应的处理流程。

步骤S50，执行所述目标代付方案，以完成所述代付请求对应的处理流程。

在本实施例中，代付请求处理系统包括存款核心、统一支付平台等，其中，存款核心为银行的核心记账系统；统一支付平台特指银行对内的统一支付平台系统，用于将代付请求中的款项转入他行银行卡。目标代付方案可以是处理不同商户并发量的方案一、方案二、方案三、批量方案等代付方案中的一个方案，如图5所示，图5为本发明代付请求处理方法较佳实施例(方案一)的代付处理流程图。若目标代付方案为方案一，在接收到客户的代付请求后，首先对代付请求中的请求数据进行校验，如校验请求数据对应的商户与发送该代付请求的商户是否匹配、请求数据是否为空、数据格式是否符合等等，在请求数据校验通过后入库到代付流水表中，然后组装一对一转账请求数据，发往存款核心；若存款核心处理失败，即客户账户上的款项扣款失败，则将该代付请求在代付流水表中的代付状态更新为“失败”，并将交易失败的消息返回对应的客户端；若存款核心处理成功，即客户账户上的款项扣款成功，则判断待转入的账户(收款方)是否为本银行开立的账户(行内账户)；若收款方为行内账户，则直接将客户账户上的款项划到待转入的账户上，并将交易成功的消息返回对应的客户端；若收款方不是行内账户，则将客户账户上的款项划到产品专有的内部户中，组装报文请求发送到统一支付平台，由统一支付平台走不同的支付通路，如网联、银联等支付通路，将内部户的钱转入到代付请求对应的他行银行卡上，统一支付平台接收到支付通路的转账结果后，再将支付结果回调产品系统提供的支付结果接口，以更新代付流水表中的支付状态，产品系统再通知用户交易结果。其中，调统一支付平台将内部户的钱转入到客户指定的他行银行卡上是一个异步的过程。由此可见，方案一最大的特点就是尽量同步返回代付处理过程中的交易结果，一般用于正常的个人账户转账，并发量不高，所以执行方案一时代付处理系统的整体吞吐量低下。

如图6所示，图6为本发明代付请求处理方法较佳实施例(方案二)的代付处理流程图。对比图5和图6可知：方案二与方案一的代付处理流程类似，不同的是，在代付处理过程中，方案二是由异步线程调存款核心、统一支付平台进行处理，且交易结果由请求方发起代付结果查询。虽然方案二可以很好地解决系统吞吐量低下的问题，但如果某一个或多个商户的对公账户请求量非常大时，会使得这个高并发请求商户的账户变成热点账户，即该热点账户对应的代付处理会比较慢，则会影响其他并发请求并不高的商户对应的代付请求处理速度，使得代付请求处理系统的处理效率低下。为了解决因热点账户导致处理速度慢的问题，可通过执行方案三来处理高并发情况下的代付请求，通过执行批量方案来处理超高并发情况下的代付请求。根据目标代付方案执行代付请求对应的处理流程，可在提高代付请求处理效率的同时，也提升不同并发程度的商户的支付体验。

本实施例的代付请求处理方法，当接收到代付请求时，确定对应的商户和当前代付方案，判断当前代付方案是否为批量方案；若不是批量方案，则将商户TPS与当前代付方案的TPS阈值进行比较，以确定商户的方案切换方向；判断商户的预设代付可选方案中是否存在与方案切换方向相匹配的待定可选方案；若存在，则确定目标代付方案，并将当前代付方案切换为目标代付方案；执行目标代付方案，以完成对应的代付处理流程。通过动态地对商户进行方案切换处理，将商户的当前代付方案切换到适配的目标代付方案，以及时处理不同并发程度的代付请求，提高代付请求的处理效率。

进一步地，基于本发明代付请求处理方法第一实施例，提出本发明代付请求处理方法第二实施例。

代付请求处理方法的第二实施例与代付请求处理方法的第一实施例的区别在于，所述方案切换方向为向预设TPS阈值更大的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：

步骤c1，根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更大的待定可选方案，并判断当前获取到的待定可选方案是否为预设批量方案；

步骤c2，若当前获取到的待定可选方案不为预设批量方案，则将所述商户的TPS与当前获取到的待定可选方案对应的预设TPS阈值进行比较；

步骤c3，当所述商户的TPS小于或等于当前获取到的待定可选方案对应的预设TPS阈值时，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案，若能切换，则将当前获取到的预设代付可选方案确定为所述商户的目标代付方案；

步骤c4，当所述商户的TPS大于当前获取到的待定可选方案对应的预设TPS阈值，或者不能将所述商户的当前代付方案切换为当前获取到的待定可选方案时，获取下一个预设TPS阈值更大的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。

在本实施例中，若确定将商户的当前代付方案向吞吐量更大的方案进行切换，则根据待定可选方案的吞吐量大小，逐一获取比当前代付方案吞吐量更大的方案进行判断。例如，在配置如图4所示的商户属性扩展表时，可通过两两比较的方式根据预设代付可选方案对应的TPS阈值来确定各个预设代付可选方案对应的吞吐量大小，一般来说，TPS阈值相对较大的预设代付可选方案，其对应的吞吐量也就更大；然后可按照吞吐量大小降序/升序的方式对各个预设代付可选方案进行排序。以图4中商户号为0000001的商户1为例，若预设代付可选方案是按照吞吐量降序的方式进行排序，那么，在商户属性扩展表中查询到商户1排序后的预设代付可选方案包括方案一、方案二和方案三，若商户1的当前代付方案是方案一，即商户1的当前代付方案为吞吐量最小的代付方案，不是批量方案，则可确定该商户可以切换到吞吐量更大的方案二或方案三。对于商户1来说，首先获取的待定可选方案为方案二，不是批量方案，则将商户1当前的TPS与商户1在方案二中配置的TPS阈值进行比较，若比较结果为商户1的TPS小于或等于商户1在方案二中配置的TPS阈值，由于方案二还会受到总的TPS控制，因此还需要进一步判断能否切换到方案二。若能切换到方案二，则确定当前获取到的方案二确定为商户1的目标代付方案；若比较结果为商户1的TPS大于商户1在方案二中配置的TPS阈值，或者，在进一步判断能否切换到方案二时确定不能切换到方案二，则继续获取下一个吞吐量更大的待定可选方案，即方案三，判断方案三是否为商户1的目标代付方案的过程与上述方案二的判断过程类似，此处不再赘述，但是，由于方案三是用于处理高并发代付请求情况的，所以方案三也不会受到总的TPS控制，只要商户1的TPS小于或等于商户1在方案三中配置的TPS阈值，就能将商户1的当前代付方案切换到方案三。

又例如，针对图4中商户号为0000004的商户4，在商户属性扩展表中查询到商户4排序后的预设代付可选方案包括方案二、方案三和批量方案，若商户4的当前代付方案是方案二，即商户4的当前代付方案为吞吐量最小的代付方案，则可确定该商户可以切换到吞吐量更大的方案三或者批量方案。但具体是切换到方案三还是批量方案，需要以当前实时的TPS为准。首先获取的待定可选方案为方案三，不是批量方案，则将商户4当前的TPS与商户4在方案三中配置的TPS阈值进行比较，若比较结果为当前商户4的TPS大于商户4在方案三中配置的TPS阈值，则直接将商户4的当前代付方案切换到批量方案，否则将商户4的当前代付方案切换到方案三，也即，在进行方案切换处理时，如果获取到的待定可选方案不是批量方案，则需要确定商户的TPS小于或等于哪一个待定可选方案对应的TPS阈值，且商户的TPS与待切换方案对应的TPS阈值最为接近，即确定该TPS阈值对应的预设代付可选方案为该商户对应的目标代付方案。

进一步地，所述判断当前获取到的待定可选方案是否为预设批量方案的步骤之后，还包括：

步骤d，若当前获取到的待定可选方案为预设批量方案，则将当前获取到的待定可选方案确定为所述商户的目标代付方案，并将所述商户的当前代付方案切换为所述目标代付方案。

在本实施例中，若获取到的待定可选方案是批量方案，则直接将该商户的当前代付方案切换为批量方案。以图4中商户号为0000004的商户4为例，若商户4的当前代付方案是方案三，并确定将商户4切换到吞吐量更大的代付方案，那么，对于商户4来说，首先获取的待定可选方案肯定是批量方案，不是批量方案，则直接将商户4的当前代付方案切换到批量方案，也即，将批量方案确定为商户4对应的目标代付方案。

进一步地，所述方案切换方向为向预设TPS阈值更小的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：

步骤e1，根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案；

步骤e2，若当前获取到的待定可选方案不属于所述预设的TPS总值限制方案，则将当前获取到的待定可选方案确定为所述商户的目标代付方案。

在本实施例，若确定将商户的当前代付方案向吞吐量更小的代付方案进行切换，需要根据吞吐量降序的方向，逐一获取比当前代付方案吞吐量更小的待定可选方案。但由于本实施例的方案一和方案二适用于低并发程度以及正常并发程度的代付请求处理场景，因此，方案一和方案二还会受到总的TPS控制，也即，在本实施例中，预设的TPS总值限制方案包括方案一和方案二。但是，由于本实施例的方案三和批量方案适用于处理高并发以及超高并发程度的代付请求处理场景，不受总的TPS控制，因此，若当前获取到的待定可选方案不是方案一或方案二，即可确定该商户的带钱代付方案为批量方案，且当前获取到的待定可选方案为方案三，如图4中商户号为0000006的商户6。若商户6的TPS小于或等于商户6在方案三中配置的TPS阈值，则可直接将方案三确定为商户6的目标代付方案，否则，继续维持商户6的代付方案为批量方案。

进一步地，所述判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案的步骤之后，还包括：

步骤f1，若当前获取到的待定可选方案属于所述预设的TPS总值限制方案，则根据当前获取到的待定可选方案的TPS总值和所述商户的TPS，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；

步骤f2，若能切换，则将当前获取到的待定可选方案确定为所述商户的目标代付方案；

步骤f3，若不能切换，则获取下一个预设TPS阈值更小的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。

在本实施例中，若当前获取到的待定可选方案属于预设的TPS总值限制方案，即当前获取到的待定可选方案为方案一或方案二，需要进一步判断能否将商户的当前代付方案切换到当前获取到的待定可选方案，若能切换，则将当前获取到的待定可选方案确定为商户的目标代付方案，若不能切换，则继续获取下一个吞吐量更小的待定可选方案，并重复上述切换判断流程。例如，方案一的TPS总值为300，若商户A、商户B、商户C、商户D、商户E、商户F和商户G的当前代付方案为方案一，且这7个商户的当前TPS数值均为40，那么，此时方案一的TPS总值是7*40＝280，小于方案一的TPS总值300。但此时，如果系统中的商户X当前代付方案是方案二，但在某一瞬间，商户X的TPS数值降到了30，小于商户X在方案一配置的TPS阈值45，从商户X的角度来看，是可以将商户X切换到方案一的，但此时，如果将商户X切换到方案一，那么，方案一的TPS总值就会从280变成310(280+30)，大于方案一预先设置好的TPS总值300，所以，商户X暂时不能切换到方案一，即商户X的当前代付方案继续维持为方案二。若商户Y的当前代付方案为方案三，待定可选方案包括方案一和方案二，且商户Y的当前TPS小于其在方案一配置的TPS阈值，当确定商户Y不能切换到方案二之后，会继续获取方案一，以确定商户Y能否切换到方案一；由于当前获取到的方案一为商户Y待定可选方案列表中的最后一个，若确定不能将方案一确定为商户Y的目标代付方案，则确定商户Y维持当前代付方案，即维持方案三。

本实施例的代付请求处理方法，在对商户进行方案切换处理时，依次判断否将商户的当前代付方案切换到每一个待定可选方案，以将商户的当前代付方案切换到适配的预设代付可选方案，尽可能地保证商户对应的代付请求能被及时处理，从而提高代付请求处理系统的处理效率。

进一步地，基于本发明代付请求处理方法第一、第二实施例，提出本发明代付请求处理方法第三实施例。

代付请求处理方法的第三实施例与代付请求处理方法的第一、第二实施例的区别在于，判断所述商户的当前代付方案是否为预设批量方案的步骤之后，还包括：

步骤g1，若当前代付方案是预设批量方案，则获取所述商户的预设代付可选方案，并从所述商户的预设代付可选方案中筛选出比当前代付方案对应的预设TPS阈值更小的待定可选方案；

步骤g2，根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；

步骤g3，若能切换为当前获取到的待定可选方案，则将当前获取到的代付可选方案确定为所述商户的目标代付方案；

步骤g4，若不能切换为任一待定可选方案，则维持所述商户的当前代付方案。

在本实施例中，如图7所示，在对商户进行方案切换处理时，先通过查询预设商户配置表确定当前商户是否可动态切换方案；若不能动态切换方案，则确定商户的当前代付方案保持不变；若可动态切换方案，则判断当前商户的当前代付方案是否为批量方案，由于批量方案没有对应的TPS阈值，若当前商户的当前代付方案是批量方案，则确定该商户只能往吞吐量更小的方案进行切换，具体的切换流程可参考第二实施例中向吞吐量更小的方案机械能切换的切换判断过程，此处不再赘述，且如果确定该商户不能切换至任一吞吐量更小的待定可选方案，则确定该商户的代付方案继续维持为批量方案。若当前代付方案不是批量方案，则判断该商户的TPS是否超过了当前代付方案的TPS上限阈值；若当前商户的TPS超过当前代付方案的TPS上限阈值，则查询预设的商户属性扩展表，获得当前商户的预设代付可选方案列表，并查询是否存在比当前商户TPS阈值大的待定可选方案；若不存在，即说明该商户的当前代付方案为当前吞吐量最大的预设代付可选方案，则保持当前代付方案不变；若存在比当前代付方案吞吐量更大的预设代付可选方案，则获取下一个吞吐量更大的预设代付可选方案A；由于在本实施例中，批量方案对应的吞吐量最大，因此，若A为批量方案，则可直接将该商户的当前代付方案切换为批量方案；若A不是批量方案，则需要评估能否将该商户的当前代付方案切换为A，即判断如果将当前代付方案切换为A后，当前的TPS是否还小于或等于A对应的TPS总值；若当前的TPS还小于或等于A对应的TPS总值，则将该商户的当前代付方案切换为A；若当前的TPS大于A对应的TPS阈值，则继续获取下一个吞吐量更大的待定可选方案B，基于上述类似的评估过程，确定能否将该商户的当前代付方案切换为B，以此类推，直到将该商户的当前代付方案切换为最适配的预设代付可选方案。否则，该商户的当前代付方案保持不变。

而若当前商户的TPS不超过当前代付方案的TPS上限阈值，则进一步检测当前商户的TPS是否小于或等于吞吐量更小的待定可选方案对应的TPS阈值；若小于或等于，则按照排序后的待定可选方案获取下一个吞吐量更小的待定可选方案C，并判断C是否为方案一或方案二；若C为方案一或方案二，则需要评估能否将该商户的当前代付方案切换为C，即判断如果将当前代付方案切换为C后，当前的TPS是否会超过C对应的TPS总值；若当前的TPS不会超过C对应的TPS总值，则将该商户的当前代付方案切换为C；若当前的TPS超过C对应的TPS总值，则继续从排序后的待定可选方案中获取下一个吞吐量更小的待定可选方案D，基于上述类似的评估过程，确定能否将该商户的当前代付方案切换为D，以此类推，直到将该商户的当前代付方案切换为最适配的预设代付可选方案。否则，该商户的当前代付方案保持不变。

另外，若当前商户的TPS小于或等于另一待定可选方案对应的TPS阈值，但该商户未能进行方案切换处理时，还可设置轮询检测机制，在到达预设轮询时间时，再次检查该商户能否切换到相应的待定可选方案，例如，可判断该商户距离上次预切换方案但实际未能进行方案切换处理的时间是否超过了预设方案切换间隔，若超过了预设方案切换间隔，则执行方案切换处理流程。通过轮训机制查询商户是否可进行方案切换处理，可以提高代付请求处理系统的灵活性，并进一步提高代付请求处理系统的处理效率。

本实施例的代付请求处理方法，若商户的当前代付方案为批量方案，则想吞吐量更大的方案进行切换，以确定该商户的最适配代付方案，在保证代付请求处理系统稳定性的同时，也可以提高代付请求的处理效率。

进一步地，基于本发明代付请求处理方法第一、第二、第三实施例，提出本发明代付请求处理方法第四实施例。

代付请求处理方法的第四实施例与代付请求处理方法的第一、第二、第三实施例的区别在于，应用于代付请求处理系统，代付请求处理系统包括存款核心，步骤S50还包括：

步骤h1，对所述代付请求对应的代付流水进行状态初始化处理，以将所述代付流水的当前处理状态初始化为预设初始处理状态；

步骤h2，将所述代付流水存储至预设数据库，并将所述代付流水对应的请求信息发送给所述商户对应的消息队列；

步骤h3，通过所述消息队列对应的监听线程从所述预设数据库中取出所述代付流水，并将所述代付流水发往所述存款核心，以供所述存款核心根据所述目标代付方案对所述代付流水进行代付处理，以完成所述代付请求对应的处理流程。

在本实施例中，通过设置消息队列来将高并发商户的代付请求隔离出来。对代付请求对应的代付流水进行状态初始化处理，可以减少后续组装请求数据时的入库处理动作，使得组装请求的效率更高。如图8所示，图8为本发明代付请求处理方法较佳实施例(方案三)对应的代付处理流程图。由于在方案三中会为每个商户都配置一个消息队列，消息队列可包括RocketMQ、ActiveMQ、RibbitMQ等，因此，若确定商户当前运行的代付方案为方案三，对代付请求对应的代付流水进行状态初始化处理时，可将代付流水的当前处理状态初始化为“I-待处理”，预设数据库优选为代付流水表，在代付请求组装入库到代付流水表后，将代付请求对应的请求消息发送给该商户对应的消息队列，其中，请求信息可包括该代付请求对应的唯一标识、代付请求对应的报文等信息。当该消息队列对应的监听线程接收到消息队列的消息时，返回接收成功的响应，并组装代付请求发往存款核心，由存款核心进行后续的代付处理，存款核心进行的代付处理过程与方案一和方案二的类似，此处不再赘述。在方案三中，通过为每个高并发的商户设置一个对应的消息队列，以将高并发的代付请求隔离出来，保证其他不是高并发商户的代付请求能被及时处理，从而提高非高并发商户代付请求的处理能力。

进一步地，代付请求处理系统包括预设兜底任务线程，所述将所述代付流水存储至预设数据库的步骤之后，还包括：

步骤i1，通过所述预设兜底任务线程判断所述预设数据库中是否存在超过预设等待处理时间的目标代付流水；

步骤i2，若存在，则通过预设兜底任务线程从所述预设数据库中取出所述目标代付流水，并将所述目标代付流水发往所述存款核心，以供所述存款核心对所述目标代付流水进行代付处理。

在本实施例中，可通过实时或定时的兜底任务来保证消息队列中的消息不会丢失，可以理解的，由于消息队列可以是专门的消息中间件，也可以是简单的内存消息队列等，但这些消息队列不能完全保证消息不会丢失，因此，为了保证不丢失消息队列中的消息，需要设置一个兜底任务线程来扫描预设数据库，其中，兜底任务优选为兜底定时任务；预设数据库可以是代付流水表或者一对一转账流水表，预设数据库可根据该商户当前运行的代付方案对应的并发程度来决定，例如，若当前的目标代付方案为方案三，由于在执行方案三时，代付请求是入库到代付流水表中，因此，可通过兜底定时任务线程扫描代付流水表来查询超过预设等待处理时间的目标代付流水；若当前的目标的代付方案为批量方案，由于在执行批量方案时，代付请求除了入库到代付流水表外，还入库到一对一转账流水表中，但是后续组装代付请求发往存款核心时，可直接从一对一转账流水表获取代付流水，因此，在执行批量方案时，兜底定时任务线程可通过扫描一对一转账流水表来查询超过预设等待处理时间的目标代付流水，然后通过兜底任务线程将取出的目标代付流水发往存款核心，以供存款核心对该目标代付流水进行后续的代付处理。通过兜底任务来兜住超过预设等待处理时间的代付流水，有利于提高系统的健壮性。

本实施例的代付请求处理方法，可通过为每一个高并发的商户设置一个对应的消息队列，以将高并发的代付请求隔离出来，保证其他不是高并发商户的代付请求能被及时处理，提高非高并发商户代付请求的处理能力；也可以通过预设兜底任务线程查询并处理预设数据库中超过预设等待处理时间的目标代付请求，保证消息队列中的消息不会丢失，有利于提高系统的健壮性。

进一步地，基于本发明代付请求处理方法第一、第二、第三、第四实施例，提出本发明代付请求处理方法第五实施例。

代付请求处理方法的第五实施例与代付请求处理方法的第一、第二、第三、第四实施例的区别在于，所述方法还包括：

步骤j1，从所述预设数据库中取出当前处理状态为预设初始处理状态的待处理代付流水，并对所述待处理代付流水进行代付处理，得到对应的代付处理状态；

步骤j2，将所述待处理代付流水的当前处理状态更新为所述代付处理状态；

步骤j3，当所述预设数据库中的代付流水对应的代付处理状态均为预设处理完成状态时，则将处理完成后的待处理代付流水发往所述存款核心，以供所述存款核心对所述处理完成后的待处理代付流水进行代付处理。

在本实施例中，在处理高并发代付请求时，通过兜底任务线程扫描预设数据库，可能会存在监听消息队列的线程和兜底任务的线程，或者是异常情况下两个监听线程同时处理同一笔代付流水的问题，因此，通过监听线程或兜底任务线程从预设数据库中取出每一笔代付流水进行处理时需要进行并发控制，以保证高并发情况下代付请求的处理效率，另外，由于不同代付方案对应的并发情况不同，因此，针对不同并发程度的高并发代付方案，可采用不同的并发控制措施。在处理每一笔代付流水时，可根据代付流水表对应的主键来获取待处理的代付流水，其中，主键即主关键字(primary key)，可以根据主键来唯一确定代付流水表中的一行数据，即一笔代付流水。

如图9所示，图9为本发明代付请求处理方法较佳实施例(方案三)的并发控制流程图。通过方案三进行代付处理时，通过在代付流水表上新增一个字段concurrent_status来进行并发控制，假设代付流水的初始处理状态是“I-待处理”，通过状态扭转来进行并发控制时，具体的，可通过查询concurrent_status状态为“I-待处理”的代付流水列表，再从查询到的代付流水列表中按照时间先后顺序依次取出对应的代付流水来组装一对一转账流水，并更新当前处理的代付流水的concurrent_status状态为“P-处理中”；在检测到当前处理的代付流水的concurrent_status状态成功更新为“P-处理中”后，将组装的一对一转账流水发送给存款核心，然后将该代付流水的concurrent_status状态更新为“S-已处理”；在更新成功后，检测当前处理的代付流水是否为代付流水列表中的最后一个；若当前处理的代付流水为代付流水列表中的最后一个，则结束该笔代付流水的并发控制流程；若当前处理的代付流水不是代付流水列表的最后一个，则继续从查询到的代付流水列表中按照时间先后顺序依次取出对应的代付流水来组装一对一转账流水，按照上述的并发控制流程来更新代付流水的concurrent_status状态，直到更新完代付流水列表中所有代付流水的代付处理状态，即当检测到预设数据库中的代付流水对应的代付处理状态均为预设处理完成状态时，则可结束预设数据库中的代付流水对应的处理状态更新流程，并将处理完成后的代付流水发往存款核心，以供存款核心对处理完成后的代付流水进行后续的代付处理。

如图11所示，图11为本发明代付请求处理方法较佳实施例(批量方案)的并发控制流程图。与方案三不同的是，利用批量方案进行并发控制时，查询的是一对一转账流水列表，具体的，根据商户号、批次号查询批次状态为“02-已打标”的一对一转账流水列表，从查询到的一对一转账流水列表中依次取出代付流水组装一对一转账流水，然后根据查询到的一对一转账流水的逐渐将一对一转账流水的批次状态更新为“03-组装中”；在更新成功后，将当前的一对一转账流水数据组装到核心批量请求报文中，然后更新当前处理的代付流水的批次状态为“04-已组装”，根据上述的并发控制流程依次处理一对一转账流水列表中的代付流水，直到一对一转账代付流水列表中的代付流水的代付处理状态全部更新完毕，则将组装好的这一批代付流水发往存款核心，然后将这一批次的一对一转账流水的批次状态更新为“05-已处理”，也即，当检测到预设数据库中的代付流水对应的代付处理状态均为预设处理完成状态时，则结束该预设数据库中的代付流水对应的处理状态更新流程，从而完成这一批次代付流水的并发控制流程。

本实施例的代付请求处理方法，在处理高并发代付请求时，通过更新代付流水的代付处理状态来进行并发控制，可提高代付请求处理系统的稳定性，保证系统的代付请求处理效率。

进一步地，基于本发明代付请求处理方法第一、第二、第三、第四、第五实施例，提出本发明代付请求处理方法第六实施例。

代付请求处理方法的第六实施例与代付请求处理方法的第一、第二、第三、第四、第五实施例的区别在于，所述目标代付方案为预设批量方案，所述将所述代付流水存储至预设数据库的步骤之后，还包括：

步骤k1，从所述预设数据库中查询当前处理状态为预设初始处理状态的批量代付流水，并生成所述批量代付流水对应的统一批次号；

步骤k2，获取所述批量代付流水中的商户号，将所述统一批次号和所述商户号发送给预设目标消息队列；

步骤k3，通过所述预设目标消息队列对应的监听线程根据所述统一批次号和所述商户号从所述预设数据库取出所述批量代付流水，并组装所述批量流水对应的批量请求发往所述存款核心，以供所述存款核心根据所述批量请求对所述批量代付流水进行代付处理。

在本实施例中，如图10所示，图10为本发明代付请求处理方法较佳实施例(批量方案)的代付处理流程图。与方案三不同的是，批量方案中的所有商户共用同一个消息队列。如果检测到商户当前的代付方案为批量方案，在代付请求校验成功后，直接将代付请求入库到代付流水表、一对一转账流水表，并初始化发往存款核心的一对一转账流水表，以将这一批一对一转账流水表中的batch_status状态初始化为“01-待打标”，然后通过兜底定时任务扫描一对一转账流水表，获取batch_status状态为“待打标”的代付流水，也可预先设置每次获取的流水记录数，如每次最多获取30条代付流水记录数，生成一个唯一的处理编号batch_no，并将代付流水的batch_status状态更新为“02-已打标”，以将这一批一对一转账流水的batch_no更新为同一个唯一的批次号，即统一批次号，然后将商户号、batch_no发到消息队列中，当监听消息队列的线程接收到消息队列的消息时，取出消息队列中的商户号、batch_no，根据商户号、batch_no查询一对一转账流水表，将这批一对一转账流水取出，循环组装批量请求报文发送给存款核心，由存款核心，或由存款核心和统一支付平台处理完成后得到对应的处理结果，然后基于上述的处理流程循环处理一对一转账流水，从而批量完成一对一转账流水的代付处理流程。存款核心的代付处理流程与上述的类似，此处不再赘述。

本实施例的代付请求处理方法，通过批量方案从商户的维度来组装批量代付请求，且批量方案中的一个或多个商户共用同一个消息队列，不仅可以将TPS比较大的商户的代付请求隔离出来，还可以提高超高并发商户的代付请求组处理速度。

本发明还提供一种代付请求处理装置。参照图12，本发明代付请求处理装置包括：

第一判断模块10，用于当接收到代付请求时，确定所述代付请求对应的商户，以及所述商户的当前代付方案，并判断所述商户的当前代付方案是否为预设批量方案；

比较确定模块20，用于若当前代付方案不是预设批量方案，则将所述商户的TPS与当前代付方案对应的预设TPS阈值进行比较，并根据比较结果确定所述商户的方案切换方向，所述商户的TPS为单位时间内处理的所述商户的代付请求数；

第二判断模块30，用于获取所述商户的预设代付可选方案，并判断所述预设代付可选方案中是否存在与所述方案切换方向相匹配的待定可选方案；

方案切换模块40，用于若存在，则从所述待定可选方案中确定所述商户的目标代付方案，并将所述商户的当前代付方案切换为所述目标代付方案；

代付执行模块50，用于执行所述目标代付方案，以完成所述代付请求对应的处理流程。

优选地，所述比较确定模块还用于：

优选地，所述方案切换模块还用于：

优选地，所述方案切换模块还包括总值判断单元，所述总值判断单元用于：

优选地，所述第一判断模块还包括批量方案判断单元，所述批量方案判断用于：

优选地，所述代付请求处理装置还包括存款核心，所述代付执行模块用于：

优选地，所述代付请求处理装置还包括并发控制模块，所述并发控制模块用于：

优选地，所述代付执行模块还包括批量代付单元，所述批量代付单元用于：

本发明还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上所述的代付请求处理方法的步骤。

本发明还提供一种存储介质。

本发明存储介质上存储有代付请求处理程序，所述代付请求处理程序被处理器执行时实现如上所述的代付请求处理方法的步骤。

其中，本发明代付请求处理系统、计算机程序产品和存储介质的各实施例，均可参照本发明代付请求处理方法各个实施例，此处不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端系统(可以是手机，计算机，服务器，空调器，或者网络系统等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书与附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims

1.一种代付请求处理方法，其特征在于，所述方法包括如下步骤：

2.如权利要求1所述的代付请求处理方法，其特征在于，所述根据比较结果确定所述商户的方案切换方向的步骤包括：

3.如权利要求2所述的代付请求处理方法，其特征在于，所述方案切换方向为向预设TPS阈值更大的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：

4.如权利要求2所述的代付请求处理方法，其特征在于，所述方案切换方向为向预设TPS阈值更小的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：

5.如权利要求4所述的代付请求处理方法，其特征在于，所述判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案的步骤之后，还包括：

6.如权利要求1所述的代付请求处理方法，其特征在于，所述判断所述商户的当前代付方案是否为预设批量方案的步骤之后，还包括：

7.如权利要求1所述的代付请求处理方法，其特征在于，应用于代付请求处理系统，所述代付请求处理系统包括存款核心，所述执行所述目标代付方案，以完成所述代付请求对应的处理流程的步骤包括：

8.如权利要求7所述的代付请求处理方法，其特征在于，所述方法还包括：

9.如权利要求7所述的代付请求处理方法，其特征在于，所述目标代付方案为预设批量方案，所述将所述代付流水存储至预设数据库的步骤之后，还包括：

10.一种代付请求处理系统，其特征在于，所述代付请求处理系统包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的代付请求处理程序，所述代付请求处理程序被所述处理器执行时实现如权利要求1至9中任一项所述的代付请求处理方法的步骤。