CN115098234A - 一种业务回调服务的控制方法、装置、系统及存储介质 - Google Patents

Abstract

本发明提供了一种业务回调服务的控制方法、装置、系统及存储介质，其中所述方法包括：服务提供端接收到业务端发出的业务请求后，向回调系统发送与业务请求对应的回调请求；回调系统接收到所述回调请求后，将回调请求存入内存队列中；回调系统通过回调线程池，根据内存队列中的回调请求，对所述回调地址对应的业务端执行回调任务。本发明通过设置一独立的回调系统，独立处理回调服务，将回调请求存入内存队列中，并根据回调线程池对业务端进行执行回调任务。本发明所提供的回调服务的实现方式中，业务端和服务提供端均无需进行回调服务的处理，而只需回调系统独立处理，方法简单，能够保证高性能性、高可用性和高稳定性。

Description

一种业务回调服务的控制方法、装置、系统及存储介质

技术领域

本发明涉及业务回调技术领域，更具体地说，涉及一种业务回调服务的控制方法、装置、系统及存储介质。

背景技术

系统中，很多业务场景处理耗时较长，所以一般将业务执行异步化，从而减轻客户端的等待压力。

但由于异步化或任务化，必然涉及到一个完成时间点的感知问题，而最简单和直接的方法是使用回调和主动轮询的方法。其中，主动轮询的方式会加大调用方的实现难度，而回调服务则可以及时有效地告知相关方，从而使其可以推进下一步的操作。因此，实现一个稳定可靠的回调，就变得非常重要。

常规的回调实现方式中，一般是在任务执行成功之后直接进行同步回调，这种实现方式往往带来较多问题。一方面，客户端会需要自己关注大量的异常情况及其处理，如客户端必须要使用推拉方式结合，方能完成一个基础功能；另一方面，需要增加很多的复杂的逻辑方法于业务代码中，导致整体系统逻辑耦合比较严重。

总之，现有的回调服务实现方式中，需要客户端自己关注大量异常情况及其处理，并且业务代码中需要增加很多的复杂的逻辑方法，造成系统逻辑耦合严重。

发明内容

有鉴于此，本发明提供一种业务回调服务的控制方法，包括：

服务提供端接收到业务端发出的业务请求后，向回调系统发送与所述业务请求对应的回调请求；其中，所述回调请求包括所述业务端对应的回调地址；

所述回调系统接收到所述回调请求后，将所述回调请求存入内存队列中；

所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务。

优选地，所述将所述回调请求存入内存队列中之前，还包括：

所述回调系统接收到所述回调请求后，将所述回调请求插入数据库中，并赋予待处理的执行状态标签；

所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务之后，还包括：

所述回调系统的所述回调任务执行完成之后，将所述执行状态标签变更为回调成功。

优选地，所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务，包括：

所述回调系统判断所述回调线程池中的执行线程的数量是否已达到预设最大数量；

若是，则将所述执行状态标签变更为等待调度，并根据所述等待调度的执行状态标签将所述回调请求挂起；

若否，则将所述回调请求插入所述回调线程池的执行线程内，以便于根据所述执行线程中的所述回调请求对所述业务端执行回调任务。

优选地，所述回调线程池中，所述执行线程的所述预设最大数量的计算方法为：

预设最大数量＝系统并发度×每秒可执行回调任务数×预设可接受延迟时间。

优选地，所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务之后，还包括：

所述回调系统获取所述服务提供端根据所述业务端的业务请求的执行情况所返回的响应信息；

若所述响应信息为业务执行成功，则判定执行状态为回调任务执行完成，以便于将所述执行状态标签变更为回调成功。

优选地，所述回调系统获取所述服务提供端根据所述业务端的业务请求的执行情况所返回的响应信息之后，还包括：

若所述响应信息并非为业务执行成功，则判定执行状态为回调任务执行异常；

所述回调系统接收所述服务提供端根据所述业务端的业务请求的执行情况所返回重复回调指令，以便于根据所述重复回调指令对所述业务端执行回调任务。

