CN109660589B - Request processing method and device and electronic equipment - Google Patents
Request processing method and device and electronic equipment Download PDFInfo
- Publication number
- CN109660589B CN109660589B CN201811252275.9A CN201811252275A CN109660589B CN 109660589 B CN109660589 B CN 109660589B CN 201811252275 A CN201811252275 A CN 201811252275A CN 109660589 B CN109660589 B CN 109660589B
- Authority
- CN
- China
- Prior art keywords
- processing result
- network request
- request
- client
- server
- 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
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/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
- H04L67/62—Establishing a time schedule for servicing the requests
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
One or more embodiments of the present specification provide a request processing method and apparatus, and an electronic device, where the method may include: receiving a network request sent by a client; storing a processing result for the network request when the network request is received for the first time; and when the network request is not received for the first time, reading a processing result aiming at the network request, and returning the read processing result to the client.
Description
Technical Field
One or more embodiments of the present disclosure relate to the field of communications technologies, and in particular, to a request processing method and apparatus, and an electronic device.
Background
After the client establishes a session with the server, the client may send a network request to the server, so that the server responds to the network request for processing, and returns a corresponding processing result. And in the process of interaction between the client and the server, based on the existence of the timeout retry mechanism, when the client does not receive the processing result within a certain time, the client sends the same network request to the server again. In other words, the same network request may be received multiple times by the server during the interaction with the client.
Disclosure of Invention
In view of this, one or more embodiments of the present disclosure provide a request processing method and apparatus, and an electronic device.
To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:
according to a first aspect of one or more embodiments of the present specification, a request processing method is provided, which is applied to a server; the method comprises the following steps:
receiving a network request sent by a client;
storing a processing result for the network request when the network request is received for the first time;
and when the network request is not received for the first time, reading a processing result aiming at the network request, and returning the read processing result to the client.
According to a second aspect of one or more embodiments of the present specification, there is provided a data request method applied to a client; the method comprises the following steps:
sending a network request to a server; wherein the processing result for the network request is stored when the server receives the network request for the first time;
when the processing result returned by the server is not received within a preset waiting time, the network request is retransmitted, so that the server reads and returns the stored processing result;
and displaying the received first processing result, and discarding the other processing results except the first processing result.
According to a third aspect of one or more embodiments of the present specification, a request processing apparatus is provided, which is applied to a server; the device comprises:
the receiving unit is used for receiving a network request sent by a client;
the storage unit is used for storing a processing result aiming at the network request when the network request is received for the first time;
and the result returning unit is used for reading the processing result aiming at the network request and returning the read processing result to the client when the network request is not received for the first time.
According to a fourth aspect of one or more embodiments of the present specification, there is provided a data request apparatus, which is applied to a client; the device comprises:
the sending unit is used for sending a network request to the server; wherein the processing result for the network request is stored when the server receives the network request for the first time;
the resending unit resends the network request when the processing result returned by the server is not received within a preset waiting time so that the server reads and returns the stored processing result;
and the display unit displays the received first processing result and discards other processing results except the first processing result.
According to a fifth aspect of one or more embodiments herein, there is provided an electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor executes the executable instructions to implement the request processing method according to any of the above embodiments.
According to a sixth aspect of one or more embodiments herein, there is provided an electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor executes the executable instructions to implement the data request method according to any of the above embodiments.
Drawings
FIG. 1 is an architectural diagram illustrating a request processing system according to an exemplary embodiment.
FIG. 2 is a flow chart of a request processing method provided by an exemplary embodiment.
Fig. 3 is a flowchart of a data request method according to an example embodiment.
FIG. 4 is an interaction diagram that provides for repeatedly returning processing results in accordance with an exemplary embodiment.
FIG. 5 is a diagram illustrating the repeated return of processing results provided by an exemplary embodiment.
FIG. 6 is an interaction diagram of a return notification message provided by an exemplary embodiment.
Fig. 7 is a diagram illustrating a return notification message provided by an exemplary embodiment.
Fig. 8 is a schematic structural diagram of an apparatus according to an exemplary embodiment.
Fig. 9 is a block diagram of a request processing device according to an example embodiment.
Fig. 10 is a schematic structural diagram of another apparatus provided in an exemplary embodiment.
Fig. 11 is a block diagram of a data request device according to an example embodiment.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.
It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.
FIG. 1 is an architectural diagram illustrating a request processing system according to an exemplary embodiment. As shown in fig. 1, the system may include a server 11, a network 12, and several electronic devices, such as cell phones 13-14 and PCs 15-16.
The server 11 may be a physical server comprising a separate host, or the server 11 may be a virtual server carried by a cluster of hosts. During operation, the server 11 may run a server-side program of an application to implement relevant service functions of the application. In one or more embodiments of the present disclosure, the server 11 may serve as a server to receive network requests sent by electronic devices (e.g., the mobile phones 13-14 and the PCs 15-16) to implement a request processing scheme.
Cell phones 13-14 and PCs 15-16 are just one type of electronic device that a user may use. In fact, it is obvious that the user can also use electronic devices of the type such as: tablet devices, notebook computers, Personal Digital Assistants (PDAs), wearable devices (e.g., smart glasses, smart watches, etc.), etc., which are not limited by one or more embodiments of the present disclosure. During operation, the electronic device may run a client-side program of an application to implement a related service function of the application. In one or more embodiments of the present disclosure, the electronic device may serve as a client to send a network request to a server to implement a request processing scheme.
And the network 12 for interaction between the electronic device and the server 11 may include various types of wired or wireless networks. In one embodiment, the Network 12 may include the Public Switched Telephone Network (PSTN) and the Internet. Meanwhile, the electronic devices such as the mobile phones 13-14 and the PCs 15-16 can also carry out communication interaction through the network 12.
Referring to fig. 2, fig. 2 is a flowchart illustrating a request processing method according to an exemplary embodiment. As shown in fig. 2, the method applied to the server may include the following steps:
In this embodiment, after sending the network request, based on the existence of the timeout retry mechanism, when the processing result for the sent network request is not received within the preset time (i.e. waiting for a return timeout), the client will send the same network request to the server again. In other words, the server may receive the same network request multiple times. Therefore, after receiving the network request from the client, the server first enters a process of anti-repeat request check to determine whether the network request is received for the first time.
In an exemplary embodiment, a communication protocol between the client and the server has a parameter for checking against a repeat request agreed. Before sending the network request, the client generates the parameter as a request identifier of the network request, and adds the request identifier to the network request. And after receiving the network request from the client, the server firstly performs a process of anti-repeat request verification. Based on the network request including the request identifier, the server may locally query whether a key-value pair corresponding to the request identifier is recorded. When a certain network request is received for the first time, the key value pair corresponding to the request identifier does not exist locally, and then the key value pair taking the request identifier of the network request as a key is created locally. Further, entering a request processing flow to process the network request to generate a processing result for the network request; wherein the key value in the key value pair (i.e. the value with the request identifier as the key) is set to the committed state as a result of having entered the process flow (i.e. the network request is being processed). When the network request is not received for the first time, the server can locally find the key-value pair corresponding to the request identifier. Therefore, when the key value pair corresponding to the request identifier of the received network request exists locally, the server can determine that the network request is not received for the first time.
And step 204, storing the processing result aiming at the network request when the network request is received for the first time.
In this embodiment, when the network request is received for the first time, the network request is processed according to the request processing logic, and the generated processing result is stored. And meanwhile, returning the generated processing result to the client.
And step 206, when the network request is not received for the first time, reading a processing result aiming at the network request, and returning the read processing result to the client.
In this embodiment, when the network request is not received for the first time (i.e., the network request is not sent by the client for the first time), it indicates that the client does not receive the processing result when sending the network request (e.g., the processing result returned in step 204 is not temporarily transmitted to the client due to network delay). And based on the fact that the server stores the processing result, when the network request is not received for the first time, the processing result aiming at the network request can be directly read, and the read processing result is returned to the client. It can be seen that, by storing the processing result for any network request when the network request is received for the first time (when the network request is received for the first time, the processing result is also returned to the client), the requested processing result can be directly read and returned to the client when the network request is still received in the subsequent time (in the case that the server has returned the processing result to the client but the client has triggered the timeout retry mechanism). On one hand, the server can prevent the server from repeatedly processing the same network request by inquiring whether the processing result corresponding to the received network request is stored or not; on the other hand, when the processing result corresponding to the received network request is stored, the processing result is directly read and returned to the client, so that the client can receive the processing result as soon as possible, and the efficiency of the server for processing the network request is improved. Meanwhile, when the server receives the same network request again, by the processing mode for the same network request (storing the processing result when the network request is received for the first time), error information representing repeated requests does not need to be returned to the client, and the fact that the client cannot display the subsequently received processing result due to error reporting (error reporting after the error information is received) is avoided.
In this embodiment, when the network request is not received for the first time, in addition to the above case where the processing result for the network request has been generated, the server may be processing the network request, that is, not generating the processing result. Therefore, when the network request is not received for the first time and the processing result is not generated, a notification message indicating that the network request is being processed may be returned to the client. Then the client may not need to report an error after receiving the notification message. For example, one may continue to wait for processing results. Or, when the network request is not received for the first time and the processing result is not generated, the server may not respond to the network request, that is, directly ignore the network request that is not received for the first time.
Based on the mechanism that the network request is configured with the request identifier, since the network request includes the request identifier, when the network request is received for the first time, the key value using the request identifier as a key is set to be in the submitted state, that is, the locally stored key value pair is "request identifier — submitted state"; wherein the committed state is used to indicate that the processing result was not generated. And when the processing result is generated, the key value can be set as the processing result, namely, the locally stored key value pair is updated to be 'request identification-processing result'. In other words, when the server receives the same network request again, the value in the key value pair corresponding to the network request can be directly read locally, and the value can be used as a processing result and returned to the client.
In this embodiment, the effective duration may also be preset for the processing result stored locally. When the storage duration of the processing result exceeds the preset effective duration, the processing result can be deleted, so that the occupation of the storage space in the server side is reduced.
Accordingly, referring to fig. 3, fig. 3 is a flowchart of a data request method according to an exemplary embodiment. As shown in fig. 3, the method applied to the client may include the following steps:
In this embodiment, the interaction process between the client and the server specifically refers to the embodiment shown in fig. 2, and is not described herein again. Based on the timeout retry mechanism of the client and the mechanism that the server directly returns the stored processing result when receiving the same network request again, the client may receive multiple processing results (all for the same network request), and then the client may display only the first received processing result and discard the processing results other than the first processing result.
For ease of understanding, the request processing scheme of the present specification is described in detail below with reference to examples and the accompanying drawings.
Referring to fig. 4, fig. 4 is an interaction diagram of a process result repeatedly returned according to an exemplary embodiment. As shown in fig. 4, the method may include the steps of:
in step 402, the client generates a request identifier.
In this embodiment, a parameter for checking an anti-repeat request is agreed in a communication protocol between the client and the server, and before the client sends a network request, the client generates the parameter as a request identifier of the network request and adds the request identifier to the network request. The following description will take the request identifier as a dpkey as an example. For example, the client may upload a random string of fixed numbers and concatenate with the name of the current request to get a dpkey.
In step 404, the client sends a network request to the server.
In step 406, the server creates a key-value pair after receiving the network request.
At step 408, the server processes the network request.
In this embodiment, after receiving a network request from a client, a server performs a process of checking an anti-duplication request. Based on the network request including the dpkey, the server can locally inquire whether a key value pair corresponding to the dpkey is recorded. For example, the server may configure a preset cache for storing key-value pairs. And when the key value pair corresponding to the dpkey is found in the cache, the server side is explained to receive the network request for the first time, and then the key value pair taking the dpkey as the key is established in the cache. Further, the server enters a request processing flow, and processes the network request according to the server processing logic to generate a processing result for the network request. Wherein, since the processing flow is entered (i.e. the network request is being processed), the server can set the key value in the key value pair (i.e. the value corresponding to the dpkey) to the committed state. For example, a value of "1" indicates a committed state.
And step 410, the server stores the processing result in a cache.
In this embodiment, after the server generates the processing result, the value of the key-value pair created in step 406 may be set as the generated processing result (at this time, the key-value pair is "dpkey — processing result"), that is, the generated processing result is stored in the cache. Meanwhile, the server returns the generated processing result to the client.
In this embodiment, the service end may further set an effective duration for the stored processing result. When the storage duration of the processing result exceeds the preset effective duration, the processing result can be deleted, so that the occupation of the storage space in the server side is reduced.
In step 412, the client resends the network request.
In this embodiment, due to network delay and the like, the processing result returned by the server cannot reach the client in time. When the processing result for the sent network request is not received within the preset time (i.e. waiting for the return timeout), the client sends the same network request to the server again. In other words, the server may receive the same network request multiple times. Therefore, after receiving a network request from the client each time, the server first enters a process of anti-repeat request check to determine whether the network request is received for the first time. Since the server generates a key value pair (the key value pair is "dpkey — processing result") corresponding to the network request in step 406, the server can find the key value pair in the cache after receiving the same network request, and can obtain the processing result of the network request according to the key value pair.
In step 414, the server reads the processing result from the cache.
In this embodiment, when the same network request is not received for the first time (i.e., the network request is not sent by the client for the first time), it indicates that the client does not receive the processing result when sending the network request (e.g., the returned processing result is not temporarily transmitted to the client due to network delay). And based on the fact that the server stores the processing result, when the network request is not received for the first time, the processing result aiming at the network request can be directly read, and the read processing result is returned to the client. By storing the processing result for any network request when the network request is received for the first time (when the network request is received for the first time, the processing result is also returned to the client), the requested processing result can be directly read and returned to the client when the network request is still received in the following (in the case that the server has returned the processing result to the client but the client has triggered the timeout retry mechanism). On one hand, the server can prevent the server from repeatedly processing the same network request by inquiring whether the processing result corresponding to the received network request is stored or not; on the other hand, when the processing result corresponding to the received network request is stored, the processing result is directly read and returned to the client, so that the client can receive the processing result as soon as possible, and the efficiency of the server for processing the network request is improved. Meanwhile, when the server receives the same network request again, by the processing mode for the same network request (storing the processing result when the network request is received for the first time), error information representing repeated requests does not need to be returned to the client, and the fact that the client cannot display the subsequently received processing result due to error reporting (error reporting after the error information is received) is avoided.
Step 416, the server returns the processing result to the client.
In this embodiment, the server returns the processing result in response to the network request sent by the client in step 404.
In step 418, the server returns the processing result to the client.
In this embodiment, the server returns the processing result in response to the network request sent by the client in step 412.
In step 420, the client displays the received processing result.
For example, as shown in fig. 5, a client sends a first network request (request 1) to a server, and the server creates a key-value pair in a cache after receiving the request 1 and processes the request 1 according to the processing logic of the server. After the processing result for the request 1 is generated, the processing result is stored in the cache (i.e., "return 1" between the server processing logic and the cache in the figure), and the processing result is returned to the client (i.e., "return 1" between the cache and the client in the figure). And the client sends the same network request to the server again (i.e., "request 2" in the figure, which is the same network request as "request 1") because the client waits for the return timeout. After receiving the request 2, the server may find a corresponding processing result in the cache, and then the server does not enter the processing flow (i.e., the request 2 is not processed according to the server processing logic), but directly reads the processing result stored in the cache and returns the processing result to the client (i.e., "return 2" in the figure). It should be noted that, in one case, "return 1" arrives at the client before "return 2"; in another case, return 2 arrives at the client before return 1. Wherein, the sequence of the arrival of the two is determined according to the actual situation. For the client, the client may display only the received first processing result and discard other processing results except the first processing result. For example, assuming that "return 2" arrives at the client before "return 1", the client may display the processing result of "return 2" and discard the processing result of "return 1".
In the request processing scheme of the present specification, when the server does not receive the same network request for the first time, in addition to the above-described case where the processing result for the network request has been generated, there is a possibility that the server is processing the network request, that is, the processing result is not generated. Therefore, for the above situation, the server may return a notification message indicating that the network request is being processed to the client to inform the client to continue waiting for the processing result. This is explained below with reference to fig. 6-7.
Referring to fig. 6, fig. 6 is an interaction diagram of a return notification message provided by an exemplary embodiment. As shown in fig. 6, the method may include the steps of:
in step 602, the client generates a request identifier.
In this embodiment, a parameter for checking an anti-repeat request is agreed in a communication protocol between the client and the server, and before the client sends a network request, the client generates the parameter as a request identifier of the network request and adds the request identifier to the network request. For example, the client may upload a random string of fixed numbers and concatenate with the name of the current request to get a dpkey.
In step 604, the client sends a network request to the server.
Step 606, the server creates the key-value pair after receiving the network request.
In step 608, the server sets the key to the committed state.
In this embodiment, after receiving a network request from a client, a server performs a process of checking an anti-duplication request. Based on the network request including the dpkey, the server can locally inquire whether a key value pair corresponding to the dpkey is recorded. For example, the server may configure a preset cache for storing key-value pairs. And when the key value pair corresponding to the dpkey is found in the cache, the server side is explained to receive the network request for the first time, and then the key value pair taking the dpkey as the key is established in the cache. Further, the server enters a request processing flow (step 614), and processes the network request according to the server processing logic to generate a processing result for the network request. Wherein, since the processing flow is entered (i.e. the network request is being processed), the server can set the key value in the key value pair (i.e. the value corresponding to the dpkey) to the committed state. For example, a value of "1" indicates a committed state.
The server processes the network request, step 610.
In this embodiment, due to overload of the server or too many network requests to be processed, the server may not be able to process the network request in time to generate a processing result. When the processing result for the sent network request is not received within the preset time (i.e. waiting for the return timeout), the client sends the same network request to the server again. In other words, the server may receive the same network request that the client repeatedly sent while waiting for the return timeout in the process of processing the network request (i.e., while processing the network request).
In step 612, the client resends the network request.
In step 614, the server returns a notification message indicating that the client is processing to the client.
In this embodiment, as shown in step 608, the key value pair corresponding to the network request in the cache is "dpkey-1", that is, the processing result for the network request does not exist in the cache. Therefore, when the same network request is not received for the first time and a processing result for the network request is not generated, a notification message indicating that the network request is being processed may be returned to the client. Therefore, after receiving the notification message, the client does not need to report an error, thereby avoiding that the client cannot display the subsequently received processing result due to error reporting. For example, the client may continue to wait for processing results. Alternatively, when the same network request is not received for the first time and a processing result for the network request is not generated, the server may not respond to the network request, that is, directly ignore the network request that is not received for the first time.
Step 616, storing the processing result in the cache.
Step 618, the server returns the processing result to the client.
In step 620, the client displays the processing result.
For example, as shown in fig. 7, a client sends a first network request (request 1) to a server, and the server creates a key-value pair in a cache after receiving the request 1 and processes the request 1 according to the processing logic of the server. In the process of processing the request 1 (the processing result is not generated yet), the client sends the same network request to the server again due to the waiting-to-return timeout (i.e., "request 2" in the figure, which is the same network request as "request 1"). Since there is no processing result for the network request (i.e., request 2) in the cache of the server at this time, the server returns a notification message indicating that the network request is being processed to the client (i.e., "return 2" in fig. 7). After the server generates the processing result, the generated processing result is returned to the client, that is, return 1 in fig. 7. It should be noted that the order of the return 1 "and the return 2" to reach the client depends on the actual situation. When the client first receives return 2 (i.e. the client receives the notification message), it may not need to report an error and continue to wait for the processing result, i.e. continue to wait for return 1.
Fig. 8 is a schematic structural diagram of a device on the server side according to an exemplary embodiment. Referring to fig. 8, at the hardware level, the apparatus includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810, but may also include hardware required for other services. The processor 802 reads a corresponding computer program from the non-volatile memory 810 into the memory 808 and runs the computer program, thereby forming a request processing apparatus on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 9, in a software implementation, the request processing apparatus is applied to a server and may include:
a receiving unit 91, which receives a network request sent by a client;
a storage unit 92 that stores a processing result for the network request when the network request is received for the first time;
the result returning unit 93, when the network request is not received for the first time, reads the processing result for the network request, and returns the read processing result to the client.
Optionally, the method further includes:
a notification returning unit 94, configured to return a notification message indicating that the network request is being processed to the client when the network request is not received for the first time and the processing result is not generated.
Optionally, the network request includes a request identifier, when the network request is received for the first time, a key value using the request identifier as a key is set to a submitted state, and when the processing result is generated, the key value is set to the processing result; wherein the committed state is used to indicate that the processing result was not generated.
Optionally, the method further includes:
and the deleting unit 95 deletes the processing result when the storage duration of the processing result exceeds a preset effective duration.
Fig. 10 is a schematic structural diagram of a client-side based device according to an exemplary embodiment. Referring to fig. 10, at the hardware level, the apparatus includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 10010, and a non-volatile memory 1010, although other hardware required for services may be included. The processor 1002 reads a corresponding computer program from the non-volatile memory 1010 into the memory 10010 and runs the computer program, thereby forming a data request device on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 11, in a software implementation, the data request apparatus applied to the client may include:
a sending unit 1101 that sends a network request to a server; wherein the processing result for the network request is stored when the server receives the network request for the first time;
a resending unit 1102, configured to resend the network request when the processing result returned by the server is not received within a preset waiting duration, so that the server reads and returns the stored processing result;
a display unit 1103 configured to display the received first processing result and discard the processing results other than the first processing result.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
In a typical configuration, a computer 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 disk storage, quantum memory, graphene-based storage media 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.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.
Claims (10)
1. A request processing method is applied to a server; the method comprises the following steps:
receiving a network request sent by a client, wherein the network request comprises a request identifier;
when the network request is received for the first time, setting the key value in the key value pair with the request mark as the key to be in a submitted state; wherein, when a processing result for the network request is generated, the processing result is stored, and the key value is set as the processing result, the committed state is used for indicating that the processing result is not generated;
when the network request is not received for the first time, reading a processing result aiming at the network request, wherein the processing result comprises the following steps: reading a key value in the key value pair as a processing result; the network request is retransmitted by the client when the processing result is not received within a preset waiting time; and returning the read processing result to the client.
2. The method of claim 1, further comprising:
when the network request is not received for the first time and the processing result is not generated, a notification message for indicating that the network request is being processed is returned to the client.
3. The method of claim 1, further comprising:
and deleting the processing result when the storage duration of the processing result exceeds the preset effective duration.
4. A data request method is applied to a client; the method comprises the following steps:
sending a network request to a server, wherein the network request comprises a request identifier, and when the server receives the network request for the first time, a key value in a key value pair with the request identifier as a key is set to be in a submitted state; wherein a processing result for the network request is stored when the server receives the network request for the first time, the key value is set as the processing result, and the committed state is used for indicating that the processing result is not generated;
when the processing result returned by the server is not received within a preset waiting time, the network request is retransmitted, so that the server reads the key value in the key value pair as the processing result and returns the processing result;
and displaying the received first processing result, and discarding the other processing results except the first processing result.
5. A request processing device is applied to a server; the device comprises:
the receiving unit is used for receiving a network request sent by a client, wherein the network request comprises a request identifier;
the storage unit is used for setting a key value in a key value pair taking the request identifier as a key to be in a submitted state when the network request is received for the first time; wherein, when a processing result for the network request is generated, the processing result is stored, and the key value is set as the processing result, the committed state is used for indicating that the processing result is not generated;
a result returning unit, configured to read a processing result for the network request when the network request is not received for the first time, including: reading a key value in the key value pair as a processing result; the network request is retransmitted by the client when the processing result is not received within a preset waiting time; and returning the read processing result to the client.
6. The apparatus of claim 5, further comprising:
and the notification returning unit is used for returning a notification message for indicating that the network request is processed to the client when the network request is not received for the first time and the processing result is not generated.
7. The apparatus of claim 5, further comprising:
and the deleting unit deletes the processing result when the storage duration of the processing result exceeds the preset effective duration.
8. A data request device is applied to a client; the device comprises:
the sending unit is used for sending a network request to a server, wherein the network request comprises a request identifier, and when the server receives the network request for the first time, a key value in a key value pair with the request identifier as a key is set to be in a submitted state; wherein a processing result for the network request is stored when the server receives the network request for the first time, the key value is set as the processing result, and the committed state is used for indicating that the processing result is not generated;
a resending unit, which resends the network request when the processing result returned by the server is not received within a preset waiting time, so that the server reads the key value in the key value pair as a processing result and returns the processing result;
and the display unit displays the received first processing result and discards other processing results except the first processing result.
9. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of any one of claims 1-3 by executing the executable instructions.
10. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of claim 4 by executing the executable instructions.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811252275.9A CN109660589B (en) | 2018-10-25 | 2018-10-25 | Request processing method and device and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811252275.9A CN109660589B (en) | 2018-10-25 | 2018-10-25 | Request processing method and device and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109660589A CN109660589A (en) | 2019-04-19 |
| CN109660589B true CN109660589B (en) | 2021-05-04 |
Family
ID=66110072
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811252275.9A Active CN109660589B (en) | 2018-10-25 | 2018-10-25 | Request processing method and device and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109660589B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111190709B (en) * | 2019-11-19 | 2024-04-12 | 泰康保险集团股份有限公司 | Method and device for processing request, electronic equipment and readable storage medium |
| CN112055023B (en) * | 2020-09-09 | 2022-10-18 | 中国工商银行股份有限公司 | Access request processing method, device, equipment and medium based on prediction machine |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013192137A1 (en) * | 2012-06-22 | 2013-12-27 | Qualcomm Incorporated | Methods and apparatus for providing hybrid unicast broadcast services |
| CN106412899A (en) * | 2016-10-11 | 2017-02-15 | 江苏电力信息技术有限公司 | Network request method for saving flow of mobile terminal |
| CN106603598A (en) * | 2015-10-15 | 2017-04-26 | 阿里巴巴集团控股有限公司 | Method for processing service request and apparatus thereof |
| CN106713455A (en) * | 2016-12-22 | 2017-05-24 | 北京锐安科技有限公司 | System, method and device for processing client requests |
| CN106909690A (en) * | 2017-03-07 | 2017-06-30 | 四川驹马企业管理有限公司 | Network data caching method |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7490152B2 (en) * | 2003-04-11 | 2009-02-10 | Alcatel-Lucent Usa Inc. | Version caching mechanism |
| CN102710666B (en) * | 2012-06-28 | 2015-03-04 | 武汉虹信通信技术有限责任公司 | RADIUS (remote authentication dial in user service) client overtime treating method in WLAN (wireless local area network) system |
| CN106973074B (en) * | 2016-01-13 | 2019-11-19 | 腾讯科技（深圳）有限公司 | A kind of data processing method, apparatus and system |
| CN105847184A (en) * | 2016-02-22 | 2016-08-10 | 乐视移动智能信息技术（北京）有限公司 | Network request method, device and processing system for android operation system |
-
2018
- 2018-10-25 CN CN201811252275.9A patent/CN109660589B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013192137A1 (en) * | 2012-06-22 | 2013-12-27 | Qualcomm Incorporated | Methods and apparatus for providing hybrid unicast broadcast services |
| CN106603598A (en) * | 2015-10-15 | 2017-04-26 | 阿里巴巴集团控股有限公司 | Method for processing service request and apparatus thereof |
| CN106412899A (en) * | 2016-10-11 | 2017-02-15 | 江苏电力信息技术有限公司 | Network request method for saving flow of mobile terminal |
| CN106713455A (en) * | 2016-12-22 | 2017-05-24 | 北京锐安科技有限公司 | System, method and device for processing client requests |
| CN106909690A (en) * | 2017-03-07 | 2017-06-30 | 四川驹马企业管理有限公司 | Network data caching method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109660589A (en) | 2019-04-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10204114B2 (en) | Replicating data across data centers | |
| WO2016177285A1 (en) | Data pushing method and device | |
| CN115004673B (en) | Message pushing method, device, electronic equipment and computer readable medium | |
| CN106716335B (en) | Asynchronous processing of mapping information | |
| US20140006475A1 (en) | Method, apparatus, and computer program product for processing data requests | |
| JP2016517551A (en) | Method, computer system and computer program for performing integrity check and selective deduplication based on network parameters | |
| US10498681B1 (en) | Storage management for ephemeral messages | |
| EP3817333B1 (en) | Method and system for processing requests in a consortium blockchain | |
| US10523532B1 (en) | Multiple queueing for distributed environments | |
| WO2018149317A1 (en) | Method of performing smart hybrid acceleration on resources, device, medium, and apparatus | |
| US11978025B2 (en) | Method and device for processing virtual cards | |
| TWI716822B (en) | Method and device for correcting transaction causality, and electronic equipment | |
| EP3813001A1 (en) | Data reading method based on a plurality of block chain networks and system | |
| CN109660589B (en) | Request processing method and device and electronic equipment | |
| WO2017032152A1 (en) | Method for writing data into storage device and storage device | |
| CN113259479A (en) | Data processing method and equipment | |
| US8521902B2 (en) | Shared buffer for connectionless transfer protocols | |
| US10305640B2 (en) | Communication method of node in content centric network (CCN) and the node | |
| WO2018153236A1 (en) | Method and apparatus for accelerating dynamic resource access based on api request, medium, and device | |
| EP3886396B1 (en) | Methods for dynamically controlling transmission control protocol push functionality and devices thereof | |
| US7933962B1 (en) | Reducing reliance on a central data store while maintaining idempotency in a multi-client, multi-server environment | |
| CN112230880A (en) | Data transmission control method and device, FPGA (field programmable Gate array) and medium | |
| CN106899652B (en) | Method and device for pushing service processing result | |
| CN114338574A (en) | Instant messaging method, management node and system | |
| CN111046061A (en) | Data query method, device, system, equipment and storage medium |
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 | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20200925 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20200925 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Applicant before: Alibaba Group Holding Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |