CN114429340A - 电子支付的处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供了一种电子支付的处理方法、装置、电子设备及计算机可读存储介质；方法包括：接收至少一个客户端的至少一个支付请求；对每个支付请求对应的用户账户执行扣款操作，向客户端发送扣款成功消息，并向支付请求对应的商户系统发送入账成功消息；基于每个支付请求生成对应的入账请求，将入账请求分别存储到异步缓存数据库和分布式消息队列中；从分布式消息队列中读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作；当分布式消息队列处于不可用状态时，从异步缓存数据库中继续读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作。本申请能提升电子支付场景的数据吞吐性能，提升电子支付的实时性。

Description

电子支付的处理方法、装置、电子设备及存储介质

技术领域

本申请涉及互联网技术，尤其涉及一种电子支付的处理方法、装置、电子设备及计算机可读存储介质。

背景技术

在银行或者第三方支付系统中，经常出现针对热点账户的大规模的转账交易，此时，热点账户记录的数据会被频繁更新业务请求。所有业务请求需要排队等待热点账户的账户记录锁，以完成转账。这将造成业务请求的堆积堵塞，使得业务请求超时失败，降低支付系统的吞吐量，并严重影响其它业务的处理。

发明内容

本申请实施例提供一种电子支付的处理方法、装置、电子设备及计算机可读存储介质，能提升电子支付场景的数据吞吐性能，提升电子支付的实时性。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种电子支付的处理方法，包括：

接收至少一个客户端的至少一个支付请求；

对每个所述支付请求对应的用户账户执行扣款操作，向所述客户端发送扣款成功消息，并向所述支付请求对应的商户系统发送入账成功消息；

基于每个所述支付请求生成对应的入账请求，将所述入账请求分别存储到异步缓存数据库和分布式消息队列中；

从所述分布式消息队列中读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作；

当所述分布式消息队列处于不可用状态时，从所述异步缓存数据库中继续读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作。

本申请实施例提供一种电子支付的处理方法，包括：

在客户端中显示用于电子支付的页面；

响应于在所述页面中接收到针对商户系统的电子支付操作，发送针对所述商户系统的支付请求，实时显示扣款成功消息；

其中，所述扣款成功消息是后台服务器对所述支付请求对应的用户账户执行扣款操作后发送，且针对所述商户系统的商户账户的入账操作是基于异步缓存数据库和分布式消息队列执行的。

本申请实施例提供一种电子支付的处理装置，包括：

接收模块，用于接收至少一个客户端的至少一个支付请求；

扣款模块，用于对每个所述支付请求对应的用户账户执行扣款操作，向所述客户端发送扣款成功消息，并向所述支付请求对应的商户系统发送入账成功消息；

生成模块，用于基于每个所述支付请求生成对应的入账请求，将所述入账请求分别存储到异步缓存数据库和分布式消息队列中；

第一入账模块，用于从所述分布式消息队列中读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作；

第二入账模块，用于当所述分布式消息队列处于不可用状态时，从所述异步缓存数据库中继续读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作。

在上述方案中，所述电子支付的处理装置还包括限流模块，已经接收的支付请求的状态包括正在处理和待处理；所述限流模块，用于：

当正在处理的支付请求占用的连接数超过第一连接数阈值，或正在处理的支付请求占用的连接池数量超过第一连接池数阈值时，将待处理的支付请求进行限流处理，并将所述待处理的支付请求对应的商户账户加入限流列表。

在上述方案中，所述限流模块，还用于：

当待处理的多个入账请求对应的商户账户在所述限流列表中时，对所述待处理的多个入账请求进行合并处理，并将合并处理得到的入账请求存储到与所述商户账户对应的临时队列中；

当任一临时队列中的入账请求触发超时且入账请求数小于请求数阈值时，从所述限流列表中删除所述任一临时队列对应的商户账户，并对所述任一临时队列中的入账请求对应的商户账户执行入账操作。

在上述方案中，所述第一入账模块，还用于：

当任一临时队列中的入账请求数大于所述请求数阈值时，对所述任一临时队列中的入账请求对应的商户账户执行入账操作。

在上述方案中，所述第一入账模块，还用于：

基于正在被处理的入账请求所占用的内存信息，确定其他入账请求所占用的连接数和连接池数量；

其中，所述其他入账请求是正在被处理的入账请求，且与所述待处理的入账请求对应同一商户账户；

当所述其他入账请求所占用的连接数未超过第二连接数阈值，且所述其他入账请求所占用的连接池数量未超过第二连接池数阈值时，将所述待处理的入账请求中所携带的商户账户信息写入任意一个空闲进程的内存中；

基于所述空闲进程对所述商户账户执行入账操作。

在上述方案中，所述限流模块，还用于

当所述其他入账请求所占用的连接数超过所述第二连接数阈值，或所述其入账请求所占用的连接池数量超过所述第二连接池数阈值时，对所述待处理的入账请求进行限流处理，并将所述待处理的入账请求对应的商户账户加入所述限流列表。

在上述方案中，所述限流模块，还用于：

确定包含预设命令字的待处理的入账请求的数量；

当包含预设命令字的待处理的入账请求的数量超过命令字阈值时，对所述包含预设命令字的待处理的入账请求进行限流处理，并将与包含预设命令字的待处理的入账请求对应的商户账户加入所述限流列表。

在上述方案中，所述扣款模块，还用于：

基于每个所述支付请求从用户数据库中查询对应的用户账户；

从查询到的用户账户的余额中扣除所述支付请求中携带的转账金额，并生成用户账户流水；

基于所述用户账户流水生成交易单。

在上述方案中，所述第一入账模块，还用于：

对商户数据库中所述交易单的单号进行锁定处理；

基于所述单号在所述商户数据库中查找与所读取的入账请求对应的商户账户流水；

当未查找到所述商户账户流水时，从所读取的入账请求对应的商户账户的余额中增加所述转账金额，并生成商户账户流水；

对所述交易单的单号进行解锁处理。

在上述方案中，所述第一入账模块，还用于：

基于所述商户账户流水和所述用户账户流水对每个入账请求对应的交易进行核对处理，以确定每次交易中对所述用户账户扣款正确，且对所述商户账户入账正确。

在上述方案中，所述接收模块，还用于：

将所述支付请求的相关信息存储至日志中，以在所述异步缓存数据库、所述用户数据库或所述商户数据库处于不可用状态时，基于所述日志进行恢复处理。

在上述方案中，所述第一入账模块，还用于：

将所述异步缓存数据库中所述商户账户的状态由待入账修改为已入账。

本申请实施例提供一种电子支付的处理装置，包括：

第一显示模块，用于在客户端中显示用于电子支付的页面；

第二显示模块，用于响应于在所述页面中接收到针对商户系统的电子支付操作，发送针对所述商户系统的支付请求，实时显示扣款成功消息；

其中，所述扣款成功消息是后台服务器对所述支付请求对应的用户账户执行扣款操作后发送，且针对所述商户系统的商户账户的入账操作是基于异步缓存数据库和分布式消息队列执行的。

本申请实施例提供一种电子设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的任意一种电子支付的处理方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的任意一种电子支付的处理方法。

本申请实施例具有以下有益效果：

