Remote call fault-tolerant processing method, terminal device and storage medium

Abstract

This invention discloses a remote call fault tolerance processing method, terminal device, and storage medium. The method includes: opening a first time window when a client sends a business request to a server; opening a second time window when no callback request is received from the server within a first duration corresponding to the first time window, wherein the callback request is a request returned by the server after executing the asynchronous business logic processing indicated by the business request; and performing status and fault tolerance detection on the asynchronous business logic processing when a second duration corresponding to the second time window is reached, to obtain status information of the asynchronous business logic processing. This invention solves the technical problem in the prior art where remote calls cannot support fault tolerance processing for asynchronous calls.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a remote call fault-tolerant processing method, terminal device, and storage medium. Background Technology

[0002] Hypertext Transfer Protocol (HTTP) remote invocation is a relatively common communication technology. Other existing communication technologies also exist, such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). However, these technologies have certain limitations, such as focusing on how to send requests and receive responses, which restricts their application.

[0003] In practice, it has been found that remote procedure call (RPC) technology can only support some simple and specific exception handling, and cannot support fault tolerance for asynchronous calls. Summary of the Invention

[0004] This application provides a remote call fault tolerance processing method, which solves the technical problem that remote calls cannot support fault tolerance processing for asynchronous calls in the prior art.

[0005] Firstly, this application provides a remote call fault-tolerant processing method through an embodiment of the application, applied on the client side, the method comprising:

[0006] When a service request is detected from the client to the server, a first-time window is opened;

[0007] When it is detected that no callback request is received from the server within the first time period corresponding to the first time window, a second time window is opened. The callback request is the request returned by the server after it has completed the asynchronous business logic processing indicated by the business request.

[0008] When the second duration corresponding to the second time window is reached, the asynchronous business logic processing is subjected to status and fault tolerance detection to obtain the status information of the asynchronous business logic processing.

[0009] Optionally, before opening the second time window, the method further includes:

[0010] Send a heartbeat detection packet to the server to check whether the server is operating normally;

[0011] If so, continue with the steps to open the second time window;

[0012] If not, the pre-configured interval period is used to repeatedly execute the step of sending a heartbeat detection packet to the server to detect whether the server is running normally, until the number of repetitions reaches the pre-configured number of detections.

[0013] Optionally, the step of performing state and fault tolerance detection on the asynchronous business logic processing to obtain the state information of the asynchronous business logic processing includes:

[0014] When the client is running, it sends a status query message to the server.

[0015] Receive a first response message returned by the server based on the status query message, and obtain the status information of the asynchronous business logic processing based on the first response message;

[0016] The first response message carries the status information of the asynchronous business logic processing.

[0017] Optionally, the method further includes:

[0018] When a callback request is received from the server within the first duration corresponding to the first time window, the system responds to the callback request and performs corresponding business logic processing based on the obtained callback information.

[0019] Optionally, before performing the corresponding business logic processing based on the obtained callback information, the method further includes:

[0020] Determine whether to close the first time window;

[0021] If so, continue with the steps of performing corresponding business logic processing based on the obtained callback information;

[0022] If not, then close the first time window and continue with the step of performing corresponding business logic processing based on the obtained callback information.

[0023] Secondly, this application provides another remote call fault-tolerant processing method through one embodiment of the application, applied to the server side, the method comprising:

[0024] Receive business requests sent by the client;

[0025] After detecting that the business request has been successfully requested, respond to the business request and execute the asynchronous business logic processing indicated by the business request;

[0026] After executing the asynchronous business logic processing indicated by the business request, a corresponding callback request is returned to the client. The callback request is used to instruct the client to perform the corresponding business logic processing according to the pre-configured callback information.

[0027] Optionally, after returning the corresponding callback request to the client, the method further includes:

[0028] Determine whether the server successfully called back the client;

[0029] If not, record the status information of the failed client callback.

[0030] Optionally, the method further includes:

[0031] When it is detected that the service request was not successfully requested, a second response message is returned to the client, which carries status information indicating that the service request failed.

[0032] Thirdly, this application provides a remote call fault-tolerant processing device through one embodiment of the application. The device includes: an activation module and a processing module, wherein:

