重新发起业务请求的执行方法及执行装置

摘要

本申请公开了一种重新发起业务请求的执行方法及执行装置，所述执行方法包括：在确定用户的第一业务请求异常且请求处理时间大于第一预设时间的情况下，生成用户的第二业务请求，其中，第二业务请求用于请求对虚拟资源进行变更，第二业务请求为与第一业务请求相同的业务请求，第二业务请求包括用户的身份信息、请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量；基于用户的身份信息，判断是否为第二业务请求发起等待动作；在确定为第二业务请求发起等待动作的情况下，基于请求时间信息、虚拟资源的类型和虚拟资源的数量，确定与第二业务请求对应的等待时间；在等待时间后，执行与第二业务请求对应的业务操作。

说明书

技术领域

本申请涉及业务请求领域，尤其涉及一种重新发起业务请求的执行方法及执行装置。

背景技术

传统的分布式系统下保证数据一致性主要包括以下方法：1)加大数据库的事务隔离级别，将数据库的事务隔离级别设置为读已提交(Read committed)，这种事务隔离级别不会引起脏读，但会引起行级别的锁，当一个事务更新余额、未提交时，另一个事务无法读取也无法更新余额。2)在用户余额表中加入版本号字段，每次更新余额前，先将版本号取出，更新余额的时候在where条件后加上的版本号等于先前取出的版本号，并对版本号重新赋值。

但是，前述两种方式在大并发下会引起大量事务超时或更新余额失败，导致用户业务请求失败，而在导致用户业务请求失败，重新发起业务请求的情况下，针对不同产品，业务请求重新执行的等待时间是固定的，影响用户体验。

发明内容

本申请公开一种重新发起业务请求的执行方法及执行装置，解决了在重新发起业务请求的情况下，针对不同产品，业务请求重新执行的等待时间是固定的，影响用户体验的问题。

为了解决上述问题，本申请采用下述技术方案：

第一方面，本申请实施例公开一种重新发起业务请求的执行方法，包括：在确定用户的第一业务请求异常且请求处理时间大于第一预设时间的情况下，生成所述用户的第二业务请求，其中，所述第二业务请求用于请求对虚拟资源进行变更，所述第二业务请求为与所述第一业务请求相同的业务请求，所述第二业务请求包括所述用户的身份信息、请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量；基于所述用户的身份信息，判断是否为所述第二业务请求发起等待动作；在确定为所述第二业务请求发起等待动作的情况下，基于所述请求时间信息、所述虚拟资源的类型和所述虚拟资源的数量，确定与所述第二业务请求对应的等待时间；在所述等待时间后，执行与所述第二业务请求对应的业务操作。

第二方面，本申请实施例公开一种重新发起业务请求的执行装置，包括：生成模块，用于在确定用户的第一业务请求异常且请求处理时间大于第一预设时间的情况下，生成所述用户的第二业务请求，其中，所述第二业务请求用于请求对虚拟资源进行变更，所述第二业务请求为与所述第一业务请求相同的业务请求，所述第二业务请求包括所述用户的身份信息、请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量；判断模块，用于基于所述用户的身份信息，判断是否为所述第二业务请求发起等待动作；第一确定模块，用于在确定为所述第二业务请求发起等待动作的情况下，基于所述请求时间信息、所述虚拟资源的类型和所述虚拟资源的数量，确定与所述第二业务请求对应的等待时间；执行模块，用于在所述等待时间后，执行与所述第二业务请求对应的业务操作。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括处理器和存储器，所述存储器存储可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的方法的步骤。

第四方面，本申请实施例提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤。

本申请采用的技术方案能够达到以下有益效果：

本申请实施例提供一种重新发起业务请求的执行方法，通过在确定用户的第一业务请求异常且请求处理时间大于第一预设时间的情况下，生成与第一业务请求相同的第二业务请求，其中，第二业务请求包括用户的身份信息、请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量，然后基于用户的身份信息，判断是否为第二业务请求发起等待动作，在确定为第二业务请求发起等待动作的情况下，基于请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量，确定与第二业务请求对应的等待时间，在等待时间后，执行与第二业务请求对应的业务操作。本申请通过基于请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量，确定与第二业务请求对应的等待时间，能够根据第二业务请求的具体情况，确定与第二业务请求对应的等待时间，进而提升用户体验。

附图说明