在完成对用户账户的扣款后，通过将发送通知与入账操作进行异步化的处理，使得客户端和商户系统能够实时感知电子支付的处理结果，提高用户和商户的体验；针对入账请求采用分布式消息队列和异步缓存数据库协同的方式，在缓解了高并发的争用的同时，有效地保证了入账请求相关数据的持久化和安全性。

附图说明

图1是相关技术提供的实现异步化服务的示意图；

图2是相关技术提供的消息队列中的请求的传递示意图；

图3是相关技术提供的入账原理示意图；

图4A是本申请实施例提供的交易系统的架构示意图；

图4B是本申请实施例提供的异步支付系统的架构示意图；

图5是本申请实施例提供的入账原理示意图；

图6A是本申请实施例提供的电子支付的处理方法的流程示意图；

图6B是本申请实施例提供的电子支付的处理方法的交互流程示意图；

图6C是本申请实施例提供的电子支付页面的示意图；

图6D是本申请实施例提供的支付成功的通知页面的示意图；

图7是本申请实施例提供的入账的交互示意图；

图8是本申请实施例提供的动态限流的示意图；

图9A是本申请实施例提供的电子支付的处理方法的流程示意图；

图9B是本申请实施例提供的对入账请求的处理的示意图；

图10是本申请实施例提供的热点商户的交易示意图；

图11是本申请实施例提供的入账请求处理的页面示意图；

图12A是本申请实施例提供的服务器400的结构示意图；

图12B是本申请实施例提供的终端500的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

如果申请文件中出现“第一/第二”的类似描述则增加以下的说明，在以下的描述中，所涉及的术语“第一/第二/第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一/第二/第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)MySQL：一种关系型数据库管理系统。

2)实时付款系统：可以及时向用户的银行卡完成付款的系统。

3)异步支付系统：用于延迟向商户的商户账户进行入账操作的系统，具体是在向客户端发送入账成功消息之后才进行实际的入账操作。

4)用户身份证明(UID，User Identification)：用户、用户、商户都有自己UID，UID是他们的唯一标识。

5)命令字：是针对商户账户的操作，例如：商户金额增加。

6)每秒查询率(QPS，Queries-per-second)：是单个进程每秒请求服务器的成功次数。

7)吞吐量(TPS，Transactions Per Second)：服务器单位时间内能处理的数量，是每秒内的事务数。

8)并发：一段时间内存在需要处理的多个支付请求的情况，多个支付请求可以来自相同或不同的用户。

9)消息队列(MQ，Message Queue)：是一种分布式消息队列服务，它能够提供可靠的基于消息的异步通信机制，能够将分布式部署的不同应用(或同一应用的不同组件)之间的收发消息，存储在可靠有效的CMQ队列中，防止消息丢失。CMQ支持多进程同时读写，收发互不干扰，无需各应用或组件始终处于运行状态。基于云技术实现的消息队列称为云消息队列(CMQ，Cloud Message Queue)。

10)进程：是正在运行的程序的实例，也是线程的容器。

11)线程：是进程的基本执行单元，一个进程的所有任务都在线程中执行。一个进程中可以并发多个线程，每条线程并行执行不同的任务。一个线程处理一个请求，在每次处理请求时，从线程池中取出一个空闲的线程。

12)连接池：用于将数据库连接作为对象存储的内存空间。当需要访问数据库时，从连接池中取出一个已建立的空闲连接对象；使用完毕后，将连接放回连接池中，以供下一个请求访问使用。

13)热点账户：即高频(超出频率阈值)进行扣款、入账的账户；对应的数据为热点数据，会被频繁更新。

14)异步：指发出一个请求后，不需要等待返回，随时可以触发下一个请求，不需要等待。

15)限流：通过对并发访问请求进行限速，或者对一个时间窗口内的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务、让服务排队或等待、降级服务等。

16)锁争用：多个线程使用同一个锁，另一个线程先于本线程加锁，本线程在加锁的时候会造成线程阻塞。

商业支付一般通过实时付款系统完成实时入账，然而，在实际运营中，实时付款系统可能会出现以下问题：

1、商户突然做活动，引起请求量突增，导致实时付款系统过于繁忙。

2、当实时付款系统出问题的时候，银行支付不可用。

3、在一秒内QPS的流量不均衡，请求集中于最开始的几十毫秒内，由于资源管理器的限流，只有部分请求能穿透资源管理器到达数据库，其它的请求会被资源管理器拒绝，只有在部分请求被处理完后，才会被继续处理，但是因为此时QPS超过限制，新的请求无法过来，且因为QPS的超时设置，其余的请求若没有在一定时间内被处理完，则不再对其处理，造成整体TPS较低。

因为大部分商户都是采用日结/月结的结账方式，商户并不关心商户账户中的实时余额，所以相关技术中通过对用户账户实时扣款，对商户账户延迟入账的方式，来解决请求过于集中的问题。针对秒杀场景，相关技术通过引入异步化服务，将部分支付做成准实时，化并行请求为串行请求，缓解了高并发请求给支付系统带来的压力。

如图1和图2所示，图1是相关技术提供的实现异步化服务的示意图，图2是相关技术提供的消息队列中的请求传递的示意图。图1中，来自网络用户(也是图2中的发布方)的用户请求会被送入消息队列中，通过异步队列组件进行异步化处理后，被图2中的消费方消费掉(即处理完请求)。管理端用于管理消息队列，它可根据不同的业务需求创建不同的消息队列，还可对请求进行配置、监测、管理、重建等。全球代理用于监听消息队列。若异步队列组件出现问题，必须得到相关数据库管理员的技术支持，才能解决问题，不利于管理和维护，可控性较差，且出现的问题极有可能对业务造成不可控的风险。

参见图3，图3是相关技术提供的入账原理示意图。其中，虚线的左右两边对应不同的地方，例如，左边对应广州，右边对应上海。接入层用于接收来自客户端的支付请求，并向事务管理器分发待处理的支付请求。事务管理器用于产生事务并为事务分配事务标识，在图3中，事务管理器1和事务管理器2用于接收支付请求，并完成对用户账户的扣款操作，以及基于支付请求生成入账请求。异步入账服务用于实现商户账户的入账，商户数据库用于存储各个商户账户的余额等信息。以图3左侧为例说明入账过程，事务管理器1将入账请求发送到消息队列1，以等待被处理，之后，异步入账服务1调用商户资源管理器1的入账接口串行处理消息队列1中的入账请求，完成商户账户的入账，并更新商户数据库中对应商户账户的余额信息。

这种准实时(异步)入账的做法，使得在一般的高并发情况下，商户几乎无延迟感知。但是当商户账户一直处于高并发状态时，消息队列中将不断插入新的待处理的入账请求，因为待处理的入账请求无法得到及时的处理，所以达不到准实时的效果，降低了商户的体验。

为解决相关技术中异步队列组件管理困难，且持续高并发情况下无法准实时的技术问题，本申请实施例提供一种电子支付的处理方法、装置、电子设备和计算机可读存储介质，能够提高TPS，降低运维压力。