[0033] The enabling module is used to open a first time window when it detects that the client sends a service request to the server;

[0034] The enabling module is further configured to enable a second time window when it is detected that no callback request is received from the server within a first time period corresponding to the first time window, wherein the callback request is a request returned by the server after it has completed the asynchronous business logic processing indicated by the business request;

[0035] The processing module is used to perform status and fault tolerance detection on the asynchronous business logic processing when the second duration corresponding to the second time window is reached, and to obtain the status information of the asynchronous business logic processing.

[0036] For any content not introduced or described in the embodiments of this application, please refer to the relevant introduction in the method embodiments described in the first aspect above, which will not be repeated here.

[0037] Fourthly, this application provides another remote invocation fault-tolerant processing apparatus through one embodiment of the application, the apparatus comprising: a receiving module, a processing module, and a sending module, wherein:

[0038] The receiving module is used to receive service requests sent by the client;

[0039] The processing module is configured to respond to the business request and execute the asynchronous business logic processing indicated by the business request after detecting that the business request has been successfully requested.

[0040] The sending module is used to return a corresponding callback request to the client after executing the asynchronous business logic processing indicated by the business request. The callback request is used to instruct the client to perform the corresponding business logic processing according to the pre-configured callback information.

[0041] For any content not introduced or described in the embodiments of this application, please refer to the relevant descriptions in the method embodiments described in the second aspect above, which will not be repeated here.

[0042] Fifthly, this application provides a terminal device through an embodiment of the present application. The terminal device includes: a processor, a memory, a communication interface, and a bus; the processor, the memory, and the communication interface are connected through the bus and communicate with each other; the memory stores executable program code; the processor reads the executable program code stored in the memory to run a program corresponding to the executable program code, so as to execute the remote call fault-tolerant processing method described in the first or second aspect above.

[0043] On the other hand, this application provides a computer-readable storage medium through one embodiment of the application, the computer-readable storage medium storing a program that, when the program runs on a terminal device, executes the remote call fault-tolerant processing method as described in the first or second aspect above.

[0044] One or more technical solutions provided in this application embodiment have at least the following technical effects or advantages: When this application detects that a client sends a business request to the server, it opens a first time window; then, when it detects that no callback request is received from the server within a first duration corresponding to the first time window, it opens a second time window, wherein the callback request is a request returned by the server after executing the asynchronous business logic processing indicated by the business request; finally, when the second duration corresponding to the second time window is reached, the asynchronous business logic processing is subjected to status and fault tolerance detection to obtain the status information of the asynchronous business logic processing. In the above solution, this application uses time windows to handle fault tolerance processing in remote asynchronous calls to obtain the status information of asynchronous business logic processing, which not only realizes fault tolerance processing in remote asynchronous calls but also improves the convenience and efficiency of fault tolerance processing. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a flowchart illustrating a remote call fault-tolerant processing method provided in an embodiment of this application.

[0047] Figure 2 This is a flowchart illustrating another remote call fault-tolerant processing method provided in an embodiment of this application.

[0048] Figure 3 This is a schematic diagram of the structure of a remote call fault-tolerant processing device provided in an embodiment of this application.

[0049] Figure 4 This is a schematic diagram of another remote call fault-tolerant processing device provided in the embodiments of this application.

[0050] Figure 5 This is a schematic diagram of the structure of a client provided in an embodiment of this application.

[0051] Figure 6 This is a schematic diagram of another server structure provided in an embodiment of this application. Detailed Implementation

[0052] This application provides a remote call fault tolerance processing method, which solves the technical problem that remote calls cannot support fault tolerance processing for asynchronous calls in the prior art.

[0053] The technical solution of this application embodiment is to solve the above-mentioned technical problems. The overall idea is as follows: when it is detected that the client sends a business request to the server, a first time window is opened; when it is detected that no callback request is received from the server within a first time period corresponding to the first time window, a second time window is opened, wherein the callback request is the request returned by the server after executing the asynchronous business logic processing indicated by the business request; when the second time period corresponding to the second time window is reached, the status and fault tolerance detection of the asynchronous business logic processing is performed to obtain the status information of the asynchronous business logic processing.

