CN110033246A - 网络支付限流控制方法和装置 - Google Patents

Abstract

本发明提供了一种支付控制方法，包括：接收来自多个用户的交易请求，每个交易请求包括发送该交易请求的用户的ID；使第一阈值数目的交易请求通过第一限流节点；根据所述用户的ID确定与通过所述第一限流节点的每个交易请求相关的主支付工具并且确定该主支付工具为空闲支付工具还是超载支付工具；向主支付工具为超载支付工具的用户的子集推荐空闲支付工具；以及在第二限流节点处针对每种支付工具对交易请求进行限流。

Description

网络支付限流控制方法和装置

技术领域

本发明主要涉及互联网应用技术领域，尤其涉及一种网络支付限流控制方法和装置。

背景技术

随着经济和网络技术的快速发展，网络购物成为消费者的主要购物渠道之一，用于网络交易的支付工具也越来越多，如签约的快捷银行卡、余额宝、花呗等，使得付款方和收款方之间的交易更加方便、快捷。

目前在应对交易支付高峰方面，支付链路有两个关键节点：收银环节的整体支付容量限流和进入支付环节之后的分支付工具容量限流。

但由于各主支付工具容量和用户使用习惯的分布不均衡，造成以下问题：首先，有些支付工具容量超过负荷，使得大量用户支付超时或失败，而另外一些支付工具容量没有被充分利用，造成容量浪费。其次，进入支付环节后用户再被限流导致支付失败，用户还要退回收银环节选择其他支付工具进行支付，影响用户体验。

因此，亟需解决以上问题的支付限流控制方案。

发明内容

本发明要解决的技术问题是提供一种高效的支付限流方法，充分利用各种支付工具资源，并且提升支付的顺畅度。

为解决上述技术问题，本发明提供了一种支付控制方法，包括：

接收来自多个用户的交易请求，每个交易请求包括发送该交易请求的用户的ID；

使第一阈值数目的交易请求通过第一限流节点；

根据所述用户的ID确定与通过所述第一限流节点的每个交易请求相关的主支付工具并且确定该主支付工具为空闲支付工具还是超载支付工具；

向主支付工具为超载支付工具的用户的子集推荐空闲支付工具；以及

在第二限流节点处针对每种支付工具对交易请求进行限流。

可任选地，该方法进一步包括，

确定与每种支付工具相关的交易请求的总数；以及

将与每种支付工具相关的交易请求的总数与该支付工具的预设目标值进行比较以确定该支付工具是空闲支付工具还是超载支付工具。

可任选地，该方法进一步包括，如果与支付工具相关的交易请求的总数低于该支付工具的预设目标值，则确定该支付工具为空闲支付工具。

可任选地，该方法进一步包括，如果与支付工具相关的交易请求的总数高于该支付工具的预设目标值，则确定该支付工具为超载支付工具。

可任选地，所述预设目标值是根据每种支付工具的容量变化来实时更新的。

可任选地，所述预设目标值是根据所述第二限流节点处针对每种支付工具设置的容量阈值来确定的。

可任选地，被推荐空闲支付工具的用户的子集是根据用户使用习惯和/或历史支付成功率来选择的。

可任选地，该方法进一步包括，将通过所述第二限流节点的交易请求发送到支付链路。

本发明的另一方面提供了一种支付控制装置，包括：

接收模块，其被配置成接收来自多个用户的交易请求，每个交易请求包括发送该交易请求的用户的ID；

第一限流模块，其被配置成：

使第一阈值数目的交易请求通过第一限流节点；

根据所述用户的ID确定与通过所述第一限流节点的每个交易请求相关的

主支付工具并且确定该主支付工具为空闲支付工具还是超载支付工具；以及向主支付工具为超载支付工具的用户的子集推荐空闲支付工具；以及

第二限流模块，其被配置成在第二限流节点处针对每种支付工具对交易请求进行限流。

可任选地，所述第一限流模块被进一步配置成，基于与每种支付工具相关的交易请求的总数来确定该支付工具是空闲支付工具还是超载支付工具。

可任选地，所述第一限流模块被进一步配置成：如果与支付工具相关的交易请求的总数低于该支付工具的预设目标值，则确定该支付工具为空闲支付工具。

可任选地，所述第一限流模块被进一步配置成：如果与支付工具相关的交易请求的总数高于该支付工具的预设目标值，则确定该支付工具为超载支付工具。

可任选地，所述预设目标值是根据每种支付工具的容量变化来实时更新的。

可任选地，所述预设目标值是根据所述第二限流节点处针对每种支付工具设置的容量阈值来确定的。

可任选地，被推荐空闲支付工具的用户的子集是根据用户使用习惯和/或历史支付成功率来选择的。

可任选地，该装置进一步包括传送模块，其被配置成将通过所述第二限流节点的交易请求发送到支付链路。

本发明的又一方面提供了一种支付控制装置，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

接收来自多个用户的交易请求，每个交易请求包括发送该交易请求的用

户的ID；

使第一阈值数目的交易请求通过第一限流节点；

根据所述用户的ID确定与通过所述第一限流节点的每个交易请求相关的

主支付工具并且确定该主支付工具为空闲支付工具还是超载支付工具；

向主支付工具为超载支付工具的用户的子集推荐空闲支付工具；以及

在第二限流节点处针对每种支付工具对交易请求进行限流。

在现有技术中，因收银环节仅进行整体支付容量限流，导致在大流量支付峰值时，各支付工具容量不能被充分利用。

本发明在收银环节加入了前置支付工具粒度限流，并向用户推荐空闲支付工具，从而能够充分利用各种支付工具。本发明还感知下游支付工具容量变化情况(例如，银行卡异常，银行卡渠道的容量会缩小)，并选择出最适合被限流和推荐其他支付工具的用户，提升用户支付成功率并且降低用户切换率，保障用户支付顺畅。

附图说明

图1是支付链路限流的示意图。

图2是现有技术中进入支付链路的流程图。

图3解说了现有技术中的支付链路限流的一个示例。

图4解说了根据本发明的各方面的支付链路限流的示例。

图5示出了向用户推荐使用支付工具的界面示图。

图6解说了根据本发明的支付工具限流方法的流程图。

图7是根据本发明的用于支付工具限流方法的流程图。

图8是根据本发明的用于支付工具限流方法的装置的框图。

具体实施方式

为让本发明的上述目的、特征和优点能更明显易懂，以下结合附图对本发明的具体实施方式作详细说明。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是本发明还可以采用其它不同于在此描述的其它方式来实施，因此本发明不受下面公开的具体实施例的限制。

在网络支付中，用户的支付是否顺畅有两个衡量指标：支付成功率和用户支付工具切换率。

支付成功率是支付成功数与支付请求数的比率。用户支付工具切换率是用户切换支付工具的支付数与支付请求数之比。一般而言，支付成功率越高、用户支付工具切换率越低，支付的顺畅度越高。

本申请旨在提供一种在整体支付容量不足的情况下提升支付顺畅度的方法。

图1是支付链路容量限流方案的示意图，图2是现有技术中支付链路限流过程的流程图。

如图1和2所示，支付链路有两个环节：收银环节和支付环节。

具体而言，在用户发起交易请求(本文也被称为支付请求)(例如，点击淘宝的“确认购买/提交订单”按钮)之后，可进入收银环节。在收银环节，应用跳出收银台界面，收银台界面显示数种支付工具，提示用户选择其中一种支付工具进行支付。替换地，收银台界面也可显示默认支付工具和选择其它支付工具的入口。用户确定要用于支付的支付工具并且点击“确认支付”按钮之后，进入支付环节。

相应地，支付链路上的交易请求容量限流分为以下两个节点：

第一个节点是收银环节限流，也被称为整体限流，其针对整体交易请求流量进行限流，保护整个支付链路。在交易峰值时，交易请求总数会大于支付通道的总容量。收银环节限流允许小于或等于支付通道总容量的数量的交易请求进入收银环节，其它被限流的交易请求排队等待进入收银环节。整体限流一般按照接收到交易请求的时间进行限流，较晚接收到的请求更有可能被限流。因此无法控制整体限流中被限流请求的支付工具。

