CN113709248A - 业务请求处理方法、系统以及前端、服务端业务处理装置 - Google Patents

Abstract

本发明涉及业务请求处理领域，尤其涉及一种业务请求处理方法、系统以及前端、服务端业务处理装置，服务端接收到业务请求后，先判断业务请求是否被篡改，确定业务请求未被篡改，判断分布式处理集合中是否存在第一业务请求标识，不存在时，则执行该业务请求的处理逻辑，生成处理结果，将处理结果反馈给用户终端并将其写入至分布式消息处理系统中，若存在，向用户终端返回第二提示信息，以使用户终端在接收到第二提示信息后，根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果。本发明提供的方法、装置及系统，可以确保业务请求处理结果的推送准确性、避免服务器资源浪费问题，不会让用户终端产生无效的等待时间。

Description

业务请求处理方法、系统以及前端、服务端业务处理装置

技术领域

本发明涉及业务请求处理领域，尤其涉及一种业务请求处理方法、系统以及前端、服务端业务处理装置。

背景技术

在业务面向C端时，业务响应要求都比较高，在小程序端对接口响应的超时时长都会在比较短的时间内。但部分情况下，如客户终端进入弱网区域或网络发生波动的情况，或业务逻辑中需要调用以来同步的第三方服务请求，为了确保业务的完整与连贯性，需要确保用户不会发生业务中断，需要对超时或终止的请求进行重试，但由于服务目前是无状态服务，因此当每次重试时，服务端都会完整执行跑完整业务处理逻辑，发生重复地获取数据或发起第三方的接口请求。

当业务逻辑比较复杂或外部接口延时时，会导致接口处理时间超出终端设置的超时时间，处理结果无法在超时时间内返回，当每次重试时都完整执行完整业务处理逻辑，导致无论重试多次，在重试限制次数内均无法获取到结果，导致最终失败。

部分业务请求数据量比较大，多次业务请求如果重复执行，加载到内存中的数据会重复增加，如出现大量重试，会导致服务器内存的飙升，浪费服务器资源。

发明内容

针对上述问题，本发明提供一种业务请求处理方法、系统以及前端、服务端业务处理装置。

本发明提供一种业务请求处理方法，包括：接收用户终端发送的业务请求，从业务请求中获取第一业务请求标识，第一业务请求标识为用户终端根据业务请求的原始业务请求参数以及预设的业务请求标识生成策略生成；

根据第一业务请求标识以及预设的业务请求篡改判断策略，判断业务请求是否被篡改，若是，向用户终端返回第一提示信息，以提示出现异常情况；否则，判断在分布式业务处理集合中是否存在第一业务请求标识；

若不存在，将第一业务请求标识加入到分布式业务处理集合中，并执行业务请求的业务逻辑，生成处理结果，将处理结果写入到分布式消息处理系统中，并向用户终端同步返回处理结果；

若存在，向用户终端返回第二提示信息，以使用户终端在接收到第二提示信息后，根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果。

进一步的，业务请求篡改判断策略包括：

从业务请求中获取当前业务请求参数，根据当前业务请求参数以及业务请求标识生成策略生成第二业务请求标识；

判断第二业务请求标识与第一业务请求标识是否相同，若是，判定业务请求未被篡改，否则，判定业务请求被篡改。

进一步的，业务请求标识生成策略包括：

获取业务请求参数，按照业务请求参数的参数名称对业务请求参数进行排序；

根据MD5信息摘要算法对排序后的业务请求参数进行处理，生成32位字符串作为业务请求标识。

进一步的，业务请求参数为加入随机码后的业务请求参数，随机码由用户终端生成，每个业务请求对应唯一一个随机码。

本发明还提供一种业务请求处理方法，方法包括：

向服务端发送业务请求，业务请求中包括原始业务请求参数以及用于唯一标识业务请求的第一业务请求标识，第一业务请求标识为根据原始业务请求参数以及预设的业务请求标识生成策略生成；

若发生预设的重试条件，向服务端重新发送业务请求，并在接收到服务端返回的第二提示信息后，根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果，同时设置结果等待超时时间；

若在结果等待超时时间内，接收到分布式消息处理系统推送的处理结果，将处理结果予以显示，否则，取消订阅，生成结果等待超时信息，并将结果等待超时信息予以显示。

进一步的，预设的重试条件包括业务请求超时或者业务请求中断。