图1为本申请实施例公开的一种重新发起业务请求的执行方法的流程示意图；

图2为本申请实施例公开的一种第一业务请求的执行流程图；

图3为本申请实施例公开的一种重新发起业务请求的执行装置的结构示意图；

图4为本申请实施例公开的电子设备的一种结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所电连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例公开的重新发起业务请求的执行方法及执行装置进行详细地说明。

图1为本申请实施例公开的一种重新发起业务请求的执行方法的流程示意图，该方法可以由电子设备执行，该电子设备可以包括：服务器和/或终端设备。换言之，该方法可以由安装在电子设备的软件或硬件来执行，该方法包括如下步骤：

S120、在确定用户的第一业务请求异常且请求处理时间大于第一预设时间的情况下，生成所述用户的第二业务请求。

其中，所述第二业务请求用于请求对虚拟资源进行变更，所述第二业务请求为与所述第一业务请求相同的业务请求，所述第二业务请求包括所述用户的身份信息、请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量。

在本申请中，在确定用户的第一业务请求异常且请求处理时间大于第一预设时间的情况下，生成用户的第二业务请求，业务系统服务器在收到第二业务请求的情况下，将第二业务请求反馈给重新执行模块，重新执行模块记录并存储第二业务请求，并根据第二业务请求中包括的用户的身份信息、请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量，对是否为第二业务请求发起等待动作，以及与第二业务请求对应的等待时间进行确定。

S140、基于所述用户的身份信息，判断是否为所述第二业务请求发起等待动作。

示例性的，可以通过用户的身份信息，获取与用户的身份信息对应的业务请求记录，进而判断是否为第二业务请求发起等待动作。

S160、在确定为所述第二业务请求发起等待动作的情况下，基于所述请求时间信息、所述虚拟资源的类型和所述虚拟资源的数量，确定与所述第二业务请求对应的等待时间。

在本申请中，若请求时间为用户活跃度高的时间，同时请求的虚拟资源的类型不是新的类型、请求的虚拟资源的数量大于第一预设阈值的情况下，与第二业务请求对应的等待时间为第一时间值；若请求时间为用户活跃度较低的时间，同时请求的虚拟资源的类型不是新的类型、请求的虚拟资源的数量大于第一预设阈值的情况下，与第二业务请求对应的等待时间为第二时间值；若请求时间为用户活跃度高的时间，同时请求的虚拟资源的类型是新的类型、请求的虚拟资源的数量大于第一预设阈值的情况下，与第二业务请求对应的等待时间为第三时间值；若请求时间为用户活跃度较低的时间，同时请求的虚拟资源的类型是新的类型、请求的虚拟资源的数量大于第一预设阈值的情况下，与第二业务请求对应的等待时间为第四时间值。

在一般情况下，在用户活跃度高的时间，请求对虚拟资源变更的数量大于第一预设阈值，相对而言，属于正常业务请求，若该业务请求异常，系统会通过再次提交业务请求，来保证业务请求执行成功，但若在用户活跃度较低的时间，请求对虚拟资源变更的数量大于第一预设阈值，则系统不再提供重新执行业务请求，以此降低误操作。对应的，在用户活跃度较低的时间，请求的虚拟资源的数量大于第一预设阈值的情况下，可以将与第二业务请求对应的等待时间赋值为无穷(即不再提供第二业务请求)。

在本申请中，用户活跃度高和用户活跃度较低所分别对应的数值大小或数值范围可以根据具体情况系进行设置。本申请也不对第一预设阈值的具体数值进行限定。

示例性的，业务请求可以为购买请求，请求时间可以包括用户购买行为活跃度较高的时间和用户购买行为活跃度较低的时间，请求的虚拟资源的类型可以为是否购买新的套餐，请求的虚拟资源的数量可以为话费充值的数额。其中，用户购买行为活跃度可以通过k-means聚类平台下用户购买行为-时间来得到。

对应的，若用户的请求时间为购买行为活跃度较高的时间，同时用户购买的行为不是重新购买新的套餐、大于500元话费充值，与第二购买请求对应的等待时间为A1秒；若用户的请求时间为购买行为活跃度较低的时间，同时用户购买的行为不是重新购买新的套餐、大于500元话费充值，与第二购买请求对应的等待时间为B1秒；若用户的请求时间为购买行为活跃度较高的时间，同时用户购买的行为是重新购买新的套餐、大于500元话费充值，与第二购买请求对应的等待时间为A2秒；若用户的请求时间为购买行为活跃度较低的时间，同时用户购买的行为是重新购买新的套餐、大于500元话费充值，与第二购买请求对应的等待时间为B2秒。