优选地，所述回调系统接收所述服务提供端根据所述业务端的业务请求的执行情况所返回重复回调指令之后，还包括：

所述回调系统根据预设的所述回调任务执行异常的执行状态的次数与时间的对应关系，获取与所述回调任务执行异常的执行状态的次数对应的当前次的时间间隔；

所述回调系统根据所述当前次的时间间隔对所述业务端执行回调任务，并返回执行所述回调系统获取所述服务提供端根据所述业务端的业务请求的执行情况所返回的响应信息；

其中，所述当前次的时间间隔大于前一次的时间间隔。

优选地，所述业务回调服务的控制还包括：

所述回调系统接收平台的关机/重启指令；

接收到所述关机/重启指令后，所述回调系统获取所述内存队列中的回调请求，并将所述内存队列中的回调请求存入数据库中成一数据包，并对所述数据包设置一待分配状态标签，以便于所述回调系统根据所述待分配状态标签获取所述数据库中的所述数据包至所述内存队列中。

优选地，所述回调系统根据随机休眠时间作为启动时间间隔，启动扫描守护线程；

所述回调系统基于所述扫描守护线程判断所述数据库中是否存在与所述回调系统对应且所述状态标签为待处理的数据包；

若是，则所述回调系统调取所述数据包至所述内存队列中，删除所述待分配状态标签。

优选地，所述回调系统接收到所述回调请求后，将所述回调请求存入内存队列中之前，还包括：

所述回调系统对所接收到所述回调请求设定一对应的回调ID；

所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务，还包括：

所述回调系统通过所述回调线程池中的所述回调请求，向所述业务端发送与所述回调任务对应的回调信息；其中所述回调信息中包括所述回调ID；

所述业务端接收到所述回调信息后，获取所述回调信息对应的回调ID；

所述业务端判断所述回调ID是否与先前已经接收到的回调信息的回调ID相同；

若是，则判定当前所接收到的所述回调信息为无效回调；

若否，则判定当前所接收到的所述回调信息为有效回调，并根据所述回调信息向所述回调系统返回一对应的有效回调响应信息。

此外，为解决上述问题，本发明还提供一种业务回调服务的控制装置，包括：

请求模块，用于服务提供端接收到业务端发出的业务请求后，向回调系统发送与所述业务请求对应的回调请求；其中，所述回调请求包括所述业务端对应的回调地址；

存储模块，用于所述回调系统接收到所述回调请求后，将所述回调请求存入内存队列中；

执行模块，用于所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务。

此外，为解决上述问题，本发明还提供一种业务回调服务的控制系统，包括业务端、服务提供端和回调系统；其中，至少所述回调系统中设有存储器以及处理器，所述存储器用于存储业务回调服务的控制程序，所述处理器运行所述业务回调服务的控制程序以使所述业务回调服务的控制系统执行如上述所述的业务回调服务的控制方法。

此外，为解决上述问题，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有业务回调服务的控制程序，所述业务回调服务的控制程序被处理器执行时实现如上述所述的业务回调服务的控制方法。

本发明提供了一种业务回调服务的控制方法、装置、系统及存储介质，其中，所述方法包括：服务提供端接收到业务端发出的业务请求后，向回调系统发送与所述业务请求对应的回调请求；其中，所述回调请求包括所述业务端对应的回调地址；所述回调系统接收到所述回调请求后，将所述回调请求存入内存队列中；所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务。本发明通过设置一独立的回调系统，独立处理回调服务，将回调请求存入内存队列中，并根据回调线程池对业务端进行执行回调任务。本发明所提供的回调服务的实现方式中，业务端和服务提供端均无需进行回调服务的处理，而只需回调系统独立处理，方法简单，能够保证高性能性、高可用性和高稳定性。

附图说明

图1为本发明业务回调服务的控制方法实施例涉及的硬件运行环境的结构示意图；

图2为本发明业务回调服务的控制方法第1实施例的流程示意图；

图3为本发明业务回调服务的控制方法第2实施例的流程示意图；