本发明还提供一种服务端业务处理装置，服务端业务处理装置包括：业务请求接收模块、业务请求篡改判断模块、查询模块、业务处理模块，其中：

业务请求接收模块，与业务请求篡改判断模块连接，用于接收用户终端发送的业务请求；

业务请求篡改判断模块，与查询模块连接，用于从业务请求中获取第一业务请求标识，第一业务请求标识为用户终端根据业务请求的原始业务请求参数以及预设的业务请求标识生成策略生成，根据第一业务请求标识以及预设的业务请求篡改判断策略，判断业务请求是否被篡改，若是，向用户终端返回第一提示信息，否则，控制查询模块执行查询操作；

查询模块，与业务处理模块连接，用于执行查询操作，查询操作包括判断在分布式业务处理集合中是否存在第一业务请求标识，若存在，向用户终端返回第二提示信息，以使用户终端在接收到第二提示信息后，根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果，若不存在，将第一业务请求标识加入到分布式业务处理集合中，并控制业务处理模块执行业务处理操作；

业务处理模块，用于执行业务处理操作，执行业务处理操作为执行业务请求的业务逻辑，生成处理结果，业务处理模块还用于将处理结果写入到分布式消息处理系统中，并向用户终端同步返回处理结果。

进一步的，业务请求篡改判断模块还包括第二业务请求标识生成单元以及判断单元，其中：

第二业务请求标识生成单元，与判断单元连接，用于从业务请求中获取当前业务请求参数，根据当前业务请求参数以及业务请求标识生成策略生成第二业务请求标识；

判断单元，用于判断第二业务请求标识与第一业务请求标识是否相同，若是，判定业务请求未被篡改，否则，判定业务请求被篡改。

本发明还提供一种前端业务处理装置，前端业务处理装置包括发送模块、重试模块、接收模块、订阅模块以及显示模块，其中：

发送模块，与重试模块连接，用于向服务端发送业务请求，业务请求中包括原始业务请求参数以及用于唯一标识业务请求的第一业务请求标识，第一业务请求为根据原始业务请求参数以及预设的业务请求标识生成策略生成；

重试模块，用于若发生预设的重试条件，控制发送模块向服务端重新发送业务请求；

接收模块，与订阅模块以及显示模块连接，用于接收服务端返回的提示消息以及处理结果，提示消息包括用于提示业务请求被篡改的第一提示信息以及用于提示业务请求的处理状态为处理中或已处理的第二提示信息；

订阅模块，还与发送模块连接，用于在接收到服务端返回的第二提示信息后，根据第一业务请求标识在分布式消息处理系统中订阅所述业务请求的处理结果，同时设置结果等待超时时间；若在结果等待超时时间内，接收到分布式消息处理系统推送的处理结果，将处理结果发送至显示模块，否则，取消订阅，并生成结果等待超时信息，将所述结果等待超时信息发送至所述显示模块；

显示模块，用于对接收到的第一提示信息、第二提示信息、处理结果或结果等待超时信息进行显示。

本发明还提供一种业务请求处理系统，系统包括上述的服务端业务处理装置以及上述的前端业务处理装置，服务端业务处理装置与前端业务处理装置之间进行信息交互，以实现对业务请求的处理。

本发明提供的业务请求处理方法、系统以及前端、服务端业务处理装置，至少包括以下有益效果：(1)服务端接收到业务请求之后，先判断业务请求是否被篡改，只有未被篡改才能执行后续的业务逻辑处理操作，确保业务请求处理结果的准确性，从而保证处理结果推送的正确性。(2)通过判断分布式业务处理集合中是否存在第一业务请求标识，保证了多个服务之间不会冲突的问题，并确保只有一个相同请求在处理。(3)当分布式业务处理集合中存在第一业务请求标识时，说明该业务请求是一个重复的业务请求(可能为重试请求)，此时服务端接收到重复的业务请求，不再根据重复的业务请求再执行全部的完整的业务处理逻辑，从而避免当业务逻辑比较复杂或外部接口延时时，接口处理时间超出终端设置的超时时间，无论重试多次，在重试限制次数内均无法获取到结果，导致最终业务请求失败的问题，同时也避免了浪费服务器资源的问题。(4)在用户终端，收到服务端的第二提示信息之后，直接根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果，分布式消息处理系统中接收到服务端发送的处理结果后，能够及时将处理结果推送给用户终端，使用户终端能够在第一时间获得处理结果，不会让用户终端产生无效的等待时间。(5)利用消息订阅(在分布式消息处理系统中订阅处理结果)，代替了重复调用接口，使用户终端无需每隔一段时间就与服务端进行连接，进行重复业务请求，减少了与服务器连接次数，降低了服务器的连接请求及带宽占用压力。