[0054] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0055] First, it should be clarified that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0056] Please see Figure 1 This is a flowchart illustrating a remote invocation fault-tolerant processing method provided in an embodiment of this application. Figure 1The method shown is applied to a system including a client and a server, and the method includes the following implementation steps:

[0057] S101. The client sends a service request to the server and opens a first-time window. Correspondingly, the server receives the service request. The service request is used to request asynchronous business logic processing.

[0058] The business request described in this application is an asynchronous business request, used to request the server to perform asynchronous logic processing of corresponding business operations, such as asynchronously reading data. The first time window is a system-defined time window, and its corresponding window duration is the first duration.

[0059] S102, The server detects whether the service request was successfully requested.

[0060] After receiving the service request, the server can detect whether it has received a preset first verification code (e.g., 200). The first verification code is used to indicate that the service request was successful. When the server receives the first verification code, it can determine that the service request was successfully requested and continue to execute step S103; otherwise, it can determine that the service request was not successfully requested, end the process, or return a response message to the client. The response message may carry status information indicating that the service request failed.

[0061] S103. The server responds to the business request and executes the asynchronous business logic processing indicated by the business request.

[0062] S104. After completing the asynchronous business logic processing, the server returns a callback request to the client.

[0063] After detecting that the business request has been successfully requested, the server can respond to the business request, execute the asynchronous business logic processing indicated by the business request, and after processing, can call the client to return the corresponding callback request to the client.

[0064] S105. The client detects whether it has received the callback request within the first duration corresponding to the first time window.

[0065] The client described in this application can detect whether it has received the callback request within a first duration corresponding to the first time window. If it has received it, it can respond to the callback request; if it has not received it, it can continue to execute step S106.

[0066] S106. The client opens a second time window.

[0067] The second time window in this application is a system-defined time window, and its corresponding window duration can be a second duration. In practical applications, the window durations corresponding to the first time window and the second time window are specifically the first duration and the second duration, which can be the same or different, and this application does not impose any restrictions.

[0068] S107. When the second duration corresponding to the second time window is reached, the client performs status and fault tolerance detection on the asynchronous business logic processing to obtain the status information of the asynchronous business logic processing.

[0069] In one specific embodiment, when the system time reaches the second duration corresponding to the second time window, the client can detect whether it is in a running state. Specifically, the client can read the pre-stored status code in the register. If the status code indicates that the client is in a running state, then the client is determined to be in a running state; otherwise, if the status code indicates that the client is not in a running state, then the client is determined to be not in a running state and the process can be terminated.

[0070] In practical applications, the status code can be specifically represented by, for example, numbers, characters, or strings. This application involves multiple status codes (or status information); taking numbers as an example: When it is 1, it indicates that business data preprocessing is in progress. When it is 2, it indicates that business data preprocessing has failed. When it is 3, it indicates that the business is running. When it is 4, it indicates that the business has failed. When it is 5, it indicates that business data is being read from or written to the database. When it is 6, it indicates that business data reading from or writing to the database has failed. When it is 7, it indicates that business logic processing has been completed. When it is 8, it indicates that the business callback is unsuccessful.

[0071] Furthermore, upon determining that the client is in a running state, the client can send a status query message (also known as a status query request) to the server to query the current status information of the asynchronous business logic processing. Accordingly, the server receives and responds to the status query message, and returns a first response message to the client, which carries the status information of the asynchronous business logic processing, thereby obtaining the status information of the asynchronous business logic processing.

[0072] In practical applications, the first response message can be represented in the form of a response code, or the status information of the asynchronous business logic processing can be represented in the form of a status code. The response code or the status code can be referred to in the foregoing introduction to status codes, and will not be repeated here.

[0073] By implementing this application, when a client sends a business request to the server, a first time window is opened; then, when no callback request is received from the server within a first duration corresponding to the first time window, a second time window is opened, where the callback request is the request returned by the server after executing the asynchronous business logic processing indicated by the business request; finally, when the second duration corresponding to the second time window is reached, the status and fault tolerance of the asynchronous business logic processing are detected to obtain the status information of the asynchronous business logic processing. In the above scheme, this application uses time windows to handle fault tolerance processing in remote asynchronous calls to obtain the status information of asynchronous business logic processing, thus realizing fault tolerance processing in remote asynchronous calls and improving the convenience and efficiency of fault tolerance processing.