图4为本发明业务回调服务的控制方法第2实施例中步骤S300细化的流程示意图；

图5为本发明业务回调服务的控制方法第3实施例中步骤S300之后步骤的流程示意图；

图6为本发明业务回调服务的控制方法第4实施例中步骤S1100和步骤S1200的流程示意图；

图7为本发明业务回调服务的控制方法第4实施例中步骤S1300-步骤S1500的流程示意图；

图8为本发明业务回调服务的控制方法第5实施例的流程示意图；

图9为本发明业务回调服务的控制装置的模块连接示意图。

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

具体实施方式

下面详细描述本发明的实施例，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

在本发明中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

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

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

本发明实施例业务回调服务的控制系统，可以为PC，也可以是智能手机、平板电脑或者便携计算机等可移动式终端设备等。该业务回调服务的控制系统中可以包括：处理器1001、例如CPU，网络接口1004、用户接口1003、存储器1005和通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏、输入单元比如键盘、遥控器，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。可选地，业务回调服务的控制系统还可以包括RF(Radio Frequency，射频)电路、音频电路、WiFi模块等等。此外，该业务回调服务的控制系统还可配置陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

本领域技术人员可以理解，图1中示出的业务回调服务的控制系统并不构成对其的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。如图1所示，作为一种计算机可读存储介质的存储器1005中可以包括操作系统、数据接口控制程序、网络连接程序以及业务回调服务的控制程序。

实施例1：

参照图2，本发明第1实施例提供一种业务回调服务的控制方法，包括：

步骤S100，服务提供端接收到业务端发出的业务请求后，向回调系统发送与所述业务请求对应的回调请求；其中，所述回调请求包括所述业务端对应的回调地址；

上述，本实施例中所提供的方法，应用于业务端(被调用方、客户端)、服务提供端(服务方)与回调系统(调用方、回调方)三端之间。其中，业务端、服务提供端和回调系统三端通过网络以有线方式或无线方式实现连接，并进行数据交互。

上述，业务端首先与服务提供端进行数据交互通信时，首先要向服务提供端发出业务请求。进而服务提供端接收到该业务请求，并向回调系统发送一回调请求，该回调请求与业务请求相对应。

上述，回调地址能够表征业务端的唯一性，回调系统能够根据回调地址查询到对应的业务端。

上述，所述回调系统的前置，是由SLB网络接入，属于集群均衡的接入。

步骤S200，所述回调系统接收到所述回调请求后，将所述回调请求存入内存队列中；

上述，内存队列为回调系统中的本地化的用于存储需要进行执行的回调的存储于内存中的队列。

上述，回调系统在收到回调请求后，就存入内存队列中。

步骤S300，所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务。

上述，回调线程池，为基于内存队列中的回调请求，根据一定策略进行分别向业务端执行回调任务，发送回调信息的线程池。

由上述可见，在回调服务中，至少设有一内存队列，以及与该内存队列具有连接关系的回调线程池。

本实施例通过设置一独立的回调系统，独立处理回调服务，将回调请求存入内存队列中，并根据回调线程池对业务端进行执行回调任务。本实施例所提供的回调服务的实现方式中，业务端和服务提供端均无需进行回调服务的处理，业务端只需简单提交一个处理请求，然后停止动作，直到处理完成后，由回调系统驱动其后续业务。而服务提供端也只是在完成处理动作后，交给回调系统去完成后续的回调动作。本实施例所提供方法，因无需回调系统关注外部因素，而只需回调系统独立处理回调线程，方法简单，能够保证高性能性、高可用性和高稳定性。

实施例2：

参照图3，本发明第2实施例提供一种业务回调服务的控制方法，基于上述实施例1，所述步骤S200，将所述回调请求存入内存队列中之前，还包括：

步骤S400，所述回调系统接收到所述回调请求后，将所述回调请求插入数据库中，并赋予待处理的执行状态标签；

数据库中的回调请求为用于备份的数据。该备份步骤可以在插入内存队列之前，也可以与插入内存队列同时。