参见图4A，图4A是本申请实施例提供的交易系统的架构示意图，交易系统包括终端和异步支付系统，其中异步支付系统包括银行系统和商户系统。终端(一般为用户终端)向异步支付系统的银行系统中的银行数据库发送支付请求，在银行数据库中完成对与支付请求相关的用户账户的扣款操作，并基于支付请求生成入账请求。之后，通过银行数据库将入账请求发送至商户系统中的商户数据库，以完成对与支付请求相关的商户账户的入账操作。

参见图4B，图4B是本申请实施例提供的异步支付系统的架构示意图，其中，异步支付系统包括接入层、多个子系统(示出了子系统1、子系统2……子系统n)、多个商户资源管理器和多个商户数据库。接入层与多个子系统连接(不同的子系统可用于处理不同类型的请求)，每个子系统都与商户资源管理器连接，商户资源管理器与商户数据库连接。子系统包括事务管理器、分布式消息队列、异步入账服务、异步缓存数据库、用户资源管理器和用户数据库。用户资源管理器根据功能的不同，可以划分为联合资源管理器、订单资源管理器、银行资源管理器等。用户数据库根据类型的不同，可以划分为联合数据库、用户订单数据库、银行数据库等。联合资源管理器用于对用户、新订单、新银行等相关的数据进行处理，订单资源管理器用于对已有订单的相关数据进行处理，银行资源管理器用于对数据库中已有银行的相关数据进行处理。

作为示例，事务管理器和分布式消息队列运行在事务服务器中，用户资源管理器和用户数据库运行在用户服务器中，商户资源管理器和商户数据库运行在商户服务器中，异步缓存数据库运行在异步服务器中，且由异步服务器提供异步入账服务。上述的服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

参见图5，图5是本申请实施例提供的入账原理示意图。以下将结合图5对本申请实施例提供的电子支付的处理方法的实现过程进行说明。在一次交易过程中(例如秒杀场景)，需要先对用户账户执行扣款操作，再对商户账户执行入账操作。针对于同一商户系统的支付请求通过接入层进入事务管理器1，事务管理器1调用用户服务器中的用户资源管理器，对用户账户执行扣款操作。在此过程中，若支付请求占用的用户资源管理器的连接数超过连接数阈值，或占用的连接池的数量超过连接池阈值，将与这些支付请求对应的商户账户加入限流列表中。在完成扣款后，事务管理器1生成入账请求，将入账请求同步发送给异步服务器，异步服务器调用异步入账服务1将入账请求的相关信息(如商户账户、用户账户、请求发起时间等)写入异步缓存数据库1中，以实现入账请求相关信息的持久化，在分布式消息队列异常时，可根据异步缓存数据库1中存储的相关数据完成支付。

同时，入账请求被事务管理器1异步发送到分布式消息队列1中等待处理，异步入账服务1读取分布式消息队列1中的入账请求，确定入账请求对应的商户账户是否属于限流列表中的账户。若不是，则直接调用商户资源管理器处理入账请求。若是，将该商户账户对应的多个入账请求存放至异步服务器内存的临时队列中等待处理，当临时队列中的入账请求触发超时或入账请求数超过请求数阈值时，调用商户资源管理器处理入账请求。其中，当入账请求触发超时且入账请求数未超过请求数阈值时，从限流列表中删除该商户账户，并调用商户资源管理器处理入账请求。在商户资源管理器处理入账请求的过程中，若入账请求占用的商户资源管理器的进程(连接数)过多，触发商户资源管理器限流，则该商户账户将被再次加入限流列表中。若入账请求未触发商户资源管理器限流，则商户资源管理器根据入账请求，对商户数据库中该商户账户的余额等信息进行更新，完成入账，并将异步缓存数据库中该商户账户的状态修改为已入账。

需要说明的是，图5中的数字序号表示数据流向。

可见，本申请实施例通过分布式消息队列对高并发请求进行削峰，在此基础上，通过对用户账户执行扣款操作和对商户账户执行入账操作时采用的上述限流措施，进一步减少了高并发请求的数量，降低了用户数据库和商户数据库的锁等待时间，缓解了并发锁争用。

参见图6A和图7，图6A是本申请实施例提供的电子支付的处理方法的流程示意图，图7是本申请实施例提供的入账的交互示意图，以下将结合图6A示出的步骤以及图7，说明异步支付系统中的服务器执行由本申请实施例提供的电子支付的处理方法。

在步骤101中，事务服务器接收至少一个客户端的至少一个支付请求。

在一些实施例中，如图7所示，事务服务器中的事务管理器通过异步支付系统的接入层接收来自至少一个客户端的至少一个支付请求。每个客户端可针对同一个商户系统向异步支付系统发送一个或多个不同的支付请求，也可针对多个商户系统向异步支付系统发送多个不同的支付请求。每个支付请求中携带了用户账户信息、商户账户信息、转账金额等信息。

事务管理器在接收支付请求后，确定异步支付系统中的用户资源管理器、用户数据库、商户资源管理器和商户数据库都处于可用状态，将支付请求的相关信息(如时间、用户账户、商户账户、转账金额等)存储至远程日志中，以在图7中的异步缓存数据库、用户数据库或商户数据库处于不可用状态时，基于日志进行恢复处理，重放与交易相关的支付请求等。

之后，事务管理器调用用户服务器中的用户资源管理器，以对每个支付请求对应的用户账户执行扣款操作。在基于支付请求对对应的用户账户执行扣款操作之前，需要确定支付请求所针对的商户系统的商户账户是否在限流列表中，并确定针对同一商户账户的并发支付请求是否触发用户资源管理器限流。其中，商户账户是支付请求所针对的商户系统的账号，用户资源管理器所接收的支付请求的状态包括正在处理和待处理。

在一些可能的示例中，当用户资源管理器中正在处理的针对同一商户账户的支付请求占用的连接数超过第一连接数阈值，或正在处理的针对同一商户账户的支付请求占用的连接池数量超过第一连接池数阈值时，确定触发用户资源管理器限流。

若支付请求所针对的商户账户在限流列表中，或针对同一商户账户的并发支付请求触发用户资源管理器限流，则用户资源管理器对针对该商户账户的支付请求进行限流处理，即，对针对该商户账户的待处理的支付请求以及后续新接收的支付请求进行延迟处理。其中，当针对同一商户账户的并发支付请求触发用户资源管理器限流时，还将该商户账户加入限流列表。

若支付请求所针对的商户账户不在限流列表中，且针对同一商户账户的并发支付请求并未触发用户资源管理器限流，则按支付请求的接收先后顺序对支付请求进行处理。

如此，可在用户资源管理器层面对高并发请求进行第一次削峰，减少进入下一级的高并发请求的数量，缓解了运维的压力。

在步骤102中，用户服务器对每个支付请求对应的用户账户执行扣款操作。

在一个可能的示例中，用户服务器对每个支付请求对应的用户账户执行扣款操作，可以通过如下步骤1021至步骤1023实现。

在步骤1021中，基于每个支付请求从用户数据库中查询对应的用户账户。

在一些实施例中，用户服务器的用户数据库中存储了各用户的用户账户信息和历史交易信息。因此，用户资源管理器可基于支付请求所携带的用户账户信息在用户数据库中查询到对应的用户账户。

在步骤1022中，从查询到的用户账户的余额中扣除支付请求中携带的转账金额，并生成用户账户流水。