附图说明

为了更清楚的说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见的，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。

图1为本发明一种实施例中的业务请求处理方法流程图；

图2为本发明一种实施例中的业务请求篡改判断策略步骤流程图；

图3为本发明一种实施例中的业务请求标识生成策略步骤流程图；

图4为本发明又一种实施例中的业务请求处理方法流程图；

图5为本发明一种实施例中的服务端业务处理装置示意图；

图6为本发明一种实施例中的前端业务处理装置示意图；

图7为本发明一种实施例中的业务请求处理系统示意图；

5-服务端业务处理装置、501-业务请求接收模块、502-业务请求篡改判断模块、503-查询模块、504-业务处理模块、6-前端业务处理装置、601-发送模块、602-重试模块、603-接收模块、604-订阅模块、605-显示模块。

具体实施方式

下面将结合本发明中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通的技术人员在没有做出创造性劳动的前提下所获得的所有其它实施例，都属于本发明的保护范围。

在本发明的一种实施例中，如图1所示，公开了一种业务请求处理方法，该方法应用在服务端，具体的，方法包括以下步骤：

步骤S101：接收用户终端发送的业务请求，从业务请求中获取第一业务请求标识。

具体的，第一业务请求标识为用户终端根据业务请求的原始业务请求参数以及预设的业务请求标识生成策略生成。在本发明中，将业务请求在用户终端时的业务请求参数作为原始业务请求参数。第一业务请求标识用于唯一标识业务请求。用户终端为业务请求生成第一业务请求标识之后，将业务请求标识通过请求头(HEAD)随业务请求发送至服务端。

进一步的，开发人员在进行后端(服务端)服务接口(RESTful API)开发时，可以根据服务接口的业务逻辑场景判断，如业务逻辑中有外部接口请求依赖或逻辑较复杂执行时间较长这类接口，加入请求拦截，用于处理由用户终端在请求头(HEAD)中随请求加入的业务请求标识(RequestId)。也即，只在业务逻辑中有外部接口请求依赖或逻辑较复杂执行时间较长这类接口，加入请求拦截，执行本实施例中的步骤S101-步骤S106的业务处理方法。

步骤S102：根据第一业务请求标识以及预设的业务请求篡改判断策略，判断业务请求是否被篡改，若是，则执行步骤S103，否则执行步骤S104。

具体的，如图2所示，在本实施例中，预设的业务请求篡改判断策略包括以下步骤：

步骤S201：从业务请求中获取当前业务请求参数，根据当前业务请求参数以及业务请求标识生成策略生成第二业务请求标识。

具体的，在本发明中，将业务请求在服务端时的业务请求参数作为当前业务请求参数，以便与业务请求在用户终端时的业务请求参数进行区分。

步骤S202：判断第二业务请求标识与第一业务请求标识是否相同，若是，执行步骤S203，否则，执行步骤S204。

步骤S203：判定业务请求未被篡改，继续执行步骤S104。

步骤S204：判定业务请求被篡改，执行步骤S103。

由于业务请求在由用户终端向服务端发送的过程之中，可能会被篡改，一旦业务请求被篡改，业务请求参数发生改变，服务端根据篡改后的业务请求参数执行相关的业务逻辑，则会造成处理结果错误。

本实施例中提供的业务请求篡改判断策略，在接收到业务请求之后，获取当前业务请求参数，若业务请求未被篡改，则当前业务请求参数与原始业务请求参数相同，因此采用同样的业务请求标识生成策略分别对原始业务请求参数、当前业务请求参数进行处理，所生成的第一业务请求标识、第二业务请求标识也应当是相同的。而业务请求被篡改，业务请求参数改变，也即当前业务请求参数与原始业务请求参数不相同，采用同样的业务请求标识生成策略分别对原始业务请求参数、当前业务请求参数进行处理，所生成的第一业务请求标识、第二业务请求标识也是不相同的。因而在本实施例中，可以采用上述的步骤S201-步骤S204来判断业务请求是否被篡改。进而在判断业务请求是否被篡改之后，根据判断结果继续执行后续的步骤S103，或步骤S104。进一步的，本实施例中，可以通过摘要算法确保业务请求参数与业务请求的唯一性，验证业务请求是否被篡改，以保证处理结果消息准确推送。