所述步骤S300，回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务之后，还包括：

步骤S500，所述回调系统的所述回调任务执行完成之后，将所述执行状态标签变更为回调成功。

执行状态标签表征了当前的回调请求对应的状态和过程。执行状态标签可以包括待处理和回调成功。

其中，如果执行状态标签为待处理则可以代表该回调请求尚未进行回调处理，回调系统可以将该执行状态标签为待处理的回调请求放入本地内存队列中，优先本地内存队列中的线程池进行调度，此时回调系统根据接收到的回调请求的进一步处理对应的回调工作，在正常情况下回调任务处理时间很短，如果处理完成则回调系统中把执行状态标签改为成功，表示事务处理完成。

进一步的，参考图4，所述步骤S300，回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务，包括：

步骤S310，所述回调系统判断所述回调线程池中的执行线程的数量是否已达到预设最大数量；

上述，在一个回调线程池中，其执行线程的数量根据系统的硬件、网络环境等因素，其数量是有限个数。因此，在进行回调时，在插入该回调线程池之前，首先进行判断池内的执行线程的数量。其中，每个需要进行的回调任务对应一个执行线程。

上述，预设最大数量为根据系统的配置、网络等因素考量所预先设置的数量值。

步骤S320，若是，则将所述执行状态标签变更为等待调度，并根据所述等待调度的执行状态标签将所述回调请求挂起；

如果已经达到最大数量，则回调系统采用丢弃策略，将数据库中的该回调请求对应的执行状态标签变更为“waithandler”即等待调度的状态，根据该状态将回调请求挂起，进而后续等待有其他方式重新调出进行回调任务。

步骤S330，若否，则将所述回调请求插入所述回调线程池的执行线程内，以便于根据所述执行线程中的所述回调请求对所述业务端执行回调任务。

上述，如果回调线程池中的执行线程的数量未超过最大数量，则判定可以执行，将回调请求插入回调线程池内，进而可以进行执行回调任务，向业务端发送回调信息。

进一步的，所述回调线程池中，所述执行线程的所述预设最大数量的计算方法为：

预设最大数量＝系统并发度×每秒可执行回调任务数×预设可接受延迟时间。

上述，系统并发度，是同时发出请求的数量。

上述，每秒可执行回调任务数，为让机器满载运行每秒可以处理完成的回调任务数量。

上述，预设可接受延迟时间，为可以接受的最大请求晚到时间。

在回调任务的异步化后，必然不会同时处理全部的回调请求，而是机器设备根据性能配置情况进行并发调度。例如，计算机如果CPU是8核，那么并发度可以调整到16或者更多。而队列大小则一般是和内存大小有关的，不过不能仅凭内存大小判定设置多少队列，因为如果太大的队列，会导致后面的回调会有很大的延时影响。虽然最终可能都能执行到该回调，但必然造成用户体验差的情况出现。

所以需要根据一定的容忍度进行设置。例如，预设可接受延迟时间即为容忍度，设置为1分钟延时；系统并发度设置为16，每个回调任务耗时100ms，根据公式计算，预设最大数量＝16×(1000/100)×60＝9600；此外，还需要考量上下文切换，队列要设置得小一些。预估每个回调的时间相对困难，所以一般内存队列中避免存在太多任务，比如有个别的请求出现长时间等待进而处理很慢，就会拖慢整体进度。综上，本实施例提供一种计算预设最大数量的方法，该方法通过系统并发度、每秒可执行回调任务数和预设可接受延迟时间等参数进行计算，由该公式可得出预设最大数量，通过该预设最大数量的数值，可以实现评估和调优的过程，提高用户体验，提高工作效率。

实施例3：

参照图5，本发明第3实施例提供一种业务回调服务的控制方法，基于上述实施例2，所述步骤S300，回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务之后，还包括：

步骤S600，所述回调系统获取所述服务提供端根据所述业务端的业务请求的执行情况所返回的响应信息；