[0074] Please see also Figure 2 This is a flowchart illustrating another remote invocation fault-tolerant processing method provided in an embodiment of this application. Figure 2 The method shown includes the following implementation steps:

[0075] S201. The client sends a service request to the server. Accordingly, the server receives the service request.

[0076] S202, The client opens the first time window.

[0077] After sending a service request to the server, the client described in this application can open a first time window. For a description of the first time window, please refer to the relevant descriptions in the foregoing method embodiments; they will not be repeated here.

[0078] S203, The server determines whether the service request was successfully requested.

[0079] This application can determine whether the server has detected / received the first verification code. If it has, it can determine that the service request was successful and continue to step S205; otherwise, it can determine that the service request failed and continue to step S204. The first verification code can be custom-set by the system and can be represented by numbers, characters, etc. For example, when the server detects verification code 200, it can determine that the service request was successfully requested.

[0080] S204. The server returns a response message to the client, the response message indicating that the service request failed. Specifically, the response message carries status information indicating that the service request failed, and the status information may be represented in the form of a status code. For details on status codes, please refer to the aforementioned descriptions of verification codes or status codes; they will not be repeated here.

[0081] S205. The server responds to the business request and executes the asynchronous business logic processing indicated by the business request.

[0082] S206. The server calls back to the client, sending a callback request to the client. The client then receives the callback request.

[0083] The callback request described in this application is used to instruct the client to perform corresponding business logic processing based on the pre-configured callback information. After the client receives the callback request, it can continue to execute step S209.

[0084] S207. The server determines whether the callback to the client was successful.

[0085] The server described in this application can determine whether the callback was successful by detecting whether a second verification code has been received. Specifically, when the server detects the second verification code, it can determine that the callback was successful and end the process; otherwise, it determines that the callback was unsuccessful and continues to execute step S208.

[0086] S208. The server records status information used to indicate callback failure.

[0087] S209. The client determines whether to close the first time window.

[0088] When the client determines that the first time window has been closed, this application may continue to execute step S211; otherwise, when it determines that the client has not closed the first time window, it may continue to execute step S210.

[0089] S210, The client closes the first time window.

[0090] S211. In response to the callback request, the client performs corresponding business logic processing based on the obtained callback information.

[0091] After closing the first time window, this application can respond to the callback request, obtain callback information, and perform corresponding business logic processing based on the callback information. The callback information can be system-defined, and may include, but is not limited to, information such as whether the asynchronous business logic processing is complete (i.e., whether the asynchronous business logic has been processed) or whether the asynchronous logic processing has encountered an error (e.g., whether the input data or processing logic of the asynchronous logic processing has encountered an error).

[0092] S212. When the first duration corresponding to the first time window is reached, the client detects the state of the client.

[0093] S213. The client determines whether it is in a running state.

[0094] In an optional embodiment, after opening the first time window, the client described in this application can continue to execute step S212. When the first duration corresponding to the first time window is reached, the current state of the client can be detected. This state can be specifically represented in the form of a status code, as detailed in the foregoing introduction to status codes, which will not be repeated here. Furthermore, after detecting the current state of the client, this application can determine whether it is in a running state. If so, it continues to execute step S214; otherwise, the process ends.

[0095] Optionally, after step S213, this application may further detect whether the callback request has been received within the first duration corresponding to the first time window. If not received, step S214 is continued. Conversely, if the client receives the callback request, it can respond to the callback request and perform corresponding business logic processing based on the obtained callback information.

[0096] S214. The client sends a heartbeat detection packet to the server to detect whether the server is operating normally.

[0097] S215. The client determines whether the server is running normally.

[0098] The client described in this application can periodically send heartbeat detection packets to the server to detect whether the server is operating normally. If it is operating normally, proceed to step S217; otherwise, proceed to step S216.