其中，账户流水即交易记录。

在步骤1023中，基于用户账户流水生成交易单。

在一些实施例中，基于用户账户流水生成的交易单可用于防止交易记录重复，因此，在对用户账户执行扣款操作时不需要对用户账户加锁。

需要说明的是，扣款操作所包括的步骤1021至步骤1023都属于原子操作，即在执行完毕之前不会被任何其它任务或事件中断的操作。

在步骤103中，用户服务器向客户端发送扣款成功消息，并向支付请求对应的商户系统发送入账成功消息。

在一些实施例中，在对用户账户执行扣款操作之后，商户资源管理器向事务管理器返回扣钱成功消息。在对支付请求对应的商户系统的商户账户执行入账操作之前，异步支付系统基于扣钱成功消息向用户的客户端发送扣款成功消息，并向支付请求对应的商户系统发送入账成功消息，可减少通知的时耗，提高用户和商户的转账体验。尤其是当异步支付系统抖动或用户服务器和商户服务器不在同一个城市时，提前向商户发送入账成功消息可避免入账成功，而迟迟接收不到入账成功消息的现象发生。

在步骤104中，事务服务器基于每个支付请求生成对应的入账请求，将入账请求分别存储到异步缓存数据库和分布式消息队列中。

在一些实施例中，入账请求和支付请求一一对应，因此，入账请求中也携带有用户账户信息、商户账户信息、转账金额等信息。因为事务管理器对高并发入账请求进行了一次削峰，因此，基于支付请求生成的入账请求的数量也相应地得到了控制。通过调用异步服务器中的异步入账服务将入账请求实时地存储到异步缓存数据库中，有效地保证了入账请求相关数据的持久化和安全性，相比消息队列更为安全可控。同时，将入账请求异步存储到分布式消息队列中，可将高并发入账请求转化为串行入账请求，降低并发锁争用带来的性能瓶颈。

参见图8，图8是本申请实施例提供的动态限流的示意图。在一些实施例中，在生成与支付请求对应的入账请求后，异步入账服务检测待处理的多个入账请求对应的商户账户是否在限流列表中，当商户账户在限流列表中时，对待处理的多个入账请求进行合并处理，并将合并处理后的入账请求存储到异步服务器的内存的临时队列中。其中，异步服务器的内存中有多个临时队列，每个临时队列中存储不同的商户账户对应的入账请求，即，临时队列与商户账户一一对应。当任一临时队列中的入账请求触发超时且入账请求数小于请求数阈值时，从限流列表中删除任一临时队列对应的商户账户，并调用商户服务器中的商户资源管理器对任一临时队列中的入账请求对应的商户账户执行入账操作。当任一临时队列中的入账请求数大于请求数阈值时，调用商户资源管理器对任一临时队列中的入账请求对应的商户账户执行入账操作。

可见，异步入账服务通过对限流列表中的商户账户对应的入账请求进行合并处理，并存储至临时队列中，减少了下一阶段在同一时间进入商户资源管理器的请求量，相当于对高并发请求进行了第二次削峰，有助于缓解并发锁争用现象，且有效地缓解了运维的压力。

在步骤105中，异步服务器判断分布式消息队列是否处于可用状态，若是，执行步骤106和步骤107；若否，执行步骤108和步骤109。

在一些实施例中，为了保证事务的一致性和安全性，在分布式消息队列处于可用状态时，从分布式消息队列中读取入账请求，以完成对商户账户的入账操作，即执行步骤106和步骤107；当分布式消息队列处于不可用状态时，从异步缓存数据库中读取入账请求，以完成对商户账户的入账操作，即执行步骤108和步骤109。

在步骤106中，异步服务器从分布式消息队列中读取待处理的入账请求。

在一些实施例中，如步骤104所述，当商户账户在限流列表中时，异步服务器中的异步入账服务从分布式消息队列中读取待处理的入账请求，并对待处理的多个入账请求进行合并处理，当合并后的入账请求触发超时或入账请求数大于请求数阈值时，调用商户服务器中的商户资源管理器对待处理的入账请求进行处理；当商户账户不在限流列表中时，异步入账服务从分布式消息队列中读取待处理的入账请求后，调用商户资源管理器对待处理的入账请求进行处理。

在一些实施例中，调用商户资源管理器对待处理的入账请求进行处理可通过图9A中的步骤1061至步骤1065实现，图9A是本申请实施例提供的电子支付的处理方法的流程示意图。

在步骤1061中，基于正在被处理的入账请求所占用的内存信息，确定其他入账请求所占用的连接数和连接池数量。

在一些实施例中，其他入账请求是商户资源管理器正在处理的入账请求，且与待处理的入账请求对应同一商户账户。商户资源管理器的每个进程对应一个连接，每个连接中可以有多个请求。每个进程都可以并发多个线程，通过多个线程处理进程中的多个请求。商户资源管理器中的进程通过共享内存交互信息，每个进程在共享内存中都有自己的专属共享内存，每个进程会将当前所处理的请求的相关信息写入自己的专属共享内存中，并可通过访问共享内存获取其他进程的专属共享内存中存储的信息，以确定其他进程当前正在处理的请求。因此，可以通过共享内存(即内存信息)确定当前正在被各个进程处理的入账请求，并确定对应同一商户账户的入账请求占用的连接数和连接池数量。

例如，对应A商户账户的入账请求1占用进程1，入账请求2占用进程2，入账请求3占用进程4。其中，进程1和进程2对应连接池1，进程4对应连接池2。可见，对应A商户账户的入账请求一共占用3个进程，即占用3个连接，并占用2个连接池。

在步骤1062中，判断其他入账请求所占用的连接数是否超过第二连接数阈值，以及其他入账请求所占用的连接池数量是否超过第二连接池数阈值；若连接数超过第二连接数阈值，或连接池数量超过第二连接池数阈值，执行步骤1063；若连接数未超过第二连接数阈值，且连接池数量未超过第二连接池数阈值，执行步骤1064和步骤1065。

在步骤1063中，对待处理的入账请求进行限流处理，并将待处理的入账请求对应的商户账户加入限流列表。

当对应同一商户账户的正在处理的入账请求所占用的连接数超过第二连接数阈值，或所占用的连接池数量超过第二连接池数阈值时，对针对同一商户账户的待处理的入账请求以及后续新接收的入账请求进行限流处理，即延迟处理。并将该商户账户加入限流列表。

可见，当支付请求触发用户资源管理器限流时，与支付请求对应的商户账户将被添加到限流列表中；当合并后的入账请求触发超时且入账请求数不超过请求数阈值时，已被添加到限流列表中的商户账户将从限流列表中删除；当入账请求触发商户资源管理器限流时，与入账请求对应的商户账户将再次被添加到限流列表中。如此，在整个支付过程中，根据支付请求和入账请求的状态实现了动态限流，降低了用户资源管理器和商户资源管理器中运行的线程数，降低了商户数据库中锁的等待时间，减少了商户数据库负载，提高了异步支付系统的吞吐量。

在步骤1064中，将待处理的入账请求中所携带的商户账户信息写入任意一个空闲进程的内存中。