在回调任务执行过程中，必须由回调系统收到规范的响应，才能认为回调成功，而并非双方网络连通就可以通过。在特殊情况中，由于有异步回调的情况下，服务提供端的业务数据尚未备齐，尚未进行，而回调系统一端的回调速度太快，从整体通信角度来讲，业务端可能需要延迟一段时间再次回调，则就需要正常规范的响应存在作为回调成功的指标。

步骤S700，若所述响应信息为业务执行成功，则判定执行状态为回调任务执行完成，以便于将所述执行状态标签变更为回调成功。

例如，响应为“{"dealStatus":"SUCCESS"}”，其字段为“业务执行成功”，代表回调任务执行完成，回调成功。

进一步的，所述步骤S700，回调系统获取所述服务提供端根据所述业务端的业务请求的执行情况所返回的响应信息之后，还包括：

步骤S800，若所述响应信息并非为业务执行成功，则判定执行状态为回调任务执行异常；所述回调系统接收所述服务提供端根据所述业务端的业务请求的执行情况所返回重复回调指令，以便于根据所述重复回调指令对所述业务端执行回调任务。

如果并非相应的“{"dealStatus":"SUCCESS"}”，或“业务执行成功”，则判定为异常响应，需要进行重复回调。

本实施例中，通过服务提供端的设定回调成功的规范响应，能够确保对方是否真正识别该请求，能否做出规范响应，此外，对方也可以利用该机制，在必要的时候做出不同的响应；比如，在业务方本机处理有困难时，可以将请求拒绝，然后触发下一次回调时才可能被其他机器处理。从而降低被回调方的实现复杂度。

进一步的，所述步骤S800，回调系统接收所述服务提供端根据所述业务端的业务请求的执行情况所返回重复回调指令之后，还包括：

步骤S900，所述回调系统根据预设的所述回调任务执行异常的执行状态的次数与时间的对应关系，获取与所述回调任务执行异常的执行状态的次数对应的当前次的时间间隔；

在需要进行重复回调的场景中，需要确定重复回调的频率。因为，如果频率设置较高，则会增加回调系统的系统资源的压力，并且不能进行无限次的回调。

例如，如果频率高，高频率的回调，则回调机会短时间内被用完，但业务端(客户端，被调用方)可能在短暂的时间内服务都是不可用的，即后续业务端恢复后也将无法收到准确的回调。

此外，如果回调的频率设置较低，进而就会出现加大回调的延迟时间的情况，这时对于正常的业务方而言，就会出现回调不及时的情况，造成用户体验差，所以可以以非固定频次的策略进行回调，即退避策略。

上述，所述回调任务执行异常的执行状态的次数，与时间间隔之间，具有一个预设的对应关系，根据该对应关系，回调系统获取到对应的当前次的时间间隔。

步骤S1000，所述回调系统根据所述当前次的时间间隔对所述业务端执行回调任务，并返回执行所述回调系统获取所述服务提供端根据所述业务端的业务请求的执行情况所返回的响应信息；其中，所述当前次的时间间隔大于前一次的时间间隔。

在开始运行或执行回调任务时，一般情况下业务的运行是正常的，此时回调系统应尽快回调客户端。但当回调系统尝试多次之后，发现始终不能收到回调的规范响应，这时，则回调系统就需要主动加大对其的回调时间间隔，重试失败次数越多，间隔越大，直到大到对系统基本无影响为止。因此，当前次的时间间隔＞前一次的时间间隔。

例如，根据对应关系设置为如下表所示：

上表中，所代表的是每次重试回调对应的时间间隔，最开始间隔1秒、3秒、5秒，最大可达到多个小时的间隔。

优选地，所述当前次的时间间隔的最大值为6小时。因为，间隔6个小时，已经对系统的整体运行影响极其微小，所以超过一定数量的多次回调，可以就停止回调，或者就以6小时为间隔进行回调。对回调系统的整体运行影响都不会太大。

实施例4：

参照图6，本发明第3实施例提供一种业务回调服务的控制方法，基于上述实施例1，所述控制方法还包括：