[0099] S216. The client uses a pre-configured interval period to repeatedly execute steps S214-S215 until the number of repetitions reaches the pre-configured number of detections.

[0100] After detecting that the server is malfunctioning, the client described in this application can determine whether the current number of detections is greater than or equal to the pre-configured number of detections. If so, the process continues, and the status information indicating that the server is malfunctioning is recorded. Otherwise, the current number of detections is incremented by 1, and a heartbeat detection packet is resent to the client according to the pre-configured interval to check whether the server is malfunctioning.

[0101] S217. The client opens a second time window.

[0102] S218. When the second duration corresponding to the second time window is reached, the state of the client is detected. For a description of the second time window, please refer to the aforementioned description of the first time window; it will not be repeated here.

[0103] S219. The client determines whether it is in a running state.

[0104] If the client is running, this application may continue to execute step S220; otherwise, the process will end.

[0105] S220. Perform status and fault tolerance detection on the asynchronous business logic processing, and obtain and record the status information of the asynchronous business logic processing.

[0106] When the client in this application determines that it is in a running state, it can send a status query message to the server to query the corresponding status of the asynchronous business logic processing. Correspondingly, after receiving the status query message, the server can return a corresponding response message, which carries the status information of the asynchronous business logic processing. In practical applications, this response message can be represented in the form of a response code, such as response code 200, and this application can obtain the status information of the asynchronous business logic processing by parsing the response code 200.

[0107] As can be seen from the above, the embodiments of this application can achieve fault tolerance during HTTP asynchronous remote calls. When the client sends a business request to the server, the server processes the business logic asynchronously. The client checks its own status at a specified time by opening a time window. If the server crashes at this time, the client will record its status. After the server finishes processing the business logic asynchronously, it calls back to the client. If the client crashes, the server will record its status. If the callback is successful, the client will ultimately perform different processing based on the status and callback information, thus achieving the purpose of fault tolerance.

[0108] By implementing the embodiments of this application, when a client sends a business request to the server, a first time window is opened; then, when no callback request is received from the server within a first duration corresponding to the first time window, a second time window is opened, where the callback request is the request returned by the server after executing the asynchronous business logic processing indicated by the business request; finally, when the second duration corresponding to the second time window is reached, the status and fault tolerance detection of the asynchronous business logic processing is performed to obtain the status information of the asynchronous business logic processing. In the above scheme, this application uses time windows to handle fault tolerance processing in remote asynchronous calls to obtain the status information of asynchronous business logic processing, which not only realizes fault tolerance processing in remote asynchronous calls but also improves the convenience and efficiency of fault tolerance processing.

[0109] Based on the same inventive concept, another embodiment of this application provides an apparatus and terminal device for implementing the remote call fault-tolerant processing method described in the embodiments of this application.

[0110] Please see Figure 3This is a schematic diagram of the structure of a remote call fault-tolerant processing device (also known as a client) provided in an embodiment of this application. Figure 3 The device 30 shown includes an opening module 301 and a processing module 302, wherein:

[0111] The opening module 301 is used to open a first time window when it detects that the client sends a service request to the server;

[0112] The opening module 302 is further configured to open a second time window when it is detected that no callback request returned by the server is received within the first time period corresponding to the first time window, wherein the callback request is a request returned by the server after it has completed the asynchronous business logic processing indicated by the business request;

[0113] The processing module 302 is used to perform status and fault tolerance detection on the asynchronous business logic processing when the second duration corresponding to the second time window is reached, and to obtain the status information of the asynchronous business logic processing.

[0114] Optionally, before opening the second time window, the processing module 302 is further configured to:

[0115] Send a heartbeat detection packet to the server to check whether the server is operating normally;

[0116] If so, continue with the steps to open the second time window;

[0117] If not, the pre-configured interval period is used to repeatedly execute the step of sending a heartbeat detection packet to the server to detect whether the server is running normally, until the number of repetitions reaches the pre-configured number of detections.

[0118] Optionally, the processing module 302 is specifically used for:

[0119] When the client is running, it sends a status query message to the server.

[0120] Receive a first response message returned by the server based on the status query message, and obtain the status information of the asynchronous business logic processing based on the first response message;