当待处理的入账请求所对应的同一商户账户未被限流时，在商户资源管理器中选择一个空闲的进程，将待处理的入账请求中携带的商户账户信息(如时间、商户账户等)写入该空闲进程的专属共享内存中。

在步骤1065中，基于空闲进程对商户账户执行入账操作。

对商户账户执行入账操作的过程可参见下文对步骤107的相关说明。

在一些实施例中，商户资源管理器不仅用于处理入账请求，还可用于处理扣款请求等。例如，A商户需要定期向材料供应商转账，此时，由商户资源管理器对商户账户执行扣款操作以完成支付。商户资源管理器中处理的请求的类型不同，当同一类型的请求过多，即包含同一命令字如“入账”的请求过多，将占用过多的商户资源管理器的进程，而导致包含其他命令字的请求如扣款请求无法得到及时的处理，而影响商户体验。因此，商户资源管理器需要确定包含预设命令字(如“入账”)的待处理的请求(如入账请求)的数量；当包含预设命令字的待处理的请求的数量超过命令字阈值(如100、300等)时，对包含预设命令字的待处理的请求进行限流处理，并将与包含预设命令字的待处理的请求对应的商户账户加入限流列表。

如此，在商户资源管理器中，通过第二连接数阈值、第二连接池数阈值和命令字阈值实现了对高并发请求的第三次削峰，避免针对同一商户账户的入账请求或同一类型的请求占用商户资源管理器所有的进程，而无法响应其他业务请求。尤其是在商户服务器容量不足时，可有效地提高异步支付系统的处理效率和系统性能。

需要说明的是，通过命令字进行限流的方法也可应用于用户资源管理器中。

在步骤107中，商户服务器对所读取的入账请求对应的商户账户执行入账操作。

在一些实施例中，对入账请求对应的商户账户执行入账操作，即通过商户服务器中的商户资源管理器对入账请求对应的商户账户，增加入账请求所请求入账的金额。

在一个可能的示例中，商户服务器对所读取的入账请求对应的商户账户执行入账操作，可以通过如下步骤1071至步骤1074实现。

在步骤1071中，对商户数据库中交易单的单号进行锁定处理。

其中，因为交易单在用户数据库中，所以在商户服务器的商户数据库中只能通过对交易单的单号加锁，防止对入账请求的重复处理。

在步骤1072中，基于单号在商户数据库中查找与所读取的入账请求对应的商户账户流水。

在步骤1073中，当未查找到商户账户流水时，从所读取的入账请求对应的商户账户的余额中增加转账金额，并生成商户账户流水。

若未查找到与所读取的入账请求对应的商户账户流水，说明之前并未对商户账户增加与所读取的入账请求对应的金额，根据入账请求所携带的转账金额在商户账号的余额中增加转账金额，完成入账操作

在步骤1074中，对交易单的单号进行解锁处理。

对交易单的单号解锁后，可基于下一个入账请求对该商户账户执行入账操作。

在一些实施例中，在执行完入账操作之后，将异步缓存数据库中与所处理的入账请求对应的商户账户的状态由待入账修改为已入账。例如，异步缓存数据库中存储有针对A商户的3个入账请求(请求a、请求b、请求c)，在基于请求a对A商户账户执行入账操作后，将请求a所对应的A商户的状态更新为已入账，而请求b和请求c所对应的A商户的状态仍然为待入账。

在一些实施例中，在修改异步缓存数据库中商户账户的状态之后，还需要基于商户账户流水和用户账户流水对每个入账请求对应的交易进行核对处理，以确定每次交易中对用户账户扣款正确，且对商户账户入账正确，从而保证转账的准确率。

在步骤108中，异步服务器从异步缓存数据库中继续读取待处理的入账请求。

在步骤109中，商户服务器对所读取的入账请求对应的商户账户执行入账操作。

在一些实施例中，异步服务器中的异步入账服务将读取的待处理的入账请求发送到商户服务器的商户资源管理器中，通过商户资源管理器执行入账操作。

需要说明的是，步骤109中对入账请求的处理过程与步骤106一致，此处不再赘述。本申请实施例中的商户数据库、用户数据库以及异步缓存数据库都，可以是MySQL数据库。

可以看出，本申请实施例在完成对用户账户的扣款后，同时向用户的客户端和商户系统发送通知，可减少通知的时耗，提高用户和商户的转账体验。将入账请求保存在分布式消息队列中，降低了高并发的争用。同时将入账请求保存在异步缓存数据库中，有效地保证了入账请求相关数据的持久化和安全性，可在分布式消息队列不可用时，通过异步缓存数据库中存储的相关数据完成支付流程。通过用户资源管理器、异步入账服务、商户资源管理器对高并发请求进行动态限流，从而可在不扩容商户服务器的情况下，提升异步支付系统的性能，使异步支付系统的吞吐量最大化，保证了高峰期间重点商户的支付稳定性，也大大降低了运维的压力。

下面，从客户端中发起支付请求的角度来说明本申请实施例提供的电子支付的处理方法。

参见图6B，图6B是本申请实施例提供的电子支付的处理方法的交互流程示意图，将结合图6B示出的步骤说明由用户的终端实施本申请实施例提供的电子支付的处理方法的过程。

在步骤201中，在客户端中显示用于电子支付的页面。

在一些可能的示例中，可通过用户终端中的客户端(如第三方支付客户端、银行客户端)或支付小程序进入电子支付的页面。

作为示例，客户端可以是各种类型，例如即时通信客户端、短视频客户端、网络购物客户端等。

在步骤202中，响应于在电子支付的页面中接收到针对商户系统的电子支付操作，发送针对商户系统的支付请求，实时显示扣款成功消息。

参见图6C和图6D，图6C是本申请实施例提供的电子支付页面的示意图，图6D是本申请实施例提供的支付成功的通知页面的示意图。在图6C中，当转账按钮601被触发时，即接收到针对商户系统(**超市)的电子支付操作时，后台服务器对用户账户执行扣款操作，并在如图6D所示的通知页面中分别显示用户的转账已被领取，以及**超市已收钱，即实时显示扣款成功消息。

在一些实施例中，扣款成功消息是后台服务器对支付请求对应的用户账户执行扣款操作后发送，同时，后台服务器(即前文中的用户服务器)向商户系统发送入账成功消息，而针对商户系统的商户账户的入账操作，是相对于发送入账成功消息异步执行的，即发送入账成功消息可以先于执行入账操作执行，具体参见上文，入账操作可以是基于异步缓存数据库和分布式消息队列执行的。

因为异步支付系统采用了分布式消息队列即异步队列，能够对高并发请求削峰，并可靠地将与支付请求对应的入账请求发送到下一环节(异步入账服务)进行处理，同时通过异步缓存数据库存储入账请求，保证了入账请求数据的持久化和安全性，所以，可在对用户账户扣款成功后，向用户账户和商户系统实时地同步发送通知，以提高用户和商户的转账体验。

此外，在对用户账户执行扣款操作，以及对商户系统的商户账户执行入账操作时，本申请实施例分别通过对支付请求和入账请求限流，降低了并发锁竞争，提高了异步支付系统的吞吐量。关于限流的详细说明，可参见前文，此处不再赘述。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