步骤S1100，所述回调系统接收平台的关机/重启指令；

需要说明的是，服务器进行重启或开关机是正常操作，但在该场景下，在回调系统中，由于回调请求均排列在内存队列中，即该队列是维护在内存中的，如果重启或关机必然导致队列丢失。

为解决上述问题，本实施例中提供一种实施方试。

关机/重启指令，由回调系统实时接收。

步骤S1200，接收到所述关机/重启指令后，所述回调系统获取所述内存队列中的回调请求，并将所述内存队列中的回调请求存入数据库中成一数据包，并对所述数据包设置一待分配状态标签，以便于所述回调系统根据所述待分配状态标签获取所述数据库中的所述数据包至所述内存队列中。

上述，回调系统在接收到关机/重启指令之后，获取内存队列中的所有回调请求为一个数据包，将其附上待分配的状态标签，并存入数据库中作为存档。

上述，针对的是正常的重启或开关机的场景，添加相应的关闭钩子，作用是将内存中的队列存入数据库中或缓存中，以便于在系统重启后，自身能从中导出进行处理。

进一步的，参考图7，所述控制方法还包括：

步骤S1300，所述回调系统根据随机休眠时间作为启动时间间隔，启动扫描守护线程；

步骤S1400，所述回调系统基于所述扫描守护线程判断所述数据库中是否存在与所述回调系统对应且所述状态标签为待处理的数据包；

步骤S1500，若是，则所述回调系统调取所述数据包至所述内存队列中，删除所述待分配状态标签。

上述，步骤S1300-S1500可以在步骤S100之前，或者在其他步骤之后，在此并不做限定，只需回调系统定时或不定时的执行该步骤对应的线程即可。

在回调系统中，实时或定时开启一个线程，即为扫描守护线程，该线程的任务就是不断检查是否需要重新导出进行回调的任务的数据包，如果有则将其导出来，加入到本机或者其他机器的内存队列中，并同时将待处理的状态标签去除，以免被重复取出。

优选地，扫描守护线程为具有单一性的线程，同时只能有一个扫描守护线程运行。

同时，要避免数据包总是被某一台回调系统抢到执行，从而增大该回调系统的自身系统压力，即需要提供一定的公平性。为解决该问题，本实施例中设置一定随机的休眠时间作为启动时间间隔，由于采用了随机休眠时间启动线程，使各机器可以错峰取任务处理，即基本上到自己取待处理队列时，都可以进行处理数据，从而达到分散处理任务目的。

实施例5：

参照图8，本发明第3实施例提供一种业务回调服务的控制方法，基于上述实施例1，所述步骤200，回调系统接收到所述回调请求后，将所述回调请求存入内存队列中之前，还包括：

步骤S1600，所述回调系统对所接收到所述回调请求设定一对应的回调ID；

所述步骤300，回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务，还包括：

步骤340，所述回调系统通过所述回调线程池中的所述回调请求，向所述业务端发送与所述回调任务对应的回调信息；其中所述回调信息中包括所述回调ID；

步骤350，所述业务端接收到所述回调信息后，获取所述回调信息对应的回调ID；

步骤360，所述业务端判断所述回调ID是否与先前已经接收到的回调信息的回调ID相同；

步骤370，若是，则判定当前所接收到的所述回调信息为无效回调；

步骤380，若否，则判定当前所接收到的所述回调信息为有效回调，并根据所述回调信息向所述回调系统返回一对应的有效回调响应信息。

需要说明的是，回调系统中的回调服务的任务的语义，执行的次数为至少一次。因此，被回调方，即业务端，需要识别出是否重复的调入的情况出现，避免业务上的处理错误。

为解决上述问题，本实施例中，通过在回调系统端和业务端分别进行设置。首先，在回调系统一端，为回调请求赋予一对应的回调ID，并且在向业务端发送回调信息时包含有该回调ID。而如果回调系统再次发送回调信息，进行重复回调时，则会依然根据此回调ID进行发送。