[0121] The first response message carries the status information of the asynchronous business logic processing.

[0122] Optionally, the processing module 302 is further configured to:

[0123] When a callback request is received from the server within the first duration corresponding to the first time window, the system responds to the callback request and performs corresponding business logic processing based on the obtained callback information.

[0124] Optionally, before performing the corresponding business logic processing based on the obtained callback information, the processing module 302 is further configured to:

[0125] Determine whether to close the first time window;

[0126] If so, continue with the steps of performing corresponding business logic processing based on the obtained callback information;

[0127] If not, then close the first time window and continue with the step of performing corresponding business logic processing based on the obtained callback information.

[0128] Please see also Figure 4 This is a schematic diagram of the structure of a remote call fault-tolerant processing device (also known as a server) provided in an embodiment of this application. Figure 4 The device 40 shown includes: a receiving module 401, a processing module 402, and a transmitting module 403, wherein:

[0129] The receiving module 401 is used to receive service requests sent by the client;

[0130] The processing module 402 is configured to respond to the business request and execute the asynchronous business logic processing indicated by the business request after detecting that the business request has been successfully requested.

[0131] The sending module 403 is used to return a corresponding callback request to the client after executing the asynchronous business logic processing indicated by the business request. The callback request is used to instruct the client to perform the corresponding business logic processing according to the pre-configured callback information.

[0132] Optionally, after returning the corresponding callback request to the client, the processing module 402 is further configured to:

[0133] Determine whether the server successfully called back the client;

[0134] If not, record status information indicating that the client callback failed.

[0135] Optionally, the processing module 402 is further configured to:

[0136] When it is detected that the service request was not successfully requested, a second response message is returned to the client, which carries status information indicating that the service request failed.

[0137] By implementing the embodiments of this application, when a client sends a business request to the server, a first time window is opened; then, when no callback request is received from the server within a first duration corresponding to the first time window, a second time window is opened, where the callback request is the request returned by the server after executing the asynchronous business logic processing indicated by the business request; finally, when the second duration corresponding to the second time window is reached, the status and fault tolerance detection of the asynchronous business logic processing is performed to obtain the status information of the asynchronous business logic processing. In the above scheme, this application uses time windows to handle fault tolerance processing in remote asynchronous calls to obtain the status information of asynchronous business logic processing, which not only realizes fault tolerance processing in remote asynchronous calls but also improves the convenience and efficiency of fault tolerance processing.

[0138] Please see Figure 5 This is a schematic diagram of the structure of a terminal device (also known as a client) provided in an embodiment of this application. Figure 5 The client 50 shown includes at least one processor 501, a communication interface 502, a user interface 503, and a memory 504. The processor 501, communication interface 502, user interface 503, and memory 504 can be connected via a bus or other means. This embodiment of the invention takes a connection via a bus 505 as an example.

[0139] Processor 501 can be a general-purpose processor, such as a central processing unit (CPU).

[0140] The communication interface 502 can be a wired interface (e.g., an Ethernet interface) or a wireless interface (e.g., a cellular network interface or a wireless LAN interface) for communicating with other terminals or websites. In this embodiment of the invention, the communication interface 502 is specifically used to obtain service requests or callback requests, etc.

[0141] User interface 503 can specifically be a touch panel, including a touch screen and a touch screen display, used to detect operation commands on the touch panel. User interface 503 can also be a physical button or a mouse. User interface 503 can also be a display screen, used to output and display images or data.

[0142] Memory 504 may include volatile memory, such as random access memory (RAM); memory may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory 504 may also include combinations of the above types of memory. Memory 504 is used to store a set of program code, and processor 501 is used to call the program code stored in memory 504 to perform the following operations:

[0143] When a service request is detected from the client to the server, a first-time window is opened;

[0144] When it is detected that no callback request is received from the server within the first time period corresponding to the first time window, a second time window is opened. The callback request is the request returned by the server after it has completed the asynchronous business logic processing indicated by the business request.

[0145] When the second duration corresponding to the second time window is reached, the asynchronous business logic processing is subjected to status and fault tolerance detection to obtain the status information of the asynchronous business logic processing.

