CN106921712B - Service processing method and device - Google Patents
Service processing method and device Download PDFInfo
- Publication number
- CN106921712B CN106921712B CN201510998966.3A CN201510998966A CN106921712B CN 106921712 B CN106921712 B CN 106921712B CN 201510998966 A CN201510998966 A CN 201510998966A CN 106921712 B CN106921712 B CN 106921712B
- Authority
- CN
- China
- Prior art keywords
- service request
- request
- library
- history
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000003672 processing method Methods 0.000 title description 5
- 238000012545 processing Methods 0.000 claims abstract description 82
- 238000000034 method Methods 0.000 claims abstract description 57
- 230000008569 process Effects 0.000 abstract description 28
- 238000010586 diagram Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/562—Brokering proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Abstract
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. In the method, the intermediate device is used for performing idempotent operation on the service request, 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 being recovered to be normal, and compared with the prior art, the idempotent of the service request can be ensured, and the accuracy of a service processing result is improved.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for processing a service.
Background
With the rapid development of network technology, the network can enable people to get rid of the traditional offline mode, and can complete the processing of some services on the network, thereby greatly facilitating the convenience of users when processing the services.
In practical applications, the accuracy of the service processing results is usually extremely important, and in order to effectively ensure the accuracy of the service processing results, in the prior art, the accuracy is usually ensured by using idempotent operations, wherein one idempotent operation is characterized in that the idempotent operation performs the same request any number of times, and the generated influence is the same, which has the main significance that: when the operation does not reach the expected target, the user can continuously retry the operation without causing side effect on the resources.
For example, when a user wants to perform a service, the user can send a service request to the data master through the used terminal, and after receiving the service request, the data master judges whether the service request is a repeat request, if so, the service request is not processed, and if not, the service request is processed, so that the accuracy of the data master in processing the service is ensured.
However, in practical applications, if the main database goes down after the user sends the service request to the main database through the terminal, the system will start the standby database to continue receiving the service request sent by the user, and suspend the main database from receiving the service request. At this time, due to the situations of misoperation, forgetting whether the service request is sent by the user, and the like, and the user repeatedly sends the same service request once, the data backup library receives the service request repeatedly sent by the user, wherein the service request does not appear in the data backup library before, and therefore the data backup library processes the service request. However, when the data backup library completes processing of the service request, and the data master library recovers normal operation, the data master library will continue to process the previously received service request, so that the data master library and the data backup library process one service request twice, and further, the idempotent of processing one service request cannot be effectively ensured.
Disclosure of Invention
The embodiment of the application provides a method and a device for service processing, which are used for solving the problem that the idempotent of a service request cannot be effectively ensured when the service request is processed in the prior art.
The method for processing the service provided by the embodiment of the application comprises the following steps:
the intermediate equipment receives a service request sent by a terminal;
judging whether the service request exists in a history request locally stored by the intermediate device;
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 method for processing the service provided by the embodiment of the application comprises the following steps:
a client generates a service request;
judging whether the service request exists in a history request locally stored in a data sub-base;
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.
An apparatus for processing a service provided in an embodiment of the present application includes:
the receiving module is used for receiving a service request sent by a terminal;
the judging and processing module is used for judging whether the service request exists in the history request locally stored by the device; 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.
An apparatus for processing a service provided in an embodiment of the present application includes:
the request generating module is used for generating a service request;
the judging and sending module is used for judging whether the service request exists in the history request locally stored in the 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 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.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a process of service processing provided in an embodiment of the present application;
fig. 2 is a process of another service processing provided in the embodiment of the present application;
fig. 3 is a schematic system diagram of service processing provided in an embodiment of the present application;
fig. 4 is a detailed process of service processing provided in an embodiment of the present application;
fig. 5 is a schematic structural diagram of a service processing apparatus according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of another service processing apparatus according to an embodiment of the present application.
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.
Claims (11)
1. A method for processing services, comprising:
the intermediate equipment receives a service request sent by a terminal;
judging whether the service request exists in a history request locally stored by the intermediate device;
if yes, the service request is not processed;
if not, storing the service request as a history request in the local, and sending the service request to a main library or a standby library for processing;
the not processing the service request comprises: if the main library is down, the service request is not sent to a standby library corresponding to the main library, wherein the main library receives the service request before the down;
the sending the service request to a main library or a standby library for processing comprises: and if the main library is down, sending the service request to the standby library.
2. The method of claim 1, wherein the service request includes a service request identifier;
judging whether the service request exists in the history request locally stored in the intermediate device, specifically including:
judging whether a history request corresponding to the service request identifier exists in the history request locally stored by the intermediate device;
if yes, determining that the service request exists in the history request locally stored by the intermediate equipment;
if not, determining that the service request does not exist in the history request locally stored by the intermediate equipment.
3. The method of claim 1, wherein the method further comprises:
and sending the historical request with the storage time exceeding the preset storage time to a data sub-database for storage.
4. The method of claim 1, wherein the intermediary device comprises a distributed cache.
5. A method for processing services, comprising:
a client generates a service request;
judging whether the service request exists in a history request locally stored in a data sub-base;
if yes, the service request is not processed;
if not, the service request is sent to the intermediate equipment, so that after the intermediate equipment receives the service request, when the service request is determined to exist in the history request locally stored by the intermediate equipment, 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 equipment, the service request is stored locally in the intermediate equipment as the history request and is sent to the main library or the standby library for processing;
the not processing the service request comprises: if the main library is down, the service request is not sent to a standby library corresponding to the main library, wherein the main library receives the service request before the down;
the sending the service request to a main library or a standby library for processing comprises: and if the main library is down, sending the service request to the standby library.
6. The method of claim 5, wherein determining whether the service request exists in a history request locally stored in a database specifically comprises:
calling each history request matched with the user identification in the data sub-base according to the user identification 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.
7. An apparatus for traffic processing, comprising:
the receiving module is used for receiving a service request sent by a terminal;
the judging and processing module is used for judging whether the service request exists in the history request locally stored by the device; if yes, the service request is not processed; if not, storing the service request as a history request in the local, and sending the service request to a main library or a standby library for processing;
the not processing the service request comprises: if the main library is down, the service request is not sent to a standby library corresponding to the main library, wherein the main library receives the service request before the down;
the sending the service request to a main library or a standby library for processing comprises: and if the main library is down, sending the service request to the standby library.
8. The apparatus of claim 7, wherein the service request includes a service request identifier;
the judging and processing module is specifically configured to judge whether a history request corresponding to the service request identifier exists in a history request locally stored by the device; 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.
9. The apparatus of claim 7, wherein the apparatus further comprises:
and the sending module is used for sending the historical request with the storage time exceeding the preset storage time to the data sub-database for storage.
10. An apparatus for traffic processing, comprising:
the request generating module is used for generating a service request;
the judging and sending module is used for judging whether the service request exists in the history request locally stored in the database; if yes, the service request is not processed; if not, the service request is sent to the intermediate equipment, so that after the intermediate equipment receives the service request, when the service request is determined to exist in the history request locally stored by the intermediate equipment, 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 equipment, the service request is stored locally in the intermediate equipment as the history request and is sent to the main library or the standby library for processing;
the not processing the service request comprises: if the main library is down, the service request is not sent to a standby library corresponding to the main library, wherein the main library receives the service request before the down;
the sending the service request to a main library or a standby library for processing comprises: and if the main library is down, sending the service request to the standby library.
11. The apparatus according to claim 10, wherein the determining and sending module is specifically configured to invoke, according to a user identifier carried in the service request, each history request matched with the user identifier in the data sub-base; and judging whether the service request exists in the called historical requests or not according to the called historical requests.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510998966.3A CN106921712B (en) | 2015-12-28 | 2015-12-28 | Service processing method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510998966.3A CN106921712B (en) | 2015-12-28 | 2015-12-28 | Service processing method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106921712A CN106921712A (en) | 2017-07-04 |
| CN106921712B true CN106921712B (en) | 2020-07-03 |
Family
ID=59454895
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510998966.3A Active CN106921712B (en) | 2015-12-28 | 2015-12-28 | Service processing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106921712B (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108415792B (en) * | 2018-01-15 | 2022-04-29 | 创新先进技术有限公司 | Disaster recovery system, method, device and equipment |
| CN108647105B (en) * | 2018-05-22 | 2022-02-01 | 创新先进技术有限公司 | Idempotent control method, device and system in system switching process |
| CN109902077B (en) * | 2018-12-29 | 2023-08-11 | 创新先进技术有限公司 | Service request processing method, device and equipment |
| CN110740163B (en) * | 2019-09-04 | 2021-04-02 | 华云数据控股集团有限公司 | Idempotent control method, idempotent control device, electronic equipment and readable storage medium |
| CN110908838B (en) * | 2019-11-19 | 2022-09-02 | 杭州安恒信息技术股份有限公司 | Data processing method and device, electronic equipment and storage medium |
| CN113626176A (en) * | 2020-05-08 | 2021-11-09 | 北京沃东天骏信息技术有限公司 | Service request processing method and device |
| CN111800512B (en) * | 2020-07-07 | 2023-08-04 | 深圳前海百递网络有限公司 | Data transmission method and server |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101420667A (en) * | 2007-10-24 | 2009-04-29 | 中兴通讯股份有限公司 | A kind of method of short message gateway processing waiting receipt message |
| CN103095691A (en) * | 2012-12-31 | 2013-05-08 | 清华大学 | Method of controlling access to Internet of things nodes |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7519734B1 (en) * | 2006-03-14 | 2009-04-14 | Amazon Technologies, Inc. | System and method for routing service requests |
| US8473783B2 (en) * | 2010-11-09 | 2013-06-25 | International Business Machines Corporation | Fault tolerance in distributed systems |
| GB2496377B (en) * | 2011-11-02 | 2014-07-30 | Ibm | Message reconciliation during disaster recovery |
-
2015
- 2015-12-28 CN CN201510998966.3A patent/CN106921712B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101420667A (en) * | 2007-10-24 | 2009-04-29 | 中兴通讯股份有限公司 | A kind of method of short message gateway processing waiting receipt message |
| CN103095691A (en) * | 2012-12-31 | 2013-05-08 | 清华大学 | Method of controlling access to Internet of things nodes |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106921712A (en) | 2017-07-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106921712B (en) | Service processing method and device | |
| EP3886403B1 (en) | Block chain service acceptance and consensus method and device | |
| EP3547170B1 (en) | Blockchain-based consensus method and device | |
| EP3547648B1 (en) | Service processing and consensus method and device | |
| EP3221795B1 (en) | Service addressing in distributed environment | |
| CN107276970B (en) | Unbinding and binding method and device | |
| CN107153644B (en) | Data synchronization method and device | |
| CN106878367B (en) | Method and device for realizing asynchronous call of service interface | |
| CN110992188B (en) | Transaction processing method, device and equipment | |
| CN107016016B (en) | Data processing method and device | |
| CN106897342B (en) | Data verification method and equipment | |
| CN114328029B (en) | Backup method and device of application resources, electronic equipment and storage medium | |
| CN111245897B (en) | Data processing method, device, system, storage medium and processor | |
| KR102114532B1 (en) | Information operation | |
| CN105354195B (en) | Information searching method and device | |
| CN114745133A (en) | Method and device for identifying uniqueness of equipment | |
| WO2016197853A1 (en) | Complexity-based service processing method and apparatus | |
| CN107276998B (en) | OpenSSL-based performance optimization method and device | |
| CN110992039B (en) | Transaction processing method, device and equipment | |
| CN107169752B (en) | Resource transfer method and device | |
| CN106156185B (en) | Method, device and system for inquiring service request execution state | |
| CN111159298A (en) | Service request processing method and device, electronic equipment and storage medium | |
| CN110764930A (en) | Request or response processing method and device based on message mode | |
| CN112491943A (en) | Data request method, device, storage medium and electronic equipment | |
| CN108023920B (en) | Data packet transmission method, equipment and application interface |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20200925 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20200925 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Patentee before: Alibaba Group Holding Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20240301 Address after: 128 Meizhi Road, Guohao Times City # 20-01, Singapore 189773 Patentee after: Advanced Nova Technology (Singapore) Holdings Ltd. Country or region after: Singapore Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee before: Innovative advanced technology Co.,Ltd. Country or region before: Cayman Islands |