Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Fig. 1 is a process of service processing provided in an embodiment of the present application, which specifically includes the following steps:
s101: and the intermediate equipment receives the service request sent by the terminal.
In practical applications, when people want to complete some services, the services can be executed through an intelligent terminal such as a computer, a smart phone, a tablet computer, and the like, and in general, the terminal can first send a service request corresponding to the services to a main repository or a standby repository, so that the main repository or the standby repository completes processing of services required by a user after receiving the service request.
In order to solve the problem that the idempotency of processing the service request cannot be guaranteed when the main library is down in the prior art, in the embodiment of the application, the intermediate device is added between the user terminal and the main library or the standby library, the intermediate device receives the service request sent by the terminal and performs idempotency operation on the service request, that is, when a user needs to execute a service, the terminal can be used for sending the service request to the intermediate device first, so that the intermediate device performs idempotency operation on the service request through the subsequent steps S102 to S104 after receiving the service request. The intermediate device may be any device having a forwarding function, and in practical application, the intermediate device needs to receive service requests sent by multiple users, so the intermediate device provided in the embodiment of the present application may be a distributed cache.
S102: and judging whether the service request exists in the history request locally stored in the intermediate device, if so, executing step S103, and if not, executing step S104.
S103: the service request is not processed.
S104: and storing the service request as a history request in a local place, and sending the service request to a main library or a standby library for processing.
When the intermediate device receives a service request sent by a user terminal, the service request and a history request locally stored by the intermediate device can be matched item by item, whether the service request identical to the service request exists in the local of the intermediate device or not is judged, if yes, the service request is determined to be a repeated request, therefore, the intermediate device does not perform subsequent processing on the service request, if not, the service request is determined not to be a repeated request, the intermediate device can store the service request as the history request in the local and send the service request to a main library or a standby library, so that the main library or the standby library can process the service request after receiving the service request, obtain a service processing result and further complete the whole service processing process. Subsequently, if the intermediate device receives the same service request as the service request again, since the service request is stored locally as a history request before, it can be determined that the service request received again is a repeat request, and further, the service request is not subjected to subsequent processing.
In the method, because the intermediate device for ensuring the power of the service request is added between the terminal and the main library or the standby library, when the terminal sends the service request to the main library or the standby library, the service request needs to be subjected to power-equal judgment of the intermediate device, and only when the intermediate device determines that the service request is a non-repeated request, the intermediate device can further send the service request to the main library or the standby library for processing, so that even if the main library is down, the standby library cannot receive the service request which is received by the main library, compared with the prior art that the power of the service request is ensured by the main library or the standby library, the power of the service request can be effectively ensured, and the accuracy of a service processing result is improved.
In this embodiment of the present application, when determining whether there is a received service request in a locally stored history request, the intermediary device may match each history request by using a service request identifier included in the service request, where the service request identifier may be a service ID, such as a transaction serial number, a payment serial number, and the like, that is generated by the terminal when generating the service request, or a service request identifier determined by the terminal or the intermediary device according to an algorithm and the content of the service request, that is, as long as the uniqueness of the service request identifier is ensured.
For example, the terminal or the intermediate device may determine a unique service request identifier of the service request according to contents of user account information, a service single number, and the like in the service request through a preset MD5 algorithm, where contents included in different service requests are different, and therefore, for two same service requests, service request identifiers respectively determined by the terminal or the intermediate device are also certain identical, and therefore, the intermediate device may effectively distinguish each service request through the service request identifier, and further may accurately judge whether the service request exists locally in the intermediate device in a subsequent process.
In practical application, considering that the storage space of the intermediate device is limited and cannot store a large number of service requests, and if the intermediate device stores a large number of service requests, the operation load of the intermediate device may be increased and the operation efficiency may be reduced, in this embodiment of the present application, a data sub-library for storing the expired service requests of the intermediate device is further provided, wherein when the storage time of the history requests stored in the intermediate device exceeds the preset storage time, the intermediate device may use the history requests exceeding the preset storage time as the expired service requests and send the expired service requests to the data sub-library added in advance for storage, so that the storage space of the intermediate device is released well, and the subsequent work efficiency can be effectively ensured. On this basis, the embodiment of the present application further provides another service processing method, as shown in fig. 2.
Fig. 2 is another process of service processing provided in the embodiment of the present application, which specifically includes the following steps:
s201: the client generates a service request.
In practical applications, when people want to execute services, the services can be executed through a client installed on an intelligent terminal such as a computer, a smart phone, a tablet computer, and the like, in general, a user can execute corresponding operations according to a service processing interface provided by the client on a terminal interface for the user, and the client can generate corresponding service requests according to the service operations executed by the user, and further can send the service requests outwards.
S202: and judging whether the service request exists in the history request locally stored in the database, if so, executing step S203, and if not, executing step S204.
S203: the service request is not processed.
S204: and sending the service request to the intermediate equipment, so that after receiving the service request, the intermediate equipment does not process the service request when determining that the service request exists in the history request locally stored by the intermediate equipment, stores the service request as the history request locally in the intermediate equipment when determining that the service request does not exist in the history request locally stored by the intermediate equipment, and sends the service request to a main library or a standby library for processing.
Because the data sub-base is additionally arranged, before the client sends the service request to the intermediate device, the client needs to firstly call the history request locally stored in the data sub-base from the data sub-base to judge whether the service request already exists in the history requests, and the aim is that in practical application, the client may not know whether the history request locally stored in the intermediate device is transferred to the data sub-base for storage, if the service request is directly sent to the intermediate device, the situation that the intermediate device transfers the same service request received before to the data sub-base for storage may occur, so that the problem that the intermediate device cannot effectively ensure the idempotent after receiving the service request again is caused. Therefore, the client may retrieve each history request from the database, determine whether the service request to be sent already exists in the retrieved history requests, wherein the specific determination manner may also be determined by the service request identifier mentioned in step S102, that is, extract the service request identifier from the service request, and match the retrieved history requests one by one according to the service request identifier, if there is no history request matching the service request identifier in the history requests, the client may send the service request to the intermediate device, so that after receiving the service request, the intermediate device does not process the service request when determining that there is a service request in the history requests locally stored by the intermediate device, and when determining that there is no service request in the history requests locally stored by the intermediate device, and if the history request does not have the history request matched with the service request identifier, the client does not perform subsequent processing on the service request, namely the service request is not sent to the intermediate equipment.
It should be noted that, in the above-described determining process, if the client side invokes all the history requests locally stored in the data sub-database, the operation speed of the terminal is greatly reduced, so that, in the process of invoking the history requests from the data sub-database, the client side may only invoke each history request matching with the user identifier in the service request, for example, the history request under the user account information is invoked from the data sub-database through the user account information included in the service request, thereby greatly saving the operation space of the terminal and increasing the operation speed of the terminal.
In the step S102, in the process of determining whether the service request exists in the locally stored history request, if the service request identifier extracted from the service request is matched with all locally stored history requests one by one, the operation load of the intermediate device may be increased, and the operation efficiency of the intermediate device is reduced, so in this embodiment of the application, the intermediate device also adopts the same method as that in the step S202, that is, the user identifier of information such as a user account may be extracted from the service request, and the history request under the user identifier is called from the local, thereby greatly saving the determination time of the service request, and improving the processing efficiency of the intermediate device.
In the step S202, when the client finds that the service request to be sent already exists in the history request locally stored in the database, the client may prompt the user, that is, prompt the user that the service request has been sent before, and does not need to be sent again. Similarly, in step S102, after the intermediate device receives the service request sent by the terminal and finds that the service request already exists in the history request stored locally, a prompt indicating that the service request already exists or has been processed may be sent to the terminal, so that the terminal displays the prompt to the user after receiving the prompt, and after checking the prompt, the user may know that the service request just sent is a service request repeatedly sent, and the intermediate device does not process the service request.
Based on the two service processing methods provided in the embodiments of the present application, a service processing system is also provided in the embodiments of the present application, as shown in fig. 3.
Fig. 3 is a schematic diagram of a system for service processing according to an embodiment of the present application.
The service processing system shown in fig. 3 includes an intermediate device, where the intermediate device may receive service requests sent by each terminal, and perform an idempotent operation on each service request, and if the intermediate device determines that the received service request is a new service request, the intermediate device may send the service request to the main repository or the standby repository for processing according to the actual situation, where the service request is sent to the main repository when the main repository is operating normally, and the service request is sent to the standby repository for processing when the main repository is down. Before each terminal sends a service request to the intermediate device, it needs to first retrieve a history request stored in the data sub-database from the data sub-database set in the system to determine whether the service request to be sent to the intermediate device is a repeat request.
Based on the service processing system described above, the embodiment of the present application further provides a detailed process of service processing, as shown in fig. 4.
Fig. 4 is a detailed process of service processing provided in the embodiment of the present application, which specifically includes the following steps:
s401: the client generates a service request.
S402: and judging whether the service request exists in the history request locally stored in the database, if so, executing step S403, and if not, executing step S404.
S403: the service request is not processed.
S404: and sending the service request to the intermediate equipment.
S405: the intermediate device determines whether the service request exists in the history request locally stored in the intermediate device, if so, executes step S406, and if not, executes step S407.
S406: the service request is not processed.
S407: and storing the service request as a history request in a local place, and sending the service request to a main library or a standby library for processing.
Based on the same idea, the two service processing methods provided in the embodiments of the present application further provide two service processing apparatuses, as shown in fig. 5 and fig. 6.
Fig. 5 is a schematic structural diagram of a service processing apparatus provided in an embodiment of the present application, which specifically includes:
a receiving module 501, configured to receive a service request sent by a terminal;
a judgment processing module 502, configured to judge whether the service request exists in a history request locally stored in the apparatus; if yes, the service request is not processed; if not, the service request is stored locally as a history request, and the service request is sent to a main library or a standby library for processing.
The service request comprises a service request identifier;
the judgment processing module 502 is specifically configured to judge whether a history request corresponding to the service request identifier exists in a history request locally stored by the apparatus; if yes, determining that the service request exists in the history request locally stored by the device; if not, determining that the service request does not exist in the history requests locally stored by the device.
The sending module 503 is configured to send the history request with the storage time exceeding the preset storage time to the data sub-database for storage.
Fig. 6 is a schematic structural diagram of another service processing apparatus provided in an embodiment of the present application, which specifically includes:
a request generating module 601, configured to generate a service request;
a judging and sending module 602, configured to judge whether the service request exists in a history request locally stored in a database; if yes, the service request is not processed; if not, the service request is sent to the intermediate device, so that after the intermediate device receives the service request, when the service request is determined to exist in the history request locally stored by the intermediate device, the service request is not processed, and when the service request is determined not to exist in the history request locally stored by the intermediate device, the service request is stored locally in the intermediate device as the history request and is sent to the main library or the standby library for processing.
The judgment sending module 602 is specifically configured to invoke each history request matched with the user identifier in the data sub-base according to the user identifier carried in the service request; and judging whether the service request exists in the called historical requests or not according to the called historical requests.
The embodiment of the application provides a method and a device for processing a service, the method comprises the steps that after a service request sent by a terminal is received by an intermediate device, whether the service request exists in a history request locally stored in the intermediate device is judged, if yes, the service request is not subjected to subsequent processing, if not, the service request is stored locally in the intermediate device as the history request and is sent to a main library or a standby library, and the main library or the standby library processes the service request after receiving the service request. According to the method, the intermediate device is used for performing idempotent operation on the service request, but not the main library or the standby library, so that even if the main library is down and the service request is processed by the standby library, the main library does not process the service request again after the main library is recovered to be normal, and compared with the prior art that the main library or the standby library is used for ensuring the idempotent of the service request, the method can effectively ensure the idempotent of the service request and improve the accuracy of a service processing result.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.