[0146] Optionally, before opening the second time window, the processor 501 is further configured to:

[0147] Send a heartbeat detection packet to the server to check whether the server is operating normally;

[0148] If so, continue with the steps to open the second time window;

[0149] If not, the pre-configured interval period is used to repeatedly execute the step of sending a heartbeat detection packet to the server to detect whether the server is running normally, until the number of repetitions reaches the pre-configured number of detections.

[0150] Optionally, the step of performing state and fault tolerance detection on the asynchronous business logic processing to obtain the state information of the asynchronous business logic processing includes:

[0151] When the client is running, it sends a status query message to the server.

[0152] Receive a first response message returned by the server based on the status query message, and obtain the status information of the asynchronous business logic processing based on the first response message;

[0153] The first response message carries the status information of the asynchronous business logic processing.

[0154] Optionally, the processor 501 is further configured to:

[0155] When a callback request is received from the server within the first duration corresponding to the first time window, the system responds to the callback request and performs corresponding business logic processing based on the obtained callback information.

[0156] Optionally, before performing the corresponding business logic processing based on the acquired callback information, the processor 501 is further configured to:

[0157] Determine whether to close the first time window;

[0158] If so, continue with the steps of performing corresponding business logic processing based on the obtained callback information;

[0159] If not, then close the first time window and continue with the step of performing corresponding business logic processing based on the obtained callback information.

[0160] Please see also Figure 6 This is a schematic diagram of the structure of another terminal device (also known as a server) provided in an embodiment of this application. Figure 6 The server 60 shown includes at least one processor 601, a communication interface 602, a user interface 603, and a memory 604. The processor 601, communication interface 602, user interface 603, and memory 604 can be connected via a bus or other means. This embodiment of the invention uses a connection via a bus 605 as an example. The descriptions of the processor 601, communication interface 602, user interface 603, memory 604, and bus 605 are consistent with the foregoing descriptions. Figure 5 The relevant details will not be repeated here. The memory 604 is used to store a set of program code, and the processor 601 is used to call the program code stored in the memory 604 to perform the following operations:

[0161] Receive business requests sent by the client;

[0162] After detecting that the business request has been successfully requested, respond to the business request and execute the asynchronous business logic processing indicated by the business request;

[0163] After executing the asynchronous business logic processing indicated by the business request, a corresponding callback request is returned to the client. The callback request is used to instruct the client to perform the corresponding business logic processing according to the pre-configured callback information.

[0164] Optionally, after returning the corresponding callback request to the client, the processor 601 is further configured to:

[0165] Determine whether the server successfully called back the client;

[0166] If not, record status information indicating that the client callback failed.

[0167] Optionally, the processor 601 is further configured to:

[0168] When it is detected that the service request was not successfully requested, a second response message is returned to the client, which carries status information indicating that the service request failed.

[0169] Since the terminal device described in this embodiment is the terminal device used to implement the remote call fault-tolerant processing method in this application embodiment, those skilled in the art can understand the specific implementation method and various variations of the terminal device in this embodiment based on the remote call fault-tolerant processing method described in this application embodiment. Therefore, how the terminal device implements the method in this application embodiment will not be described in detail here. Any terminal device used by those skilled in the art to implement the remote call fault-tolerant processing method in this application embodiment falls within the scope of protection of this application.

[0170] The technical solutions described in the embodiments of this application have at least the following technical effects or advantages:

[0171] This application opens a first time window when it detects that a client sends a business request to the server; then, if no callback request is received from the server within a first duration corresponding to the first time window, a second time window is opened. The callback request is the request returned by the server after executing the asynchronous business logic processing indicated by the business request. Finally, when the second duration corresponding to the second time window is reached, the asynchronous business logic processing undergoes status and fault tolerance detection to obtain its status information. In this scheme, this application uses time windows to handle fault tolerance in remote asynchronous calls to obtain the status information of the asynchronous business logic processing, thus achieving fault tolerance in remote asynchronous calls and improving the convenience and efficiency of fault tolerance processing.

[0172] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can 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, etc.) containing computer-usable program code.