第二个节点是支付环节限流(也称为分支付工具限流)。进入支付环节后，系统根据各种支付工具容量分别进行限流。具体而言，针对每种支付工具设置一容量阈值，如果选择该支付工具的用户数量大于该容量阈值，则系统仅允许等于该容量阈值的数量的交易请求进入支付，其它交易请求排队等待。

在一些示例中，排队等待超过阈值时间，则交易失败。

图3解说了现有技术中的支付链路限流的一个示例。

如图3所示，交易中可使用四种支付工具A、B、C和D，这些支付工具可以例如是银行卡、花呗、余额宝、支付宝余额等等。

这些交易请求包括6万个使用支付工具A的请求、6万个使用支付工具B的请求、2万个使用支付工具C的请求以及2万个使用支付工具D的请求。请注意，这里每个请求所对应的支付工具是系统按照该请求的用户的设置和/或支付习惯等确定的默认支付工具。例如，通常在收银台界面上显示为默认支付工具，或者在支付工具列表中排在第一位。即，在请求交易的用户中，有6万个用户默认使用支付工具A，6万个用户默认使用支付工具B，2万个用户默认使用支付工具C，以及2万个用户默认使用支付工具D。为了简化起见，这些请求在本文中分别也被称为支付工具A请求、支付工具B请求、支付工具C请求和支付工具D请求。应认识到，这里给出的数量仅仅是示例性的，并不作为限定。

在图3的示例中，收银环节的整体容量限制为8万。经过收银环节的容量限流之后，3万种支付工具A请求、3万种支付工具B请求、1万种支付工具C请求以及1万种支付工具D请求通过限流，进入支付环节。剩余的交易请求排队等待通过收银环节限流。

在支付环节限流中，对各种支付工具容量分别进行限流。如图3所示，支付环节中针对工具A、B、C和D定义的容量阈值分别为2万、4万、1万和1万。通过收银环节限流的支付工具A请求的数量(3万)大于支付环节对工具A定义的容量阈值(2万)，由此剩下一万笔支付工具A请求需要在支付环节排队，造成了这些用户支付超时或失败。而通过收银环节限流的支付工具B请求的数量(3万)比支付环节对工具A定义的容量阈值(4万)少一万，由此导致1万个的支付工具B容量未被利用，造成了资源浪费。由此可见，现有技术支付工具限流分配导致了资源分配的不均衡。

针对以上问题，本发明提出了一种在整体支付容量不足的情况下提升支付顺畅度的方法。具体而言，在收银环节限流中，在整体限流的基础上加入分支付工具限流和支付工具推荐。例如，系统根据每种支付工具的容量，在整体容量满足限额的基础上，灵活调整各种支付工具的占比分配。这可以通过向默认支付工具超载的用户推荐下游支付较顺畅的支付工具来达成。例如，引导用户使用支付成功率更高的较空闲的支付工具，由此提高用户整体支付成功率并降低用户支付工具切换率，并使得资源能够被高效利用。

图4解说了根据本发明的各方面的支付链路限流的示例。

如图4所示，收银环节可被分为两个阶段。在第一阶段，对支付请求进行整体限流，与图3中所示的相同。

与现有技术不同之处在于，本发明在收银环节添加了第二阶段，在第二阶段为每种支付工具分别设置一目标值，该目标值可以根据后续支付环节限流中为该支付工具设置的容量阈值来设置，并且每种支付工具的目标值之和满足(即，小于等于)收银环节的整体容量值。

为了解说方便起见，在本示例中，收银环节第二阶段为每种支付工具设置的目标值与支付环节为每种支付工具设置的容量阈值相同，但收银环节为每种支付工具设置的目标值与支付环节为每种支付工具设置的容量阈值也可以不同。举例而言，在收银环节的整体容量更大的情况下，收银环节的目标值也可以大于支付环节的容量阈值，例如，收银环节的目标值可以为支付环节的容量阈值的按比例缩放。