S180、在所述等待时间后，执行与所述第二业务请求对应的业务操作。

本申请实施例提供一种重新发起业务请求的执行方法，通过在确定用户的第一业务请求异常且请求处理时间大于第一预设时间的情况下，生成与第一业务请求相同的第二业务请求，其中，第二业务请求包括用户的身份信息、请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量，然后基于用户的身份信息，判断是否为第二业务请求发起等待动作，在确定为第二业务请求发起等待动作的情况下，基于请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量，确定与第二业务请求对应的等待时间，在等待时间后，执行与第二业务请求对应的业务操作。本申请通过基于请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量，确定与第二业务请求对应的等待时间，能够根据第二业务请求的具体情况，确定与第二业务请求对应的等待时间，进而提升用户体验。

在一种可能实现的方案中，在所述确定与所述第二业务请求对应的等待时间之后，且在所述等待时间后，执行与所述第二业务请求对应的业务操作之前，还可以包括：获取所述用户在第二预设时间内发起第一业务请求的频率；基于所述频率，对所述等待时间进行调整。由于考虑到用户在第二预设时间内发起业务请求的频率过高的话，有可能是出现了误操作行为，而用户在第二预设时间内发起业务请求的频率较低的话，应该为正常操作，因此，可以统计用户在第二预设时间内发起第一业务请求的频率，在第二预设时间内发起第一业务请求的频率高于第二预设阈值的情况下，保持基于请求时间信息、虚拟资源的类型和虚拟资源的数量，确定的与第二业务请求对应的等待时间；在第二预设时间内发起第一业务请求的频率低于第二预设阈值的情况下，在基于请求时间信息、虚拟资源的类型和虚拟资源的数量，确定的与第二业务请求对应的等待时间的基础上，缩短等待时间。本申请通过对于第二业务请求对应的等待时间进行调整，可以使用户尽早完成操作，减少用户等待。

在本申请实施例中，在所述对所述等待时间进行调整之后，还可以包括：确定所述第一业务请求的中断位置；基于所述中断位置，对调整后的所述等待时间再次进行调整。示例性的，由于重新执行模块会不间断的查询处理进度，因此，若发现第一业务请求是在还未发送给业务系统服务器的情况下中断的，则在基于频率，对等待时间进行调整的基础上，增加等待时长，需要说明的是，此时发生的中断，可能是由于用户的网络不畅导致的，若第一业务请求的中断是发生在消息队列组件中或者是由于第一业务请求未送达到数据库，则在基于频率，对等待时间进行调整的基础上，减少等待时长，需要说明的是，此时发生的中断，可能是由于系统信息调度以及数据同步问题导致的中断。本申请通过对于第二业务请求对应的等待时间再次进行调整，可以使用户尽早完成操作，减少用户等待。

此外，通过对不同场景下的第二业务请求的等待时间进行调整，还可以减小系统压力。

在一种实现方式中，所述基于所述用户的身份信息，判断是否为所述第二业务请求发起等待动作，可以包括：获取与所述用户的身份信息对应的历史业务请求记录；根据所述历史业务请求记录，确定所述用户的业务请求等级；基于所述用户的业务请求等级，判断是否为所述第二业务请求发起等待动作。其中，历史业务请求记录可以为服务器基于用户的身份信息通过调取获得的。

基于所述用户的业务请求等级，判断是否为所述第二业务请求发起等待动作，可以包括：在用户的业务请求等级大于第三预设阈值的情况下，确定为第二业务请求发起等待动作。

示例性的，在所述业务请求为购买请求的情况下，可以基于用户的身份信息，获取与用户的身份信息对应的历史购买请求记录，根据历史购买请求记录，确定用户的信用等级，在用户的信用等级为良好的情况下，确定为第二购买请求发起等待动作。

在本申请实施例中，在所述在确定用户的第一业务请求异常且请求处理时间大于第一预设时间的情况下，生成所述用户的第二业务请求之前，还可以包括：接收用户的第一业务请求；生成与所述第一业务请求对应的业务请求日志表，并将所述业务请求日志表发送至数据库和消息队列中间件，其中，所述业务请求日志表包括用户标识和业务处理状态；在所述业务请求日志表保存至数据库的情况下，将所述第一业务请求发送至消息队列中间件；执行与所述第一业务请求对应的业务操作，并对所述业务处理状态进行更新；基于所述业务处理状态，判断所述第一业务请求是否处理成功。