参见图10，图10是本申请实施例提供的热点商户的交易示意图。图10中，A商户整点进行秒杀活动，活动开始后大量用户(用户1～用户n)下单购买并支付。商户数据库将同时接收到n个入账请求，以更新商户数据库中A商户账户的余额。此时A商户账户余额更新出现热点，用于处理入账请求的商户资源管理器中活跃连接数快速上升，因连接和数据库锁都是有限的，当连接数耗尽，上层业务服务调用支付系统将会失败，导致商户数据库所涉及的商户的交易都无法进行。

为了解决上述问题，本申请实施例将异步服务和动态限流相结合，对支付系统进行了优化。

用户在下单购买后，客户端生成针对商户系统的支付请求。如图7所示，支付请求通过异步支付系统的接入层，到达事务管理器。事务管理器在确定异步支付系统中的用户资源管理器、用户数据库、商户资源管理器和商户数据库都可用之后，将支付请求的相关信息记录在远程日志中，以便在灾难恢复时，从远程日志中读取相关数据，用于恢复。

然后，事务管理器调用用户资源管理器完成对用户账户的扣款。在此过程中，若针对同一商户账户的处理中的支付请求在用户资源管理器中所占用的连接数超过第一连接数阈值，或占用的连接池数量超过第一连接池数阈值，对针对同一商户账户的待处理的支付请求和后续新接收的支付请求进行限流，即，延迟处理，并将该商户账户加入限流列表。如此，可在用户资源管理器中，对高并发请求(入账请求)进行第一次削峰，减少下一级的请求量，缓解运维的压力。

对用户账户扣款的过程如下。因为支付请求中携带有用户账户信息、商户账户信息、转账金额等信息。因此，用户资源管理器可根据支付请求中的用户账户信息在用户数据库中查询到用户账户相关数据。之后，从用户账户的余额中扣除转账金额，并生成用户账户流水和交易单。交易单可用于防止交易记录重复，因此，在对用户账户扣款时不需要对用户账户加锁。最后，向用户账户发送扣款成功消息，向商户系统发送入账成功消息。如此，在完成对用户账户的扣款后，同时通知用户和商户，之后再继续执行对商户账户的扣款，可减少通知的时耗，提高用户和商户的转账体验。

此后，事务管理器基于支付请求生成携带商户账户信息的入账请求，将入账请求分别存储到异步缓存数据库和分布式消息队列中，并根据分布式消息队列中的入账请求完成后续支付流程。

其中，事务管理器通过调用商户异步服务将入账请求实时存储到异步缓存数据库。当分布式消息队列处于不可用状态(如链路断裂)时，可从异步缓存数据库中读取入账请求，以完成支付流程。如此，可有效地保证入账请求的持久化和安全性。需要说明的是，若事务管理器到商户异步服务之间的链路经常出现故障，则不会将入账请求存储至异步缓存数据库中。

事务管理器调用异步入账服务对分布式异步队列中的入账请求进行处理的过程，可参见图8，在图8中，异步入账服务根据限流列表确定分布式消息队列中的入账请求对应的商户账户是否在限流列表中，若该商户账户不在限流列表中，调用商户资源管理器处理入账请求。

若该商户账户在限流列表中，异步入账服务对分布式消息队列中的入账请求进行合并处理，并将合并处理后的入账请求存放内存临时队列中。当临时队列中的入账请求触发超时且入账请求数小于请求数阈值时，从限流列表中删除入账请求对应的商户账户，并调用商户资源管理器处理临时队列中的入账请求。当临时队列中的入账请求数大于请求数阈值时，调用商户资源管理器处理临时队列中的入账请求。

可见，异步入账服务通过对限流列表中的商户账户对应的入账请求进行合并处理，并存放到临时队列中，减少了在同一时间进入下一级中的商户资源管理器的请求量，相当于对高并发请求(入账请求)进行了第二次削峰，有助于缓解并发锁争用现象，且有效地缓解了运维的压力。

参见图9B，图9B是本申请实施例提供的对入账请求的处理的示意图，以下将结合图9B中的步骤301至步骤304对商户资源管理器处理入账请求的过程进行说明。

在步骤301中，商户资源管理器在处理入账请求S之前，通过进程I统计共享内存信息，检查入账请求S对应的商户账户是否被限流。

商户资源管理器中每个进程在内存中都有自己的专属共享内存，各个进程的专属共享内存构成了商户资源管理器的共享内存。若商户资源管理器将通过空闲的进程I处理入账请求S，则在进程I处理入账请求S之前，通过进程I与其他各个进程的交互，即，根据除进程I之外的其他各个进程(图9B中的进程B、进程C……进程N)的专属共享内存中记录的各个进程当前正在处理的请求，确定入账请求S对应的商户账户的其他正在被处理的入账请求所占用的连接数和连接池数量，若连接数超过第二连接数阈值，或连接池数量超过第二连接池数阈值，将该商户账户加入限流列表，并对该商户账户对应的入账请求进行限流处理，即对与该商户账户对应的待处理的入账请求以及后续新接收的入账请求进行延迟处理。

在步骤302中，若商户账户未被限流，商户资源管理器通过进程I将商户账户相关信息写入进程I的专属共享内存中。

若与该商户账户对应的入账请求所占用的连接数未超过第二连接数阈值，且与该商户账户对应的入账请求所占用的连接池的数量未超过第二连接池数阈值，则不对该商户账户进行限流处理，并通过进程I将该商户账户相关信息(如时间、商户账号等)写入进程I的专属共享内存中。

在步骤303中，商户资源管理器通过进程I处理入账请求S。

参见图11，图11是本申请实施例提供的入账请求处理的页面示意图，图11中，进程序号(proc_no)为20的进程正在处理商户账号(UID)为“101300000005000882”的入账请求，请求(sscmd)的编号为“999506”。

商户资源管理器通过进程I处理入账请求S的过程如下。对商户数据库中交易单的单号进行锁定处理；基于单号在商户数据库中查找与所读取的入账请求对应的商户账户流水；当未查找到商户账户流水时，从所读取的入账请求对应的商户账户的余额中增加转账金额，并生成商户账户流水；对交易单的单号进行解锁处理。

在步骤304中，商户资源管理器通过进程I清理进程I的专属共享内存。

进程I在处理完入账请求S后，清理进程I的专属共享内存中该商户账户的相关信息。

在一些实施例中，若与同一商户账户对应的包含预设命令字的入账请求的数量超过命令字阈值，也会对与同一商户账户对应的包含预设命令字的入账请求进行限流处理。

在一些实施例中，完成对商户账户的入账后，将异步缓存数据库中与该交易对应的商户账户的状态修改为已入账。至此，完成整个支付流程。

可见，在商户资源管理器中，通过第二连接数阈值、第二连接池数阈值和命令字阈值实现了对高并发请求(入账请求)的第三次削峰，避免针对同一商户账户的入账请求或包含同一命令字的请求占用商户资源管理器所有的进程，而无法响应其他业务请求。

下面说明本申请实施例提供的电子支付的处理设备的示例性结构，以电子支付的处理设备为服务器为例，根据对上文的理解，电子支付的处理设备可以是上文所述的事务服务器、用户服务器、异步服务器或商户服务器等类型的服务器，下面具体说明。