步骤S103：向用户终端返回第一提示信息，以提示出现异常情况。

当用户终端接收到第一提示信息之后，即可将第一提示信息予以显示，例如显示在用户终端的显示屏上，以提示用户业务请求被篡改，出现了异常情况。进而使用户根据此异常情况进行处理。具体的，第一提示信息可以用代码403表示。

步骤S104：判断在分布式业务处理集合中是否存在第一业务请求标识，若不存在，执行步骤S105，若存在，执行步骤S106。

具体的，分布式处理集合用于存储已经处理或者正在处理中的业务请求的业务请求标识。如果在分布式业务处理集合中存在第一业务请求标识，则说明该第一业务请求标识所对应的业务请求正在处理中或者已经处理。

步骤S105：将第一业务请求标识加入到分布式业务处理集合中，并执行业务请求的业务逻辑，生成处理结果，将处理结果写入到分布式消息处理系统中，并向用户终端同步返回处理结果。

当分布式业务处理集合中不存在第一业务请求标识时，说明该第一业务请求标识所对应的业务请求之前未处理。

在本步骤中分布式消息处理系统用于存储所有业务请求的处理结果，其中，业务请求之间通过业务请求标识加以区分(也即上文中所提到的第一业务请求标识)，分布式消息处理系统在发布处理结果时，会使用该处理结果所对应的业务请求标识(RequestID)作为消息的发布主题。

步骤S106：向用户终端返回第二提示信息，以使用户终端在接收到第二提示信息后，根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果。

在本步骤中，如果分布式业务处理集合中存在第一业务请求标识，则对于第一业务请求标识所对应的业务请求正在处理中或者已经处理完成，因而服务端无需再重复执行完整的业务逻辑，只需要向用户终端返回第二提示信息，令用户终端根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果即可，当分布式消息处理系统接收到处理结果，或者已经存储有对应的处理结果，即会将该处理结果通过消息发布方式推送给订阅该业务请求的用户终端。具体的，第二提示信息可以用代码202表示。

本实施例所提供的业务请求处理方法，由于在服务端接收到业务请求之后，先判断业务请求是否被篡改，只有未被篡改才能执行后续的业务逻辑处理操作，确保业务请求结果的准确性，从而保证处理结果推送的正确性。通过分布式业务处理集合，保证了多个服务之间不会冲突的问题，并确保只有一个相同的业务请求在处理。当分布式的业务处理集合中存在第一业务请求标识时，说明该业务请求是一个重复的业务请求(重试请求)，此时服务端接收到重复的业务请求，不再根据重复的业务请求再执行全部的完整的业务处理逻辑，从而避免当业务逻辑比较复杂或外部接口延时时，接口处理时间超出终端设置的超时时间，每次重试都完整执行完整业务处理逻辑，导致无论重试多次，在重试限制次数内均无法获取到结果，导致最终业务请求失败的问题，同时也避免了因为多次重试执行完整业务处理逻辑，浪费服务器资源的问题。

在本发明的又一种实施例中，如图3所示，业务请求标识生成策略为：

步骤S301：获取业务请求参数，按照业务请求参数的参数名称对业务请求参数进行排序；

具体的，业务请求参数根据业务接口的不同而有所不同，其中必须要有的业务请求参数可以包括随机生成码(Rnd Code)，业务请求标识(RequestID)。其它的业务的参数如用户姓名(UserName)、用户ID(UserID)等等。在实际实施过程中，可以由技术人员预先设置各个业务请求参数的参数名称顺序，进而使用户终端根据预先设置的各个参数名称顺序对各个参数名称所对应的参数值(业务请求参数)进行排序。例如可以设置根据业务请求参数的英文名称进行排序。

若根据业务请求的原始业务请求参数以及预设的业务请求标识生成策略生成第一业务请求标识，则此处获取业务请求参数指的是获取原始业务请求参数，若根据当前业务请求参数以及业务请求标识生成策略生成第二业务请求标识，则此处获取业务请求参数指的是获取当前业务请求参数。

步骤S302：根据MD5信息摘要算法对排序后的业务请求参数进行处理，生成32位字符串作为业务请求标识。

其中，MD5信息摘要算法(Message-Digest Algorithm 5)，用于确保信息传输完整一致，MD5将任意长度的“字节串”变换成一个128bit的大整数(32位字符串)，并且它是一个不可逆的字符串变换算法。