进一步，收银环节第二阶段为每种支付工具设置的目标值可以动态调整。系统可以感知下游各支付工具的容量变化情况。例如，银行渠道异常抖动会导致银行容量变小，由此使得支付环节限流节点为银行卡设置的容量阈值降低。在这种情况下，可以相应地降低收银环节中针对银行卡设置的目标值。

如图4所示，交易请求中有6万种支付工具A请求、6万种支付工具B请求、2万种支付工具C请求以及2万种支付工具D请求。

经过收银环节第一阶段的整体容量限流之后，3万种支付工具A请求、3万种支付工具B请求、1万种支付工具C请求以及1万种支付工具D请求通过限流，进入收银环节的第二阶段，与图3中所示的相同。

在该示例中，收银环节第二阶段对四种支付工具分别设置目标值2万、4万、1万和1万。由此可见，支付工具A请求(3万)比支付工具A目标值(2万)多1万，而支付工具B请求(3万)比支付工具B目标值(4万)少1万。

系统由此可确定支付工具A为超载的支付工具，而支付工具B为比较空闲的支付工具。系统可进一步确定将向支付工具A的一些用户推荐支付工具B。

在收银环节的第二阶段，系统根据各种推荐算法在3万支付工具A的用户中选择1万用户，向这些用户推荐使用较空闲的支付工具B。该推荐算法例如可以考虑到用户习惯、历史支付成功率、已等待时间，等等。

图5示出了向用户推荐使用支付工具的界面图。优选地，向用户推荐支付工具的界面图可以显示预计排队等候时间以供用户考虑是否要切换。

在理想情况下，经过收银环节的推荐步骤之后，1万个使用支付工具A的用户改为选择使用支付工具B进行支付。作为结果，最终通过收银环节限流的是2万种支付工具A请求、4万种支付工具B请求、1万种支付工具C请求以及1万种支付工具D请求，进入支付环节。在支付环节限流中，消除了限流排队，总体支付数量与现有技术相比提高了1万。

关于支付工具推荐，系统可以根据用户支付习惯、历史支付成功率、已等待时间等因素来决定在使用超载支付工具的用户中选择哪些用户来推荐其他空闲的支付工具，由此降低用户支付工具切换率。

例如，系统可以在默认使用支付工具A的用户中向使用支付工具B频度较高的用户推荐使用支付工具B，从而可以提高推荐的成功率。替换地，系统可以根据用户支付的历史成功率来向用户推荐支付工具，例如，有些用户使用银行卡的成功率较高(例如，银行卡上的余额比较充足)，则可以向这些用户推荐使用银行卡。

请注意，虽然图4和图5的示例中仅仅示出了推荐一种支付工具的示例，但在两种或更多种以上支付工具较空闲的情况下，也可以向用户推荐两种或更多种的支付工具，推荐的顺序可以参照用户支付习惯或者用户支付的历史成功率。

通过收银环节的支付请求进入支付环节，支付环节为每种支付工具定义一个容量阈值，该容量阈值可根据下游支付工具容量变化来确定。收银环节限流针对每种支付工具对交易请求进行限流，允许小于或等于该支付工具的容量阈值的支付请求通过，进入支付链路，超出容量阈值的支付请求需要排队等待。

图6解说了根据本发明的各方面的支付工具限流方法的流程图。

在步骤601，接收来自多个用户的交易请求，这些交易请求中至少包括请求交易的用户身份(ID)。

在步骤602，根据第一限流节点(例如，收银环节限流节点)的要求对这些交易请求进行整体限流。

例如，步骤602可对应于上述收银环节的第一阶段。

具体而言，可限定在第一限流节点中仅能通过某一阈值数量的交易请求。其余的交易请求需要排队等候通过第一限流节点。

在步骤603，根据用户ID确定与通过整体限流的每个请求的用户相关的主支付工具。

该主支付工具可以是系统中存储的用户使用的默认支付工具。具体而言，系统可以为每个用户存储其对应的默认支付工具，该默认支付工具可以是用户自己设置的，也可以是系统根据用户支付习惯确定的。系统可以根据用户ID在其存储器中进行查找以确定该用户的默认支付工具。