如图2所示，业务系统服务器接收客户端(用户)发起的第一业务请求，基于第一业务请求，业务系统服务器生成与第一业务请求对应的业务请求日志表，并将业务请求日志表发送至数据库和消息队列中间件，其中，业务请求日志表包括业务编号、用户标识、创建时间、业务处理状态、更新时间和业务类型。需要说明的是，在将业务请求日志表刚保存到数据库时，业务处理状态设置为0，即业务未处理，更新时间先设置为空，将业务编号作为业务请求日志表的主键。

在业务请求日志表保存至数据库失败的情况下，返回给客户端第一业务请求处理失败。在业务请求日志表保存至数据库的情况下，如图2所示，业务系统服务器将第一业务请求发送至消息队列中间件，其中，消息队列中间件可以为由软件实现的缓存空间。

如图2所示，业务服务从消息队列中间件取出第一业务请求，执行与第一业务请求对应的业务操作，并对业务处理状态进行更新，更新后的业务处理状态为1。示例性的，在业务请求为购买请求的情况下，在执行与第一业务请求对应的业务操作后，分别对业务处理状态、用户余额和用户余额变更表进行更新，将更新业务处理状态、用户余额和用户余额变更表放在同一个事务中。需要说明的是，通过更新用户余额来保存用户的账户信息，通过更新用户余额变更表来跟踪用户余额的变更情况，且用户余额变更表的主键与业务请求日志表的主键相同。

考虑到第一业务请求可能会失败，可以使用专门后台线程扫描业务请求日志表中的业务处理状态，基于业务处理状态，判断第一业务请求是否处理成功。示例性的，在确定业务处理状态为0，即第一业务请求未成功处理，且请求处理时间大于第一预设时间的情况下，生成用户的第二业务请求。

在一种可能实现的方式中，在业务请求量大的情况下，可以增加消息队列中间件的数量，通过多个消息队列中间件同时处理业务，以缩短业务处理时间。在本申请中，在所述第一业务请求为多个，所述消息队列中间件为多个的情况下，所述将所述第一业务请求发送至消息队列中间件，可以包括：分别通过多个所述用户标识中的各个所述用户标识对所述消息队列中间件个数取模，确定多个目标值；基于预先设定的所述目标值与所述消息队列中间件IP地址的对应关系，确定与多个所述目标值分别对应的所述IP地址；将相同所述IP地址对应的所述第一业务请求发送至与相同所述IP地址对应的消息队列中间件。

需要说明的是，在第一业务请求为多个的情况下，与第一业务请求对应的业务请求日志表也为多个，进而业务请求日志表中的用户标识也为多个。另外，多个消息队列中间件可以部署在同一台服务器，也可以每个消息队列中间件单独部署在一台服务器，将每个消息队列中间件单独部署在一台服务器，可以防止服务器断电导致的多个消息队列中间件不可用的问题。

示例性的，可以通过如下规则进行取模：mod＝userId％消息队列中间件个数，例如，在消息队列中间件为5个的情况下，不管用户标识为多少，取模后得到的目标值已定位0、1、2、3、4中的某一个值，在预先设定的目标值与消息队列中间件互联网协议(InternetProtocol，IP)地址的对应关系如表1所示的情况下，假设用户标识为6000000，通过mod＝6000000％5，得到目标值为0，则对应的IP地址则为192.168.110.61。

表1目标值与消息队列中间件IP地址对应关系表

在确定出各个目标值分别对应的IP地址之后，将相同IP地址对应的第一业务请求发送至与该相同IP地址对应的消息队列中间件。例如，可以将IP地址为192.168.110.61的第一业务请求发送至与IP地址192.168.110.61对应的消息队列中间件。

上述方式在实质上为将同一用户的业务请求映射到同一消息队列中间件，而将同一用户的业务请求映射到同一消息队列中间件，能够避免数据库并发导致的破坏数据一致性问题。

另外，消息队列中间件采用hash策略，支持无线扩容，对消息的处理速度可以控制到秒级以内。