进一步的，在本发明的又一种实施例中，在上一实施例的基础之上，步骤S301中的所获取的业务请求参数为加入随机码后的业务请求参数。

其中，随机码(RndCode)由用户终端为每一次独立业务请求生成，每个业务请求对应唯一一个随机码，随机码为全局唯一标识符(GUID，Globally Unique Identifier)，是一种由算法生成的二进制长度为128位的数字标识符。

进一步的，在用户终端根据业务请求的原始业务请求参数以及预设的业务请求标识生成策略生成第一业务请求标识前，会先对原始业务请求参数进行预处理，将原始业务请求参数加入随机码。后续用户终端将业务请求发送给服务端时，业务请求中的原始业务请求参数为加入随机码后的业务请求参数。因此服务端所接收到的当前业务请求参数也为加入随机码后的业务请求参数。

在本发明的又一种实施例中，如图4所示，提供另一种业务请求处理方法，方法包括：

步骤S401：向服务端发送业务请求。

具体的，业务请求中包括原始业务请求参数以及用于唯一标识业务请求的第一业务请求标识，第一业务请求标识为根据原始业务请求参数以及预设的业务请求标识生成策略生成。更具体的，在本步骤中，预设的业务请求标识生成策略与上述步骤S301-步骤S302相同。

步骤S402：监控是否发生预设的重试条件，若是，则执行步骤S403，否则，重复执行步骤S402。

具体的，在本实施例中，重设条件可以为业务请求超时或者业务请求中断。

其中：业务请求超时由用户终端预置限制，例如设置每个请求的超时时间为30秒，等待响应超过此时间则认为是请求超时。

业务请求中断是指用户终端与服务端之间由于网路问题，或服务间链接中间件发生链接断开，而非到达超时时间的情况。步骤S403：向服务端重新发送业务请求，并在接收到服务端返回的第二提示信息后，根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果，同时设置结果等待超时时间。

具体的，在本实施例中，第二提示信息即指的是在服务端判断出分布式处理集合中已经存在第一业务请求标识，因而由服务端所发出的第二提示信息。具体参考步骤S104以及步骤S106。

更具体的，结果等待超时时间可以为30秒、1分钟等等，结果等待超时时间可以由技术人员根据接口业务逻辑的复杂程度等设置，本发明对此不作限制。

步骤S404：判断在结果等待超时时间内，是否接收到分布式消息处理系统推送的处理结果，若是，执行步骤S405，否则，执行步骤S406。

步骤S405：将处理结果予以显示。

步骤S406：取消订阅，生成结果等待超时信息，并将结果等待超时信息予以显示。

若用户终端在结果等待超时时间内，未接收到分布式消息处理系统推送的处理结果，则取消订阅，提醒用户订阅超时，向用户反馈无法获取到处理结果的提示，使用户不再无限期的等待订阅的处理结果。

在本实施例中，用户终端收到服务端的第二提示信息之后，直接根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果，分布式消息处理系统中接收到服务端发送的处理结果后，能够及时将处理结果推送给用户终端，使用户终端能够在第一时间获得处理结果，不会让用户终端产生无效的等待时间。

另外本实施例利用消息订阅(在分布式消息处理系统中订阅处理结果)，代替了重复调用接口，使用户终端无需每隔一段时间就与服务端进行连接，进行重复业务请求以获取处理结果，减少了与服务器连接次数，降低了服务器的连接请求及带宽占用压力。

并且在本实施例中，设置了结果等待超时时间，在结果等待超时时间内，如果一直未能接收到处理结果，则生成结果等待超时信息，将结果等待超时信息予以显示，提醒用户已超时，以便用户及时针对此情况进行处理，不必进行无意义的等待。

在本发明的一种实施例中，如图5所示，本发明还提供一种服务端业务处理装置，服务端业务处理装置包括：业务请求接收模块501、业务请求篡改判断模块502、查询模块503、业务处理模块504，其中：

业务请求接收模块501，与业务请求篡改判断模块502连接，用于接收用户终端发送的业务请求；

业务请求篡改判断模块502，与查询模块503连接，用于从业务请求中获取第一业务请求标识，第一业务请求标识为用户终端根据业务请求的原始业务请求参数以及预设的业务请求标识生成策略生成，根据第一业务请求标识以及预设的业务请求篡改判断策略，判断业务请求是否被篡改，若是，向用户终端返回第一提示信息，以利用第一提示信息提示用户业务请求被篡改，存在异常情况，否则，控制查询模块503执行查询操作。