在步骤604，统计每种支付工具所对应的交易请求的数目。

在步骤605，根据第二限流节点(例如，支付环节限流节点)为每种支付工具设置的容量阈值来设置第一限流节点中对应支付工具的目标值。

该目标值可以根据后续支付环节限流中为该支付工具设置的容量阈值来设置，并且每种支付工具的目标值之和满足(即，小于等于)收银环节的整体容量值。

在步骤606，将每种支付工具的交易请求数量与该支付工具的目标值进行比较，以确定超载支付工具和空闲支付工具。

例如，交易请求数据量大于目标值的支付工具被确定为超载支付工具，而交易请求数据量小于目标值的支付工具被确定为空闲支付工具。

在步骤607，向与超载支付工具相关的用户推荐使用空闲支付工具。

如图6所示，可在用户的手机界面上提示用户使用支付成功率较高的支付工具。

在步骤608，在第二限流节点针对每种支付工具对交易请求进行限流。

步骤603－608可对应于上述收银环节的第二阶段。

在步骤609，将通过第二限流节点的交易请求发送到支付链路。

第二限流节点(例如，支付环节限流节点)为每种支付工具设置一容量阈值。该容量阈值可根据下游支付工具容量变化来动态调整。第二限流节点针对每种支付工具进行限流，允许小于或等于该支付工具的容量阈值的支付请求通过，进入支付链路，超出容量阈值的支付请求需要排队等待。

请注意，以上按照特定次序描述了流程图，但这些步骤的次序也可交换。例如，步骤605中的设置每种支付工具的目标值也可以在步骤601、602、603和604中的任一者前面。

图7示出了根据本发明的各方面的支付工具限流方法的流程图。

在步骤701，接收来自多个用户的交易请求。

在步骤702，使第一阈值数目的交易请求通过第一限流节点。

在步骤703，确定与通过第一限流节点的每个交易请求相关的支付工具。

在步骤704，确定与通过第一限流节点的每个交易请求相关的主支付工具为空闲支付工具还是超载支付工具。

例如，如果与支付工具相关的交易请求的数量低于该支付工具的预设目标值，则确定该支付工具为空闲支付工具，如果与支付工具相关的交易请求的数量高于该支付工具的预设目标值，则确定该支付工具为超载支付工具。所述预设目标值可以根据所述第二限流节点处针对每种支付工具设置的容量阈值来确定并且可以根据每种支付工具的容量变化来实时更新。

在步骤705，向主支付工具为超载支付工具的用户的子集推荐空闲支付工具。

优选地，使用超载支付工具的用户的子集是根据用户使用习惯和/或历史支付成功率来选择的。

在步骤706，在第二限流节点处针对每种支付工具对交易请求进行限流。

第二限流节点(例如，支付环节限流节点)为每种支付工具设置一容量阈值。该容量阈值可根据下游支付工具容量变化来动态调整。第二限流节点针对每种支付工具进行限流，允许小于或等于该支付工具的容量阈值的支付请求通过，进入支付链路，超出容量阈值的支付请求需要排队等待。通过第二限流节点的交易请求被发送到支付链路。

图8是根据本发明的用于支付工具限流方法的装置的框图。

如图8所示，用于支付工具限流方法的装置可包括接收模块801、第一限流模块802、第二限流模块806和传送模块807。

接收模块801可被配置成接收来自多个用户的交易请求，这些交易请求至少包括请求交易的用户ID。

第一限流模块802包括整体限流子模块803、确定子模块804和推荐子模块805。

整体限流子模块803可被配置成根据第一限流节点(例如，收银环节限流节点)的要求对这些交易请求进行整体限流。

具体而言，可限定在第一限流节点中仅能通过某一阈值数量的交易请求。其余的交易请求需要排队等候通过第一限流节点。

确定子模块804可被配置成确定每种支付工具所对应的交易请求的数目；设置第一限流节点中对应支付工具的目标值；以及将每种支付工具的交易请求数量与该支付工具的目标值进行比较，以确定超载支付工具和空闲支付工具。