因此，业务端在接收到回调信息后，可以首先获取回调ID，然后判断该回调ID是否先前已经接收到，是否与先前接收到的回调ID相同，进行幂等处理。

如果相同，则只有第一次收到的回调ID对应的回调信息为有效回调，应当立即响应回调信息，而不是等待业务处理结束再进行响应，否则可能会给回调系统带来运行上的压力，甚至可能导致后续无效的回调重试。而其他的均为无效回调，做忽略处理。而被回调方，即业务端可以在立即响应后再进行进一步的异步化处理自己的逻辑。

总之，本申请通过设置一独立的回调系统，独立处理回调服务，将回调请求存入内存队列中，并根据回调线程池对业务端进行执行回调任务。本发明所提供的回调服务的实现方式中，业务端和服务提供端均无需进行回调服务的处理，而只需回调系统独立处理，方法简单，能够保证高性能性、高可用性和高稳定性。

通过提供本申请中的回调系统进行回调，大大减少了客户端(被回调端、业务端)的处理任务的复杂性，能够使其更专注实现自己的核心业务，而不用去关注各种异常情况。尤其是有的查询任务中逻辑并不友好，会导致客户端的并发能力地下。通过申请中的回调服务，能够避免上述问题。

而服务提供者(服务提供端)，也无需将系统资源耗费在回调问题、网络连接问题、防火墙问题和业务处理问题等问题上，服务提供端只需关注自身系统中的核心领域，交付正确处理的数据即可。其他相关的回调工作，由独立的回调系统完成，也大大降低了其代码的复杂性，提高用户体验。

此外，参考图9，本发明还提供一种业务回调服务的控制装置，包括：

请求模块10，用于服务提供端接收到业务端发出的业务请求后，向回调系统发送与所述业务请求对应的回调请求；其中，所述回调请求包括所述业务端对应的回调地址；

存储模块20，用于所述回调系统接收到所述回调请求后，将所述回调请求存入内存队列中；

执行模块30，用于所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务。

此外，本发明还提供一种业务回调服务的控制系统，包括业务端、服务提供端和回调系统；其中，至少所述回调系统中设有存储器以及处理器，所述存储器用于存储业务回调服务的控制程序，所述处理器运行所述业务回调服务的控制程序以使所述业务回调服务的控制系统执行如上述所述的业务回调服务的控制方法。

此外，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有业务回调服务的控制程序，所述业务回调服务的控制程序被处理器执行时实现如上述所述的业务回调服务的控制方法。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (13)

1.一种业务回调服务的控制方法，其特征在于，包括：

服务提供端接收到业务端发出的业务请求后，向回调系统发送与所述业务请求对应的回调请求；其中，所述回调请求包括所述业务端对应的回调地址；

所述回调系统接收到所述回调请求后，将所述回调请求存入内存队列中；

所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务。

2.如权利要求1所述业务回调服务的控制方法，其特征在于，所述将所述回调请求存入内存队列中之前，还包括：

所述回调系统接收到所述回调请求后，将所述回调请求插入数据库中，并赋予待处理的执行状态标签；

所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务之后，还包括：

所述回调系统的所述回调任务执行完成之后，将所述执行状态标签变更为回调成功。

3.如权利要求2所述业务回调服务的控制方法，其特征在于，所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务，包括：

所述回调系统判断所述回调线程池中的执行线程的数量是否已达到预设最大数量；

若是，则将所述执行状态标签变更为等待调度，并根据所述等待调度的执行状态标签将所述回调请求挂起；

若否，则将所述回调请求插入所述回调线程池的执行线程内，以便于根据所述执行线程中的所述回调请求对所述业务端执行回调任务。

4.如权利要求3所述业务回调服务的控制方法，其特征在于，所述回调线程池中，所述执行线程的所述预设最大数量的计算方法为：

预设最大数量＝系统并发度×每秒可执行回调任务数×预设可接受延迟时间。

5.如权利要求2所述业务回调服务的控制方法，其特征在于，所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务之后，还包括：