具体的，在本实施例中，业务请求篡改判断模块可以采用上述提及的步骤S201-步骤S204进行篡改判断。

查询模块503，与业务处理模块504连接，用于执行查询操作，查询操作包括判断在分布式业务处理集合中是否存在第一业务请求标识，若存在，向用户终端返回第二提示信息，以使用户终端在接收到第二提示信息后，根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果，若不存在，将第一业务请求标识加入到分布式业务处理集合中，并控制业务处理模块504执行业务处理操作。

业务处理模块504，用于执行业务处理操作，执行业务处理操作为执行业务请求的业务逻辑，生成处理结果，业务处理模块还用于将处理结果写入到分布式消息处理系统中，并向用户终端同步返回处理结果。

进一步的，业务请求篡改判断模块还包括第二业务请求标识生成单元以及判断单元，其中：

第二业务请求标识生成单元，与判断单元连接，用于从业务请求中获取当前业务请求参数，根据当前业务请求参数以及业务请求标识生成策略生成第二业务请求标识；

判断单元，用于判断第二业务请求标识与第一业务请求标识是否相同，若是，判定业务请求未被篡改，否则，判定业务请求被篡改。

本实施例所提供的服务端业务处理装置，由于在服务端接收到业务请求之后，先判断业务请求是否被篡改，只有未被篡改才能执行后续的业务逻辑处理操作，确保业务请求结果的准确性、正确性，从而保证处理结果推送的正确性。通过分布式的业务处理集合，保证了多个服务之间不会冲突的问题，并确保只有一个相同请求在处理。当分布式的业务处理集合中存在第一业务请求标识时，说明该业务请求是一个重复的业务请求(重试请求)，此时服务端接收到重复的业务请求，不再根据重复的业务请求再执行全部的完整的业务处理逻辑，从而避免当业务逻辑比较复杂或外部接口延时时，接口处理时间超出终端设置的超时时间，每次重试都完整执行完整业务处理逻辑，导致无论重试多次，在重试限制次数内均无法获取到结果，导致最终业务请求失败的问题，同时也避免了因为多次重试执行完整业务处理逻辑，浪费服务器资源的问题。

本发明还提供一种前端业务处理装置，如图6所示，前端业务处理装置包括发送模块601、重试模块602、接收模块603、订阅模块604以及显示模块605，其中：

发送模块601，与重试模块602连接，用于向服务端发送业务请求，业务请求中包括原始业务请求参数以及用于唯一标识业务请求的第一业务请求标识。

具体的，第一业务请求为根据原始业务请求参数以及预设的业务请求标识生成策略生成；其中预设的业务请求标识生成策略为上述提及的步骤S301-步骤S302所示的方法。

重试模块602，用于若发生预设的重试条件，控制发送模块向服务端重新发送业务请求。

具体的，预设的重试条件为上文所提及的业务请求超时或者业务请求中断。

接收模块603，与订阅模块604以及显示模块605连接，用于接收服务端返回的提示消息以及处理结果，提示消息包括用于提示业务请求被篡改的第一提示信息以及用于提示业务请求的处理状态为处理中或已处理的第二提示信息；

订阅模块604，还与发送模块连接，用于在接收到服务端返回的第二提示信息后，根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果，同时设置结果等待超时时间；若在结果等待超时时间内，接收到分布式消息处理系统推送的处理结果，将处理结果发送至显示模块，否则，取消订阅，并生成结果等待超时信息，将结果等待超时信息发送至显示模块；

显示模块605，用于对接收到的第一提示信息、第二提示信息、处理结果或结果等待超时信息进行显示。

本实施例提供的前端业务处理装置，用户终端收到服务端的第二提示信息之后，直接根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果，分布式消息处理系统中接收到服务端发送的处理结果后，能够及时将处理结果推送给用户终端，使用户终端能够在第一时间获得处理结果，不会让用户终端产生无效的等待时间。

另外本实施例利用消息订阅(在分布式消息处理系统中订阅处理结果)，代替了重复调用接口，使用户终端无需每隔一段时间就与服务端进行连接，进行重复业务请求，减少了与服务器连接次数，降低了服务器的连接请求及带宽占用压力。