推荐子模块805可被配置成向默认使用超载支付工具的用户推荐使用空闲支付工具。

第二限流模块806可被配置成针对每种支付工具对交易请求进行限流。

第二限流模块806可被配置成为每种支付工具设置一容量阈值。该容量阈值可根据下游支付工具容量变化来动态调整。第二限流模块针对每种支付工具进行限流，允许小于或等于该支付工具的容量阈值的支付请求通过，进入支付链路，超出容量阈值的支付请求需要排队等待。

传送模块807被配置成将通过第二限流节点的支付请求发送到支付链路。

本文结合附图阐述的说明描述了示例配置而不代表可被实现或者落在权利要求的范围内的所有示例。本文所使用的术语“示例性”意指“用作示例、实例或解说”，而并不意指“优于”或“胜过其他示例”。本详细描述包括具体细节以提供对所描述的技术的理解。然而，可以在没有这些具体细节的情况下实践这些技术。在一些实例中，众所周知的结构和设备以框图形式示出以避免模糊所描述的示例的概念。

在附图中，类似组件或特征可具有相同的附图标记。此外，相同类型的各个组件可通过在附图标记后跟随短划线以及在类似组件之间进行区分的第二标记来加以区分。如果在说明书中仅使用第一附图标记，则该描述可应用于具有相同的第一附图标记的类似组件中的任何一个组件而不论第二附图标记如何。

结合本文中的公开描述的各种解说性框以及模块可以用设计成执行本文中描述的功能的通用处理器、DSP、ASIC、FPGA或其他可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可被实现为计算设备的组合(例如，DSP与微处理器的组合、多个微处理器、与DSP核心协同的一个或多个微处理器，或者任何其他此类配置)。

本文中所描述的功能可以在硬件、由处理器执行的软件、固件、或其任何组合中实现。如果在由处理器执行的软件中实现，则各功能可以作为一条或多条指令或代码存储在计算机可读介质上或藉其进行传送。其他示例和实现落在本公开及所附权利要求的范围内。例如，由于软件的本质，以上描述的功能可使用由处理器执行的软件、硬件、固件、硬连线或其任何组合来实现。实现功能的特征也可物理地位于各种位置，包括被分布以使得功能的各部分在不同的物理位置处实现。另外，如本文(包括权利要求中)所使用的，在项目列举(例如，以附有诸如“中的至少一个”或“中的一个或多个”之类的措辞的项目列举)中使用的“或”指示包含性列举，以使得例如A、B或C中的至少一个的列举意指A或B或C或AB或AC或BC或ABC(即，A和B和C)。同样，如本文所使用的，短语“基于”不应被解读为引述封闭条件集。例如，被描述为“基于条件A”的示例性步骤可基于条件A和条件B两者而不脱离本公开的范围。换言之，如本文所使用的，短语“基于”应当以与短语“至少部分地基于”相同的方式来解读。

计算机可读介质包括非瞬态计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。非瞬态存储介质可以是能被通用或专用计算机访问的任何可用介质。作为示例而非限定，非瞬态计算机可读介质可包括RAM、ROM、电可擦除可编程只读存储器(EEPROM)、压缩盘(CD)ROM或其他光盘存储、磁盘存储或其他磁存储设备、或能被用来携带或存储指令或数据结构形式的期望程序代码手段且能被通用或专用计算机、或者通用或专用处理器访问的任何其他非瞬态介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来的，则该同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文所使用的盘(disk)和碟(disc)包括CD、激光碟、光碟、数字通用碟(DVD)、软盘和蓝光碟，其中盘常常磁性地再现数据而碟用激光来光学地再现数据。以上介质的组合也被包括在计算机可读介质的范围内。

提供本文的描述是为了使得本领域技术人员能够制作或使用本公开。对本公开的各种修改对于本领域技术人员将是显而易见的，并且本文中定义的普适原理可被应用于其他变形而不会脱离本公开的范围。由此，本公开并非被限定于本文所描述的示例和设计，而是应被授予与本文所公开的原理和新颖特征相一致的最广范围。

Claims (17)