参见图12A，图12A是本申请实施例提供的服务器400的结构示意图，图12A所示的服务器400包括：至少一个处理器410、存储器440、至少一个网络接口420。服务器200中的各个组件通过总线系统430耦合在一起。可理解，总线系统430用于实现这些组件之间的连接通信。总线系统430除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统430。

处理器410可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

存储器440可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器440可选地包括在物理位置上远离处理器410的一个或多个存储设备。

存储器440包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器440旨在包括任意适合类型的存储器。

在一些实施例中，存储器440能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统441，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块442，用于经由一个或多个(有线或无线)网络接口420到达其他计算设备，示例性的网络接口420包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

在一些实施例中，本申请实施例提供的电子支付的处理装置443可以采用软件方式实现，图12A示出了存储在存储器440中的电子支付的处理装置443，其可以是程序和插件等形式的软件，包括以下软件模块：接收模块4431、扣款模块4432、生成模块4433、第一入账模块4434、第二入账模块4435，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。

接收模块4431，用于接收至少一个客户端的至少一个支付请求；扣款模块4432，用于对每个支付请求对应的用户账户执行扣款操作，向客户端发送扣款成功消息，并向支付请求对应的商户系统发送入账成功消息；生成模块4433，用于基于每个支付请求生成对应的入账请求，将入账请求分别存储到异步缓存数据库和分布式消息队列中；第一入账模块4434，用于从分布式消息队列中读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作；第二入账模块4435，用于当分布式消息队列处于不可用状态时，从异步缓存数据库中继续读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作。

在一些实施例中，电子支付的处理装置还包括限流模块4436，已经接收的支付请求的状态包括正在处理和待处理；限流模块4436，用于：当正在处理的支付请求占用的连接数超过第一连接数阈值，或正在处理的支付请求占用的连接池数量超过第一连接池数阈值时，将待处理的支付请求进行限流处理，并将待处理的支付请求对应的商户账户加入限流列表。

在一些实施例中，限流模块4436，还用于：当待处理的多个入账请求对应的商户账户在限流列表中时，对待处理的多个入账请求进行合并处理，并将合并处理得到的入账请求存储到与商户账户对应的临时队列中；当任一临时队列中的入账请求触发超时且入账请求数小于请求数阈值时，从限流列表中删除任一临时队列对应的商户账户，并对任一临时队列中的入账请求对应的商户账户执行入账操作。

在一些实施例中，第一入账模块4434，还用于：当任一临时队列中的入账请求数大于请求数阈值时，对任一临时队列中的入账请求对应的商户账户执行入账操作。

在一些实施例中，第一入账模块4434，还用于：基于正在被处理的入账请求所占用的内存信息，确定其他入账请求所占用的连接数和连接池数量；其中，其他入账请求是正在被处理的入账请求，且与待处理的入账请求对应同一商户账户；当其他入账请求所占用的连接数未超过第二连接数阈值，且其他入账请求所占用的连接池数量未超过第二连接池数阈值时，将待处理的入账请求中所携带的商户账户信息写入任意一个空闲进程的内存中；基于空闲进程对商户账户执行入账操作。

在一些实施例中，限流模块4436，还用于：当其他入账请求所占用的连接数超过第二连接数阈值，或其入账请求所占用的连接池数量超过第二连接池数阈值时，对待处理的入账请求进行限流处理，并将待处理的入账请求对应的商户账户加入限流列表。

在一些实施例中，限流模块4436，还用于：确定包含预设命令字的待处理的入账请求的数量；当包含预设命令字的待处理的入账请求的数量超过命令字阈值时，对包含预设命令字的待处理的入账请求进行限流处理，并将与包含预设命令字的待处理的入账请求对应的商户账户加入限流列表。

在一些实施例中，扣款模块4432，还用于：基于每个支付请求从用户数据库中查询对应的用户账户；从查询到的用户账户的余额中扣除支付请求中携带的转账金额，并生成用户账户流水；基于用户账户流水生成交易单。

在一些实施例中，第一入账模块4434，还用于：对商户数据库中交易单的单号进行锁定处理；基于单号在商户数据库中查找与所读取的入账请求对应的商户账户流水；当未查找到商户账户流水时，从所读取的入账请求对应的商户账户的余额中增加转账金额，并生成商户账户流水；对交易单的单号进行解锁处理。

在一些实施例中，第一入账模块4434，还用于：基于商户账户流水和用户账户流水对每个入账请求对应的交易进行核对处理，以确定每次交易中对用户账户扣款正确，且对商户账户入账正确。

在一些实施例中，接收模块4431，还用于：将支付请求的相关信息存储至日志中，以在异步缓存数据库、用户数据库或商户数据库处于不可用状态时，基于日志进行恢复处理。

在一些实施例中，第一入账模块4434，还用于：将异步缓存数据库中商户账户的状态由待入账修改为已入账。

需要说明的是，对于本申请实施例中的电子支付的处理设备而言，可以实施上述的全部模块，从而根据实际的部署情况有针对性地实施部分模块，以实现事务服务器、用户服务器、异步服务器或商户服务器的角色。

例如，当电子支付的处理设备实施接收模块和生成模块时，成为事务服务器的角色，当电子支付的处理设备实施扣款模块时，成为用户服务器的角色，当电子支付的处理设备实施第一入账模块和第二入账模块时，成为异步服务器和商户服务器的角色。

当然，服务器也可以根据具体的应用场景，只实施用于实现事务服务器、用户服务器、异步服务器或商户服务器中任意一个服务器的功能模块。

参见图12B，图12B是本申请实施例提供的终端500的结构示意图，以电子支付的处理设备是终端500为例，图12B所示的终端500包括：至少一个处理器510、存储器550、至少一个网络接口520和用户接口530。终端500中的各个组件通过总线系统540耦合在一起。用户接口530包括能够呈现媒体内容的一个或多个输出装置531，还包括一个或多个输入装置532。

在一些实施例中，存储器包括操作系统551、网络通信模块552、呈现模块553、输入处理模块554。本申请实施例提供的电子支付的处理装置555可以采用软件方式实现，图12B示出了存储在存储器550中的电子支付的处理装置555，其可以是程序和插件等形式的软件，包括以下软件模块：第一显示模块5551、第二显示模块5552，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。当然，本申请实施例提供的电子支付的处理装置555也可以采用硬件方式实现，本申请实施例在此不再赘述。

下面继续说明本申请实施例提供的电子支付的处理装置555实施为软件模块的示例性结构。在一些实施例中，如图12B所示，存储在存储器550的电子支付的处理装置555中的软件模块可以包括：第一显示模块5551、第二显示模块5552。

第一显示模块5551，用于在客户端中显示用于电子支付的页面；第二显示模块5552，用于响应于在页面中接收到针对商户系统的电子支付操作，发送针对商户系统的支付请求，实时显示扣款成功消息；其中，扣款成功消息是后台服务器对支付请求对应的用户账户执行扣款操作后发送，且针对商户系统的商户账户的入账操作是基于异步缓存数据库和分布式消息队列执行的。

需要说明的是，对于本申请实施例提供的电子支付的处理装置555中未尽的技术细节，可以根据图3至图9B任一附图的说明而理解。

本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得计算机设备执行本申请实施例上述的电子支付的处理方法。