本发明还提供一种业务请求处理系统，如图7所示，系统包括上述的服务端业务处理装置5以及上述的前端业务处理装置6，服务端业务处理装置5与前端业务处理装置6之间进行信息交互，以实现对业务请求的处理。具体的，服务端业务处理装置5包括业务请求接收模块501、业务请求篡改判断模块502、查询模块503、业务处理模块504，前端业务处理装置6包括发送模块601、重试模块602、接收模块604、订阅模块604以及显示模块605，其中发送模块601与业务请求接收模块501通信连接，业务请求篡改判断模块502、查询模块503、业务处理模块504与接收模块603通信连接。

本发明提供的方法、装置及系统，在服务端接收到业务请求之后，先判断业务请求是否被篡改，只有未被篡改才能执行后续的业务逻辑处理操作，确保业务请求结果的准确性，从而保证处理结果推送的正确性。通过判断分布式业务处理集合中是否存在第一业务请求标识，保证了多个服务之间不会冲突的问题，并确保只有一个相同请求在处理。当分布式业务处理集合中存在第一业务请求标识时，说明该业务请求是一个重复的业务请求(可能为重试请求)，此时服务端接收到重复的业务请求，不再根据重复的业务请求再执行全部的完整的业务处理逻辑，从而避免当业务逻辑比较复杂或外部接口延时时，接口处理时间超出终端设置的超时时间，无论重试多次，在重试限制次数内均无法获取到结果，导致最终业务请求失败的问题，同时也避免了浪费服务器资源的问题。在用户终端，收到服务端的第二提示信息之后，直接根据第一业务请求标识在分布式消息处理系统中订阅业务请求的处理结果，分布式消息处理系统中接收到服务端发送的处理结果后，能够及时将处理结果推送给用户终端，使用户终端能够在第一时间获得处理结果，不会让用户终端产生无效的等待时间。利用消息订阅(在分布式消息处理系统中订阅处理结果)，代替了重复调用接口，使用户终端无需每隔一段时间就与服务端进行连接，进行重复业务请求以获得处理结果，减少了与服务器连接次数，降低了服务器的连接请求及带宽占用压力。

本发明说明书中使用的术语和措辞仅仅为了举例说明，并不意味构成限定。本文中在本发明的权利要求书、说明书中所使用的“第一”、“第二”只是为了便于区分的目的，没有特殊含义，不是旨在于限制本发明。本领域技术人员应当理解，在不脱离所公开的实施方式的基本原理的前提下，对上述实施方式中的各细节可进行各种变化。因此，本发明的范围只由权利要求确定，在权利要求中，除非另有说明，所有的术语应按最宽泛合理的意思进行理解。

Claims (10)

1.一种业务请求处理方法，其特征在于，所述方法包括：

接收用户终端发送的业务请求，从所述业务请求中获取第一业务请求标识，所述第一业务请求标识为用户终端根据所述业务请求的原始业务请求参数以及预设的业务请求标识生成策略生成；

根据所述第一业务请求标识以及预设的业务请求篡改判断策略，判断所述业务请求是否被篡改，若是，向用户终端返回第一提示信息，以提示出现异常情况；否则，判断在分布式业务处理集合中是否存在所述第一业务请求标识；

若不存在，将所述第一业务请求标识加入到所述分布式业务处理集合中，并执行所述业务请求的业务逻辑，生成处理结果，将处理结果写入到分布式消息处理系统中，并向用户终端同步返回处理结果；

若存在，向用户终端返回第二提示信息，以使用户终端在接收到所述第二提示信息后，根据所述第一业务请求标识在所述分布式消息处理系统中订阅所述业务请求的处理结果。

2.根据权利要求1所述的业务请求处理方法，其特征在于，所述业务请求篡改判断策略包括：

从所述业务请求中获取当前业务请求参数，根据所述当前业务请求参数以及所述业务请求标识生成策略生成第二业务请求标识；

判断所述第二业务请求标识与所述第一业务请求标识是否相同，若是，判定所述业务请求未被篡改，否则，判定所述业务请求被篡改。

3.根据权利要求2所述的业务请求处理方法，其特征在于，所述业务请求标识生成策略包括：

获取业务请求参数，按照所述业务请求参数的参数名称对所述业务请求参数进行排序；

根据MD5信息摘要算法对排序后的所述业务请求参数进行处理，生成32位字符串作为业务请求标识。

4.根据权利要求3所述的业务请求处理方法，其特征在于，所述业务请求参数为加入随机码后的业务请求参数，所述随机码由所述用户终端生成，每个业务请求对应唯一一个随机码。

5.一种业务请求处理方法，其特征在于，所述方法包括：