1.一种支付控制方法，包括：

接收来自多个用户的交易请求，每个交易请求包括发送该交易请求的用户的ID；

使第一阈值数目的交易请求通过第一限流节点；

根据所述用户的ID确定与通过所述第一限流节点的每个交易请求相关的主支付工具并且确定该主支付工具为空闲支付工具还是超载支付工具；

向主支付工具为超载支付工具的用户的子集推荐空闲支付工具；以及

在第二限流节点处针对每种支付工具对交易请求进行限流。

2.根据权利要求1所述的方法，其特征在于，进一步包括，

确定与每种支付工具相关的交易请求的总数；以及

将与每种支付工具相关的交易请求的总数与该支付工具的预设目标值进行比较以确定该支付工具是空闲支付工具还是超载支付工具。

3.根据权利要求2所述的方法，其特征在于，进一步包括，如果与支付工具相关的交易请求的总数低于该支付工具的预设目标值，则确定该支付工具为空闲支付工具。

4.根据权利要求2所述的方法，其特征在于，进一步包括，如果与支付工具相关的交易请求的总数高于该支付工具的预设目标值，则确定该支付工具为超载支付工具。

5.根据权利要求2所述的方法，其特征在于，所述预设目标值是根据每种支付工具的容量变化来实时更新的。

6.根据权利要求2所述的方法，其特征在于，所述预设目标值是根据所述第二限流节点处针对每种支付工具设置的容量阈值来确定的。

7.根据权利要求1所述的方法，其特征在于，被推荐空闲支付工具的用户的子集是根据用户使用习惯和/或历史支付成功率来选择的。

8.根据权利要求1所述的方法，其特征在于，进一步包括，将通过所述第二限流节点的交易请求发送到支付链路。

9.一种支付控制装置，包括：

接收模块，其被配置成接收来自多个用户的交易请求，每个交易请求包括发送该交易请求的用户的ID；

第一限流模块，其被配置成：

使第一阈值数目的交易请求通过第一限流节点；

根据所述用户的ID确定与通过所述第一限流节点的每个交易请求相关的主支付工具并且确定该主支付工具为空闲支付工具还是超载支付工具；以及

向主支付工具为超载支付工具的用户的子集推荐空闲支付工具；以及

第二限流模块，其被配置成在第二限流节点处针对每种支付工具对交易请求进行限流。

10.根据权利要求9所述的装置，其特征在于，所述第一限流模块被进一步配置成，基于与每种支付工具相关的交易请求的总数来确定该支付工具是空闲支付工具还是超载支付工具。

11.根据权利要求10所述的装置，所述第一限流模块被进一步配置成：如果与支付工具相关的交易请求的总数低于该支付工具的预设目标值，则确定该支付工具为空闲支付工具。

12.根据权利要求10所述的装置，其特征在于，所述第一限流模块被进一步配置成：如果与支付工具相关的交易请求的总数高于该支付工具的预设目标值，则确定该支付工具为超载支付工具。

13.根据权利要求11或12所述的装置，其特征在于，所述预设目标值是根据每种支付工具的容量变化来实时更新的。

14.根据权利要求11或12所述的装置，其特征在于，所述预设目标值是根据所述第二限流节点处针对每种支付工具设置的容量阈值来确定的。

15.根据权利要求9所述的装置，其特征在于，被推荐空闲支付工具的用户的子集是根据用户使用习惯和/或历史支付成功率来选择的。

16.根据权利要求9所述的装置，其特征在于，进一步包括传送模块，其被配置成将通过所述第二限流节点的交易请求发送到支付链路。

17.一种支付控制装置，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

接收来自多个用户的交易请求，每个交易请求包括发送该交易请求的用户的ID；

使第一阈值数目的交易请求通过第一限流节点；

根据所述用户的ID确定与通过所述第一限流节点的每个交易请求相关的主支付工具并且确定该主支付工具为空闲支付工具还是超载支付工具；

向主支付工具为超载支付工具的用户的子集推荐空闲支付工具；以及

在第二限流节点处针对每种支付工具对交易请求进行限流。