本申请实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的电子支付的处理方法。

在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

综上所述，本申请实施例在完成对用户账户的扣款后，同时向用户的客户端和商户系统发送通知，可减少通知的时耗，提高用户和商户的转账体验。将入账请求保存在分布式消息队列中，降低了高并发的争用。同时将入账请求保存在异步缓存数据库中，有效地保证了入账请求相关数据的持久化和安全性，可在分布式消息队列不可用时，通过异步缓存数据库中存储的相关数据完成支付流程。通过用户资源管理器、异步入账服务、商户资源管理器对高并发请求进行动态限流，从而可在不扩容商户服务器的情况下，提升异步支付系统的性能，使异步支付系统的吞吐量最大化，保证了高峰期间重点商户的支付稳定性，也大大降低了运维的压力。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (15)

1.一种电子支付的处理方法，其特征在于，包括：

接收至少一个客户端的至少一个支付请求；

对每个所述支付请求对应的用户账户执行扣款操作，向所述客户端发送扣款成功消息，并向所述支付请求对应的商户系统发送入账成功消息；

基于每个所述支付请求生成对应的入账请求，将所述入账请求分别存储到异步缓存数据库和分布式消息队列中；

从所述分布式消息队列中读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作；

当所述分布式消息队列处于不可用状态时，从所述异步缓存数据库中继续读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作。

2.根据权利要求1所述的方法，其特征在于，已经接收的支付请求的状态包括正在处理和待处理；在所述对每个所述支付请求对应的用户账户执行扣款操作之前，所述方法还包括：

当正在处理的支付请求占用的连接数超过第一连接数阈值，或正在处理的支付请求占用的连接池数量超过第一连接池数阈值时，将待处理的支付请求进行限流处理，并将所述待处理的支付请求对应的商户账户加入限流列表。

3.根据权利要求2所述的方法，其特征在于，在所述从所述分布式消息队列中读取待处理的入账请求之后，所述方法还包括：

当待处理的多个入账请求对应的商户账户在所述限流列表中时，对所述待处理的多个入账请求进行合并处理，并将合并处理得到的入账请求存储到与所述商户账户对应的临时队列中；

当任一临时队列中的入账请求触发超时且入账请求数小于请求数阈值时，从所述限流列表中删除所述任一临时队列对应的商户账户，并对所述任一临时队列中的入账请求对应的商户账户执行入账操作。

4.根据权利要求3所述的方法，其特征在于，在所述将合并处理得到的入账请求存储到与所述商户账户对应的临时队列中之后，所述方法还包括：

当任一临时队列中的入账请求数大于所述请求数阈值时，对所述任一临时队列中的入账请求对应的商户账户执行入账操作。

5.根据权利要求2所述的方法，其特征在于，在所述从所述分布式消息队列中读取待处理的入账请求之后，所述方法还包括：

基于正在被处理的入账请求所占用的内存信息，确定其他入账请求所占用的连接数和连接池数量；

其中，所述其他入账请求是正在被处理的入账请求，且与所述待处理的入账请求对应同一商户账户；

当所述其他入账请求所占用的连接数未超过第二连接数阈值，且所述其他入账请求所占用的连接池数量未超过第二连接池数阈值时，将所述待处理的入账请求中所携带的商户账户信息写入任意一个空闲进程的内存中；

基于所述空闲进程对所述商户账户执行入账操作。

6.根据权利要求5所述的方法，其特征在于，在确定其他入账请求所占用的连接数和连接池数量之后，所述方法还包括：

当所述其他入账请求所占用的连接数超过所述第二连接数阈值，或所述其入账请求所占用的连接池数量超过所述第二连接池数阈值时，对所述待处理的入账请求进行限流处理，并将所述待处理的入账请求对应的商户账户加入所述限流列表。

7.根据权利要求2所述的方法，其特征在于，在所述从所述分布式消息队列中读取待处理的入账请求之后，所述方法还包括：

确定包含预设命令字的待处理的入账请求的数量；

当包含预设命令字的待处理的入账请求的数量超过命令字阈值时，对所述包含预设命令字的待处理的入账请求进行限流处理，并将与包含预设命令字的待处理的入账请求对应的商户账户加入所述限流列表。

8.根据权利要求1所述的方法，其特征在于，所述对每个所述支付请求对应的用户账户执行扣款操作，包括：

基于每个所述支付请求从用户数据库中查询对应的用户账户；

从查询到的用户账户的余额中扣除所述支付请求中携带的转账金额，并生成用户账户流水；

基于所述用户账户流水生成交易单。

9.根据权利要求8所述的方法，其特征在于，所述对所读取的入账请求对应的商户账户执行入账操作，包括：

对商户数据库中所述交易单的单号进行锁定处理；

基于所述单号在所述商户数据库中查找与所读取的入账请求对应的商户账户流水；

当未查找到所述商户账户流水时，从所读取的入账请求对应的商户账户的余额中增加所述转账金额，并生成商户账户流水；

对所述交易单的单号进行解锁处理。

10.根据权利要求9所述的方法，其特征在于，在所述对所读取的入账请求对应的商户账户执行入账操作之后，所述方法还包括：

基于所述商户账户流水和所述用户账户流水对每个入账请求对应的交易进行核对处理，以确定每次交易中对所述用户账户扣款正确，且对所述商户账户入账正确。

11.根据权利要求10所述的方法，其特征在于，在接收至少一个客户端的至少一个支付请求之后，所述方法还包括：

将所述支付请求的相关信息存储至日志中，以在所述异步缓存数据库、所述用户数据库或所述商户数据库处于不可用状态时，基于所述日志进行恢复处理；

在所述对所读取的入账请求对应的商户账户执行入账操作之后，所述方法还包括：

将所述异步缓存数据库中所述商户账户的状态由待入账修改为已入账。

12.一种电子支付的处理方法，其特征在于，包括：

在客户端中显示用于电子支付的页面；

响应于在所述页面中接收到针对商户系统的电子支付操作，发送针对所述商户系统的支付请求，实时显示扣款成功消息；

其中，所述扣款成功消息是后台服务器对所述支付请求对应的用户账户执行扣款操作后发送，且针对所述商户系统的商户账户的入账操作是基于异步缓存数据库和分布式消息队列执行的。

13.一种电子支付的处理装置，其特征在于，包括：

接收模块，用于接收至少一个客户端的至少一个支付请求；

扣款模块，用于对每个所述支付请求对应的用户账户执行扣款操作，向所述客户端发送扣款成功消息，并向所述支付请求对应的商户系统发送入账成功消息；

生成模块，用于基于每个所述支付请求生成对应的入账请求，将所述入账请求分别存储到异步缓存数据库和分布式消息队列中；

第一入账模块，用于从所述分布式消息队列中读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作；

第二入账模块，用于当所述分布式消息队列处于不可用状态时，从所述异步缓存数据库中继续读取待处理的入账请求，并对所读取的入账请求对应的商户账户执行入账操作。

14.一种电子设备，其特征在于，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至11任一项、或权利要求12所述的电子支付的处理方法。

15.一种计算机可读存储介质，其特征在于，存储有可执行指令，用于引起处理器执行如权利要求1至11任一项、或权利要求12所述的电子支付的处理方法。

Images