向服务端发送业务请求，所述业务请求中包括原始业务请求参数以及用于唯一标识所述业务请求的第一业务请求标识，所述第一业务请求标识为根据所述原始业务请求参数以及预设的业务请求标识生成策略生成；

若发生预设的重试条件，向服务端重新发送所述业务请求，并在接收到服务端返回的第二提示信息后，根据所述第一业务请求标识在分布式消息处理系统中订阅所述业务请求的处理结果，同时设置结果等待超时时间；

若在所述结果等待超时时间内，接收到所述分布式消息处理系统推送的处理结果，将所述处理结果予以显示，否则，取消订阅，生成结果等待超时信息，并将所述结果等待超时信息予以显示。

6.根据权利要求5所述的业务处理方法，其特征在于，所述预设的重试条件包括业务请求超时或者业务请求中断。

7.一种服务端业务处理装置，其特征在于，所述服务端业务处理装置包括：业务请求接收模块、业务请求篡改判断模块、查询模块、业务处理模块，其中：

所述业务请求接收模块，与所述业务请求篡改判断模块连接，用于接收用户终端发送的业务请求；

所述业务请求篡改判断模块，与所述查询模块连接，用于从所述业务请求中获取第一业务请求标识，所述第一业务请求标识为用户终端根据所述业务请求的原始业务请求参数以及预设的业务请求标识生成策略生成，根据所述第一业务请求标识以及预设的业务请求篡改判断策略，判断所述业务请求是否被篡改，若是，向用户终端返回第一提示信息，否则，控制所述查询模块执行查询操作；

所述查询模块，与所述业务处理模块连接，用于执行查询操作，所述查询操作包括判断在分布式业务处理集合中是否存在所述第一业务请求标识，若存在，向用户终端返回第二提示信息，以使用户终端在接收到所述第二提示信息后，根据所述第一业务请求标识在所述分布式消息处理系统中订阅所述业务请求的处理结果，若不存在，将所述第一业务请求标识加入到所述分布式业务处理集合中，并控制所述业务处理模块执行业务处理操作；

所述业务处理模块，用于执行业务处理操作，所述执行业务处理操作为执行所述业务请求的业务逻辑，生成处理结果，所述业务处理模块还用于将所述处理结果写入到所述分布式消息处理系统中，并向用户终端同步返回处理结果。

8.根据权利要求7所述的服务端业务处理装置，其特征在于，所述业务请求篡改判断模块还包括第二业务请求标识生成单元以及判断单元，其中：

所述第二业务请求标识生成单元，与所述判断单元连接，用于从所述业务请求中获取当前业务请求参数，根据所述当前业务请求参数以及所述业务请求标识生成策略生成第二业务请求标识；

所述判断单元，用于判断所述第二业务请求标识与所述第一业务请求标识是否相同，若是，判定所述业务请求未被篡改，否则，判定所述业务请求被篡改。

9.一种前端业务处理装置，其特征在于，所述前端业务处理装置包括发送模块、重试模块、接收模块、订阅模块以及显示模块，其中：

所述发送模块，与所述重试模块连接，用于向服务端发送业务请求，所述业务请求中包括所述原始业务请求参数以及用于唯一标识所述业务请求的第一业务请求标识；

所述重试模块，用于若发生预设的重试条件，控制所述发送模块向服务端重新发送所述业务请求；

所述接收模块，与所述订阅模块以及所述显示模块连接，用于接收服务端返回的提示消息以及处理结果，所述提示消息包括用于提示业务请求被篡改的第一提示信息以及用于提示业务请求的处理状态为处理中或已处理的第二提示信息；

所述订阅模块，还与所述发送模块连接，用于在接收到服务端返回的第二提示信息后，根据所述第一业务请求标识在分布式消息处理系统中订阅所述业务请求的处理结果，同时设置结果等待超时时间；若在所述结果等待超时时间内，接收到所述分布式消息处理系统推送的处理结果，将所述处理结果发送至所述显示模块，否则，取消订阅，并生成结果等待超时信息，将所述结果等待超时信息发送至所述显示模块；

所述显示模块，用于对接收到的所述第一提示信息、第二提示信息、处理结果或结果等待超时信息进行显示。

10.一种业务请求处理系统，其特征在于，所述系统包括如权利要求7或8所述的服务端业务处理装置以及如权利要求9所述的前端业务处理装置，所述服务端业务处理装置与所述前端业务处理装置之间进行信息交互，以实现对业务请求的处理。

Images