所述回调系统获取所述服务提供端根据所述业务端的业务请求的执行情况所返回的响应信息；

若所述响应信息为业务执行成功，则判定执行状态为回调任务执行完成，以便于将所述执行状态标签变更为回调成功。

6.如权利要求5所述业务回调服务的控制方法，其特征在于，所述回调系统获取所述服务提供端根据所述业务端的业务请求的执行情况所返回的响应信息之后，还包括：

若所述响应信息并非为业务执行成功，则判定执行状态为回调任务执行异常；所述回调系统接收所述服务提供端根据所述业务端的业务请求的执行情况所返回重复回调指令，以便于根据所述重复回调指令对所述业务端执行回调任务。

7.如权利要求6所述业务回调服务的控制方法，其特征在于，所述回调系统接收所述服务提供端根据所述业务端的业务请求的执行情况所返回重复回调指令之后，还包括：

所述回调系统根据预设的所述回调任务执行异常的执行状态的次数与时间的对应关系，获取与所述回调任务执行异常的执行状态的次数对应的当前次的时间间隔；

所述回调系统根据所述当前次的时间间隔对所述业务端执行回调任务，并返回执行所述回调系统获取所述服务提供端根据所述业务端的业务请求的执行情况所返回的响应信息；其中，所述当前次的时间间隔大于前一次的时间间隔。

8.如权利要求1所述业务回调服务的控制方法，其特征在于，还包括：

所述回调系统接收平台的关机/重启指令；

接收到所述关机/重启指令后，所述回调系统获取所述内存队列中的回调请求，并将所述内存队列中的回调请求存入数据库中成一数据包，并对所述数据包设置一待分配状态标签，以便于所述回调系统根据所述待分配状态标签获取所述数据库中的所述数据包至所述内存队列中。

9.如权利要求8所述业务回调服务的控制方法，其特征在于，还包括：

所述回调系统根据随机休眠时间作为启动时间间隔，启动扫描守护线程；

所述回调系统基于所述扫描守护线程判断所述数据库中是否存在与所述回调系统对应且所述状态标签为待处理的数据包；

若是，则所述回调系统调取所述数据包至所述内存队列中，删除所述待分配状态标签。

10.如权利要求1所述业务回调服务的控制方法，其特征在于，所述回调系统接收到所述回调请求后，将所述回调请求存入内存队列中之前，还包括：

所述回调系统对所接收到所述回调请求设定一对应的回调ID；

所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务，还包括：

所述回调系统通过所述回调线程池中的所述回调请求，向所述业务端发送与所述回调任务对应的回调信息；其中所述回调信息中包括所述回调ID；

所述业务端接收到所述回调信息后，获取所述回调信息对应的回调ID；

所述业务端判断所述回调ID是否与先前已经接收到的回调信息的回调ID相同；

若是，则判定当前所接收到的所述回调信息为无效回调；

若否，则判定当前所接收到的所述回调信息为有效回调，并根据所述回调信息向所述回调系统返回一对应的有效回调响应信息。

11.一种业务回调服务的控制装置，其特征在于，包括：

请求模块，用于服务提供端接收到业务端发出的业务请求后，向回调系统发送与所述业务请求对应的回调请求；其中，所述回调请求包括所述业务端对应的回调地址；

存储模块，用于所述回调系统接收到所述回调请求后，将所述回调请求存入内存队列中；

执行模块，用于所述回调系统通过回调线程池，根据所述内存队列中的所述回调请求，对所述回调地址对应的所述业务端执行回调任务。

12.一种业务回调服务的控制系统，其特征在于，包括业务端、服务提供端和回调系统；其中，至少所述回调系统中设有存储器以及处理器，所述存储器用于存储业务回调服务的控制程序，所述处理器运行所述业务回调服务的控制程序以使所述业务回调服务的控制系统执行如权利要求1-10任一项所述的业务回调服务的控制方法。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有业务回调服务的控制程序，所述业务回调服务的控制程序被处理器执行时实现如权利要求1-10任一项所述的业务回调服务的控制方法。

Images