[0173] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0174] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0175] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0176] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0177] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A remote call fault-tolerant processing method, characterized in that, Applied to the client side, the method includes: When the client sends a service request to the server, a first time window is opened; after the server receives the service request, it can detect whether a preset first verification code has been received, which is used to indicate that the service request was successful. When it is detected that no callback request is received from the server within the first time period corresponding to the first time window, a second time window is opened. The callback request is the request returned by the server after it has completed the asynchronous business logic processing indicated by the business request. When the second duration corresponding to the second time window is reached, the asynchronous business logic processing is subjected to status and fault tolerance detection to obtain the status information of the asynchronous business logic processing. Before opening the second time window, the method further includes: Send a heartbeat detection packet to the server to check whether the server is operating normally; If so, continue with the steps to open the second time window; If not, the pre-configured interval period is used to repeatedly execute the step of sending a heartbeat detection packet to the server to detect whether the server is running normally, until the number of repetitions reaches the pre-configured number of detections. The process of performing state and fault tolerance detection on the asynchronous business logic processing to obtain the state information of the asynchronous business logic processing includes: When the client is running, it sends a status query message to the server. Receive a first response message returned by the server based on the status query message, and obtain the status information of the asynchronous business logic processing based on the first response message; The first response message carries the status information of the asynchronous business logic processing; when a callback request returned by the server is received within the first duration corresponding to the first time window, the callback request is responded to, and the corresponding business logic processing is performed according to the obtained callback information; Before performing the corresponding business logic processing based on the obtained callback information, the method further includes: Determine whether to close the first time window; If so, continue with the steps of performing corresponding business logic processing based on the obtained callback information; If not, then close the first time window and continue with the step of performing corresponding business logic processing based on the obtained callback information.

2. A remote call fault-tolerant processing method, characterized in that, Applied to the server side, the method includes: The server receives a service request sent by the client. After receiving the service request, the server can detect whether a preset first verification code has been received. The first verification code is used to indicate that the service request was successful. After detecting that the business request has been successfully requested, respond to the business request and execute the asynchronous business logic processing indicated by the business request; After executing the asynchronous business logic processing indicated by the business request, a corresponding callback request is returned to the client. The callback request is used to instruct the client to perform the corresponding business logic processing according to the pre-configured callback information. The method further includes: Receive the pericardial detection data sent by the client to check whether the server is operating normally; If so, the client continues to execute the step of opening the second time window; If not, the pre-configured interval period is used to repeatedly execute the step of sending a heartbeat detection packet to the server to detect whether the server is running normally, until the number of repetitions reaches the pre-configured number of detections. The method further includes: When the client is running, receive status query messages sent by the client; Based on the status query message, a first response message is returned, and the client obtains the status information of the asynchronous business logic processing based on the first response message; The first response message carries the status information of the asynchronous business logic processing. When the client detects that it has received a callback request from the server within a first duration corresponding to the first time window, it responds to the callback request and performs corresponding business logic processing based on the obtained callback information; before performing corresponding business logic processing based on the obtained callback information, the method further includes: Determine whether to close the first time window; If so, continue with the steps of performing corresponding business logic processing based on the obtained callback information; If not, then close the first time window and continue with the step of performing corresponding business logic processing based on the obtained callback information.

3. The method according to claim 2, characterized in that, After returning the corresponding callback request to the client, the method further includes: Determine whether the server successfully called back the client; If not, record status information indicating that the client callback failed.

4. The method according to claim 3, characterized in that, The method further includes: When it is detected that the service request was not successfully requested, a second response message is returned to the client, which carries status information indicating that the service request failed.

5. A terminal device, characterized in that, The terminal device includes: a processor, a memory, a communication interface, and a bus; the processor, the memory, and the communication interface are connected through the bus and communicate with each other; the memory stores executable program code; the processor reads the executable program code stored in the memory to run a program corresponding to the executable program code, so as to execute the remote call fault-tolerant processing method as described in claim 1 above, or to execute the remote call fault-tolerant processing method as described in any one of claims 2-4 above.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when the program runs on a terminal device, executes the remote call fault-tolerant processing method as described in claim 1 above, or executes the remote call fault-tolerant processing method as described in any one of claims 2-4 above.

Images