本申请实施例提供的重新发起业务请求的执行方法，执行主体可以为重新发起业务请求的执行装置。本申请实施例中以重新发起业务请求的执行装置执行重新发起业务请求的执行方法为例，说明本申请实施例提供的重新发起业务请求的执行方法的装置。

图3为本申请实施例公开的一种重新发起业务请求的执行装置的结构示意图。如图3所示，重新发起业务请求的执行装置300包括：生成模块310、判断模块320、第一确定模块330和执行模块340。

在本申请中，生成模块310，用于在确定用户的第一业务请求异常且请求处理时间大于第一预设时间的情况下，生成所述用户的第二业务请求，其中，所述第二业务请求用于请求对虚拟资源进行变更，所述第二业务请求为与所述第一业务请求相同的业务请求，所述第二业务请求包括所述用户的身份信息、请求时间信息、请求的虚拟资源的类型和请求的虚拟资源的数量；判断模块320，用于基于所述用户的身份信息，判断是否为所述第二业务请求发起等待动作；第一确定模块330，用于在确定为所述第二业务请求发起等待动作的情况下，基于所述请求时间信息、所述虚拟资源的类型和所述虚拟资源的数量，确定与所述第二业务请求对应的等待时间；执行模块340，用于在所述等待时间后，执行与所述第二业务请求对应的业务操作。

在一种实现方式中，所述执行装置还包括：获取模块，用于在所述确定与所述第二业务请求对应的等待时间之后，且在所述等待时间后，执行与所述第二业务请求对应的业务操作之前，获取所述用户在第二预设时间内发起第一业务请求的频率；调整模块，用于基于所述频率，对所述等待时间进行调整。

在一种实现方式中，所述执行装置还包括：第二确定模块，用于在所述对所述等待时间进行调整之后，确定所述第一业务请求的中断位置；所述调整模块，还用于基于所述中断位置，对调整后的所述等待时间再次进行调整。

在一种实现方式中，所述判断模块320基于所述用户的身份信息，判断是否为所述第二业务请求发起等待动作，包括：获取与所述用户的身份信息对应的历史业务请求记录；根据所述历史业务请求记录，确定所述用户的业务请求等级；基于所述用户的业务请求等级，判断是否为所述第二业务请求发起等待动作。

在一种实现方式中，所述执行装置还包括：接收模块，用于在所述在确定用户的第一业务请求异常且请求处理时间大于第一预设时间的情况下，生成所述用户的第二业务请求之前，接收用户的第一业务请求；所述生成模块310，还用于生成与所述第一业务请求对应的业务请求日志表，并将所述业务请求日志表发送至数据库和消息队列中间件，其中，所述业务请求日志表包括用户标识和业务处理状态；发送模块，用于在所述业务请求日志表保存至数据库的情况下，将所述第一业务请求发送至消息队列中间件；所述执行模块340，还用于执行与所述第一业务请求对应的业务操作，并对所述业务处理状态进行更新；所述判断模块320，还用于基于所述业务处理状态，判断所述第一业务请求是否处理成功。

在一种实现方式中，在所述第一业务请求为多个，所述消息队列中间件为多个的情况下，所述发送模块将所述第一业务请求发送至消息队列中间件，包括：分别通过多个所述用户标识中的各个所述用户标识对所述消息队列中间件个数取模，确定多个目标值；基于预先设定的所述目标值与所述消息队列中间件IP地址的对应关系，确定与多个所述目标值分别对应的所述IP地址；将相同所述IP地址对应的所述第一业务请求发送至与相同所述IP地址对应的消息队列中间件。

本申请实施例提供的重新发起业务请求的执行装置能够实现重新发起业务请求的执行方法实施例实现的各个过程，为避免重复，这里不再赘述。

可选地，如图4所示，本申请实施例还提供一种电子设备400，包括处理器401和存储器402，存储器402上存储有可在所述处理器401上运行的程序或指令，该程序或指令被处理器401执行时实现上述重新发起业务请求的执行方法实施例的各个步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，本申请实施例中的电子设备包括上述所述的移动电子设备和非移动电子设备。

本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述重新发起业务请求的执行方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器ROM、随机存取存储器RAM、磁碟或者光盘等。

本申请上文实施例中重点描述的是各个实施例之间的不同，各个实施例之间不同的优化特征只要不矛盾，均可以组合形成更优的实施例，考虑到行文简洁，在此则不再赘述。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。