Service remote calling method, system and equipment and storage medium
By receiving and saving the client's remote call retry request in the service remote call system, using the task queue to ensure the persistence of the retry task, the problem of remote call retry task is solved, and the reliability and stability of the service remote call is improved.
Patent Information
- Application Number
- CN202510133054.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-06
- Publication Date
- 2025-05-27
AI Technical Summary
In the service remote call scenario, the existing technology reduces the probability of remote call failure through the local retry mechanism, but in the case of service crashes, restarts, etc., there is still a risk of remote call retry tasks being lost, which is difficult to meet the needs of high-reliability business scenarios.
By receiving the client's remote call retry request, save it to the local database, and regularly save it to the task queue according to the task retry time of the retry task, ensuring the persistence of the retry task. In sequence, task instructions are issued to the client according to the retry task of the task queue, instructing the client to send a remote call retry request to the remote server, and update the local database according to the retry result.
It realizes the persistence and storage of retry tasks of service remote call, avoids the risk of retry tasks lost, improves the reliability and stability of service remote call, and meets the needs of high-reliability business scenarios.
Smart Images
Figure CN120045352A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application relate to the field of computer technologies, and in particular, to a method, a system, a device, and a storage medium for remote service invocation. Background Art
[0002] Currently, with the wide application of distributed systems, remote invocation between systems has become a key means of information transfer between different application services. In the scenario of remote service invocation, due to the expansion of service scale and the increase in the complexity of the network environment, factors such as network failures, hardware failures, and application service failures often lead to the failure of remote method invocations. For this reason, a local retry mechanism is usually required to reduce the failure probability of remote invocations. When a remote service invocation fails, the client will re-perform the remote service invocation after a set time interval to improve the availability of the remote service invocation through local retries.
[0003] However, in the case of service crashes, restarts, etc., simple local retries will still result in the failure of remote service invocations, easily leading to the risk of loss of remote invocation retry tasks, and it is difficult to meet the requirements of high-reliability business scenarios, resulting in low reliability and stability of remote service invocations. Summary of the Invention
[0004] The embodiments of the present application provide a method, a system, a device, and a storage medium for remote service invocation, which can persistently save remote invocation retry tasks, avoid the risk of loss of remote invocation retry tasks, and solve the technical problem of loss of remote invocation retry tasks caused by local retries of remote invocations.
[0005] In a first aspect, the embodiments of the present application provide a method for remote service invocation, including:
[0006] Receiving a retry task submitted by a client corresponding to a remote invocation retry request, saving the retry task to a local database, and regularly extracting the corresponding retry task from the local database based on the task retry time of the retry task and storing it in a first task queue locally. The first task queue is used to store retry tasks for performing remote invocation retries in a future set time period, and the retry tasks are stored in the order of the task retry time;
[0007] Sequentially issuing task instructions to the corresponding client according to the retry tasks in the first task queue, so as to instruct the corresponding client to send a remote invocation retry request to a remote server based on the task instructions;
[0008] Receiving the retry result of the retry task reported by the corresponding client based on the task instructions, and updating the local database based on the retry result.
[0009] In a second aspect, the embodiments of the present application provide a system for remote service invocation, including:
[0010] A receiving module, configured to receive a retry task submitted by a client corresponding to a remote call retry request, save the retry task to a local database, and regularly extract the corresponding retry task from the local database based on the task retry time of the retry task and store it in a first task queue locally. The first task queue is used to store retry tasks for performing remote call retries in a set future time period, and the retry tasks are stored in the order of the task retry time;
[0011] An instruction module, configured to sequentially issue task instructions to corresponding clients according to the retry tasks in the first task queue, so as to instruct the corresponding clients to send remote call retry requests to a remote server based on the task instructions;
[0012] An update module, configured to receive the retry result of the retry task reported by the corresponding client based on the task instruction, and update the local database based on the retry result.
[0013] In a third aspect, an embodiment of the present application provides a service remote call device, including:
[0014] A memory and one or more processors;
[0015] The memory is configured to store one or more programs;
[0016] When the one or more programs are executed by the one or more processors, the one or more processors implement the service remote call method as described in the first aspect.
[0017] In a fourth aspect, an embodiment of the present application provides a non-volatile computer-readable storage medium, which stores computer-executable instructions. The computer-executable instructions are configured to execute the service remote call method as described in the first aspect when executed by a computer processor.
[0018] In a fifth aspect, an embodiment of the present application provides a computer program product, which contains instructions. When the instructions run on a computer or a processor, the computer or the processor is caused to execute the service remote call method as described in the first aspect.
[0019] In the embodiment of the present application, by receiving a retry task submitted by a client corresponding to a remote call retry request, saving the retry task to a local database, and regularly extracting the corresponding retry task from the local database based on the task retry time of the retry task and storing it in a local first task queue. The first task queue is used to store retry tasks for performing remote call retries in a set future period, and the retry tasks are stored in the order of the task retry time. Sequentially issue task instructions to the corresponding client according to the retry tasks in the first task queue, so as to instruct the corresponding client to send a remote call retry request to the remote server based on the task instructions; receive the retry result of the retry task reported by the corresponding client based on the task instructions, and update the local database based on the retry result. By adopting the above technical means, by collecting retry tasks for remote service calls by the client and instructing the corresponding client to send a remote call retry request to the remote server based on the retry tasks, the persistent storage of remote call retry tasks can be realized, and the local database can be updated according to the retry results of the retry tasks, thereby avoiding the risk of loss of remote call retry tasks, improving the reliability and stability of remote service calls, meeting the requirements of high-reliability business scenarios, and enhancing the business service experience. Description of the Drawings
[0020] Figure 1 is a flowchart of a method for remote service call provided by an embodiment of the present application;
[0021] Figure 2 is an interaction flowchart of remote service call in an embodiment of the present application;
[0022] Figure 3 is a schematic diagram of retry failure handling for remote service call in an embodiment of the present application;
[0023] Figure 4 is a schematic structural diagram of a remote service call system provided by an embodiment of the present application;
[0024] Figure 5 is a schematic structural diagram of a remote service call device provided by an embodiment of the present application. Detailed Embodiments
[0025] To make the objectives, technical solutions and advantages of this application clearer, the following further describes specific embodiments of this application in conjunction with the accompanying drawings. It can be understood that the specific embodiments described herein are merely for explaining this application and not for limiting this application. Additionally, it should be noted that for ease of description, only parts related to this application rather than all content are shown in the drawings. Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the operations (or steps) as sequential processes, many of the operations can be implemented in parallel, concurrently, or simultaneously. In addition, the order of the operations can be rearranged. When the operations are completed, the process can be terminated, but there may also be additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.
[0026] The retry task for remote service calls provided by this application, based on the retry task, instructs the corresponding client to send a remote call retry request to the remote server, which can achieve the persistent storage of the remote service call retry task and update the local database according to the retry result of the retry task, thereby avoiding the risk of loss of the remote call retry task and enhancing the reliability and stability of the remote service call.
[0027] Remote Procedure Call (RPC) is a technology that allows a program to call a method located on a remote server in a distributed environment as if it were a local method. RPC hides the complexity of the underlying network communication, enabling programmers to focus on the business logic.
[0028] With the widespread application of distributed systems, remote calls between systems have become a key means of information transfer between different application services. However, with the expansion of service scale and the increase in the complexity of the network environment, factors such as network failures, hardware failures, and application service failures often lead to the failure of remote method calls. The related solutions for handling remote call devices are to reduce the failure probability through a local retry mechanism, but in cases such as service crashes and restarts, this solution is prone to request loss and cannot ensure the success of remote method calls.
[0029] In the local retry solution, when a remote method call times out or encounters a specific exception, a timed retry is usually performed locally on the client. The specific process is as follows:
[0030] 1. When a remote method call times out, the business thread is blocked, and at the same time, the client initiates a timed retry call locally.
[0031] 2. If the operation still fails within the set number of retry attempts or time range, the retry will be terminated, a failure result will be returned, and the business thread will continue to execute subsequent operations.
[0032] 3. If the retry is successful within the set number of retry attempts, a success result will be returned, and the business thread will continue with subsequent operations.
[0033] 4. If the client service restarts or crashes during the retry process, the retry process will be interrupted with the stop of the client process, resulting in the loss of the request.
[0034] In this way, it is impossible to ensure the successful processing of requests in the case of client process exceptions. For business scenarios with high reliability requirements, a simple local retry scheme is difficult to meet the requirements. To achieve fully highly reliable remote method calls through a local retry scheme, additional business configurations usually need to be made in the business logic code for each scenario, which will increase the complexity of code development.
[0035] Based on this, a service remote call method according to an embodiment of the present application is provided to solve the technical problem of the loss of remote call retry tasks caused by local retries in remote calls. For business scenarios with high reliability requirements for remote method calls, it can ensure that remote method calls will not be lost even in the case of service failures, thereby improving the reliability and stability of service remote calls.
[0036] Embodiment:
[0037] Figure 1 The flowchart of a service remote call method provided by an embodiment of the present application is given. The service remote call method provided in this embodiment can be executed by a service remote call device. The service remote call device can be implemented in software and / or hardware. The service remote call device can be composed of two or more physical entities or one physical entity. Generally, the service remote call device can be a processing device such as a server host.
[0038] The following takes the service remote call device as the main body for executing the service remote call method as an example for description. Refer to Figure 1 , the service remote call method specifically includes:
[0039] S110. Receive the retry task submitted by the client corresponding to the remote call retry request, save the retry task to the local database, and regularly extract the corresponding retry task from the local database based on the task retry time of the retry task and store it in the local first task queue. The first task queue is used to store retry tasks for executing remote call retries in a future set period, and the retry tasks are stored in the order of task retry time.
[0040] This application persists retry tasks for remote call retries on a remote storage client to ensure that retry tasks are not lost due to client crashes. Even if the system fails, these tasks can continue to be processed after recovery. Ensure that each retry task is recorded and not omitted, thereby enhancing the reliability and stability of service remote calls.
[0041] Specifically, as Figure 2 shown, an interaction flowchart for service remote calls of this application is provided, where a retry coordination server is introduced as the service remote call device for executing the service remote call method of this application. The retry coordination server persistently stores relevant information of remote procedure calls (RPCs), and then the client initiates a call to ensure that remote procedure calls are not lost. The retry coordination server provides a unified interface in the form of a component, and the business logic only needs to call the local interface method to achieve a highly reliable remote call function with the help of the retry coordination server. The retry coordination server is used to receive retry tasks submitted by the client for corresponding remote call retries and initiate retries for the retry tasks. All retry tasks are resubmitted to the original client for retry processing.
[0042] The client is responsible for submitting retry tasks to the retry coordination server and accepting instructions from the retry coordination server for task retries when needed.
[0043] When the client needs to make a service remote call, it will generate a remote call request based on the relevant information of the remote procedure call (RPC), and then send the remote call request to the remote server. At this time, the client can generate a retry task based on the relevant information of the remote procedure call (RPC). This retry task is used to trigger a service remote call retry when the service remote call fails and resend the remote call retry request to the remote client. The retry task will be uploaded to the retry coordination server and saved in the local database of the retry coordination server. Optionally, the client can also submit the retry task to the retry coordination server when it determines that the remote call request has failed and is performing a remote call retry. The retry coordination server uniformly coordinates the timing of the service remote call retry by the client.
[0044] Before the client performs a remote call retry (either for the first remote call or after the first remote call), it will construct a retry task based on the subsequent remote call retry request and report the retry task to the retry coordination server. The retry task can record the corresponding task retry time and retry count to facilitate the scheduling of retry tasks. After receiving the retry task, the retry coordination server persistently stores the retry task in the local database. Persistent storage ensures that even if the retry coordination server or the corresponding client fails or restarts, the retry task will not be lost.
[0045] The retry coordination server maintains a retry task timer. The retry task timer periodically extracts retry tasks from the database and places these retry tasks into a task queue, which is defined as the first task queue. The retry task timer extracts the tasks that are about to be retried from the local database at regular time intervals (such as every n seconds, every minute, etc.). When extracting, it filters according to the retry time of the tasks to ensure that only those tasks that need to be retried within a set future period are extracted. The extracted retry tasks are stored in a local task queue, that is, the first task queue. The first task queue is sorted according to the retry time of the retry tasks to ensure that the tasks that need to be retried earliest are at the front of the queue.
[0046] Optionally, before periodically extracting the corresponding retry tasks from the local database based on the task retry time of the retry tasks and storing them in the local first task queue, it further includes:
[0047] Configuring the task retry time of the retry tasks according to the set retry time interval, and the retry time interval is set based on the Fibonacci sequence, exponential sequence, or fixed time interval.
[0048] This application pre-configures the corresponding retry backoff strategy, and controls the time interval of the retry tasks to avoid the risk of overloading the server-side service pressure caused by initiating a large number of retries in a short time. Before saving the retry tasks to the local database and periodically extracting tasks from the database to the first task queue, it is necessary to configure the task retry time of each retry task.
[0049] Among them, the retry time interval is set based on the Fibonacci sequence, exponential sequence, or fixed time interval, so as to configure the task retry time according to the retry time interval. The Fibonacci sequence is a sequence in which each number is the sum of the previous two numbers (such as 1, 1, 2, 3, 5, 8, 13,...). In the retry strategy, the values of the Fibonacci sequence can be used as the retry time interval (which can be seconds, milliseconds, or other time units). This strategy will gradually increase the subsequent retry intervals after the first retry fails, so as to reduce the frequent requests to the remote service and give the service time to recover. The exponential sequence is a sequence in which each number is a fixed multiple (such as 2 times) of the previous number (1, 2, 4, 8, 16,...). In the retry strategy, the values of the exponential sequence can also be used as the retry time interval. This strategy makes the retry time increase faster and is suitable for scenarios with a higher tolerance for the response of the remote service. The fixed time interval means that the same time interval is used for each retry. This strategy is simple and easy to implement and is suitable for scenarios with a fixed expectation for the response of the remote service. Optionally, the different retry time interval setting methods of this application are shown in Table 1 below:
[0050] Table 1: Different retry time interval setting methods
[0051]
[0052]
[0053] Optionally, when the client submits a retry task, or when the retry coordination server receives a retry task and is ready to save the task to the database, a suitable retry time interval configuration strategy is selected according to the business requirements and system load conditions. Then, according to the selected strategy, the task retry time for each retry task is calculated or determined, and it is saved as part of the task information in the local database. When the scheduled task is triggered, the retry coordination server extracts the corresponding retry task from the database according to the task retry time and stores it in the first task queue in chronological order.
[0054] By providing multiple retry time interval configuration strategies, it can be flexibly selected according to actual needs. Thereby reducing the frequent requests to the remote service, which helps to balance the system load. Unnecessary waiting and repeated requests are avoided, and the resource utilization efficiency is improved.
[0055] Optionally, before saving the retry task to the local database, it further includes:
[0056] Determine multiple retry tasks belonging to the same call chain, retain the retry task belonging to the highest level in the call chain, and screen out other retry tasks.
[0057] By maintaining a retry policy controller to screen multiple retry tasks belonging to the same call chain. As Figure 3 shown, assume there is a call chain A - B - C - DB (database), and each service has access to the automatic retry function. When the bottom - layer query of the DB (database) times out or fails, it will cause each call level to spontaneously retry the upstream requests. The final result will be that a normal request that is originally 1 time will result in an exponentially increasing request volume when reaching the bottom - layer service. That is, each layer will trigger corresponding retry tasks. Therefore, it is necessary to retain the retry task belonging to the highest level in the call chain and screen out other retry tasks, reducing the computational workload of the retry coordination server and also reducing the volume of retry requests received by the remote service side.
[0058] Optionally, determining multiple retry tasks belonging to the same call chain includes:
[0059] Read the identification bit preset in the context information of the retry task, and determine multiple retry tasks belonging to the same call chain based on the identification bit.
[0060] By introducing a tagging mechanism in the call chain, nested retry chains are automatically identified and tagged. Before initiating an RPC call, the client sets an identification bit in the RPC context to construct the corresponding retry task. After the retry task is submitted to the retry coordination server, the retry coordination server identifies the RPC context and reads the identification. If the retry identification is detected, it is determined that there is an existing retry request upstream, and when encountering new retry logic, only one retry task is executed. The highest-level retry task is retained, and the lower-level retry tasks are invalidated, thus effectively avoiding the burden on the system caused by exponentially increasing retry requests and maintaining system stability and resource efficiency.
[0061] Optionally, at regular intervals, the corresponding retry tasks are extracted from the local database based on the task retry time of the retry tasks and stored in the local first task queue, including:
[0062] At regular intervals according to the time interval of the future set period, query the local database based on the task retry time of the retry tasks, determine the retry tasks for remote call retries to be executed in the future set period from the local database, extract the queried retry tasks and store them in the local first task queue in the order of task retry time.
[0063] Exemplarily, to avoid the pressure on the database caused by the retry task timer frequently accessing the database to extract tasks, the retry task timer only needs to batch extract the tasks to be retried within the next 5 seconds every 5 seconds and store them in the first task queue. Subsequently, the first task queue will be responsible for task retries. The first task queue traverses based on the order of the in-memory array, with high execution efficiency, thus ensuring that the retry tasks are triggered on time, reducing the overall system load, and improving the system's concurrent service ability. In this way, through optimizations in aspects such as data persistence, ordered task execution, and system fault tolerance, the reliability and stability of remote calls are improved.
[0064] S120. Sequentially issue task instructions to the corresponding clients according to the retry tasks in the first task queue, so as to instruct the corresponding clients to send remote call retry requests to the remote server based on the task instructions.
[0065] Furthermore, as Figure 2 shown, based on the above storage of the retry tasks in the first task queue, the retry coordination server sequentially extracts the retry tasks from the first task queue and issues task instructions to the corresponding clients. These task instructions instruct the clients to send remote call retry requests to the remote server.
[0066] Specifically, when the retry coordination server detects a new task in the first task queue, it retrieves the task for parsing. The task information such as task ID, task type, target client identifier, retry count, remote server address, etc. is parsed. According to the parsed task information, corresponding task instructions are generated. The task instructions are sent to the corresponding client through an internal communication mechanism (such as message queue, RPC, etc.).
[0067] The client listens for messages from the retry coordination server. When receiving the task instructions, it parses the instruction content. According to the instruction content, it prepares the parameters and data required for the remote call, and then sends a remote call retry request to the remote server.
[0068] Optionally, task instructions are sequentially sent to the corresponding clients according to the retry tasks in the first task queue, including:
[0069] In the case where the client that submitted the retry task is in a set normal state, task instructions are sequentially sent to the client that submitted the retry task according to the retry tasks in the first task queue;
[0070] In the case where the client that submitted the retry task is in a set abnormal state, the alternative client of the client that submitted the retry task is determined, and task instructions are sent to the corresponding alternative client.
[0071] By maintaining a retry client router, the selection of the client for executing the retry task is realized. Among them, in a distributed service cluster, clients are often deployed in a multi-process manner. When the retry coordination server initiates a retry task, in order to maximize business friendliness, the retry tasks of the same RPC call are preferably performed on the same client. At the same time, in order to ensure high service reliability, it is also necessary to ensure that when the source client process crashes, other client processes in the cluster can still be selected for retry. Therefore, the retry client router, in the case where the client that submitted the retry task is in a set normal state, preferentially selects the source client (i.e., the client that originally submitted the retry task) to send task instructions for retry. In addition, in the case where the client that submitted the retry task is in a set abnormal state, such as when the client crashes, task instructions are sent to the corresponding alternative client for retry. The alternative client can be a client process in the same computer room as the source client or a client process in the same availability zone. The client process in the same computer room can be selected as a sub-optimal choice, and finally the client process in the same availability zone can be selected for retry.
[0072] By considering the client status and selecting a suitable client to execute the task instructions, the success rate of the retry task can be improved. At the same time, sending task instructions to clients in an abnormal state is avoided, thus reducing resource waste. Allowing flexible adjustment of the task allocation strategy when the client status changes improves the adaptability and robustness of the system.
[0073] S130. Receive the retry result of the retry task reported by the corresponding client based on the task instruction, and update the local database based on the retry result.
[0074] After receiving the task instruction, the client will send a remote call retry request to the remote server and receive the response from the remote server as the retry result. Further, the client will report the retry result to the retry coordination server, and the retry coordination server will update the corresponding record in the local database according to the retry result. Among them, if the retry result indicates that the service remote call is successful, the retry task in the local database needs to be deleted. If the retry result indicates that the service remote call fails, the next task retry time of the retry task in the local database needs to be updated.
[0075] By reporting the retry result by the client, the retry coordination server can understand the execution status of the retry task in real time, which is convenient for subsequent processing. At the same time, by updating the records in the local database, the consistency and integrity of the data can be ensured.
[0076] Optionally, receiving the retry task submitted by the client corresponding to the remote call retry request includes:
[0077] Receiving the retry task of the corresponding remote call retry request submitted by the client in sequence based on the second task queue, and the second task queue is used to store the retry tasks submitted by the client that failed in sequence.
[0078] For the client side, a task queue is also maintained, defined as the second task queue. The second task queue is enabled when an exception occurs in the retry coordination server to handle the situation where the local retry task fails to be submitted to the retry coordination server, and a degraded local retry mechanism is implemented. Each time a retry task is submitted, the client will first try to directly submit the retry task to the retry coordination server. Once successfully submitted, subsequent retries will be controlled by the retry coordination server. If the retry task fails to be submitted to the retry coordination server, the retry task needs to be stored in the second task queue, and then the retry task of the corresponding remote call retry request submitted in sequence based on the second task queue will be submitted to the retry coordination server for storage at regular intervals, so as to ensure the fault tolerance of the retry task processing.
[0079] Similarly, a corresponding retry policy controller can also be set on the client side to screen and upload multiple retry tasks on the same call link. Therefore, the client can also judge whether the current retry task to be submitted is the highest level of the call link. If not, it will be directly screened out and not uploaded, so as to reduce the data processing pressure on the remote server.
[0080] As described above, by receiving the retry tasks submitted by the client corresponding to the remote call retry requests, saving the retry tasks to the local database, and regularly extracting the corresponding retry tasks from the local database based on the task retry time of the retry tasks and storing them in the local first task queue, where the first task queue is used to store the retry tasks for performing remote call retries in a set future period, and the retry tasks are stored in the order of the task retry time; sequentially issuing task instructions to the corresponding clients according to the retry tasks in the first task queue, so as to instruct the corresponding clients to send remote call retry requests to the remote server based on the task instructions; receiving the retry results of the retry tasks reported by the corresponding clients based on the task instructions, and updating the local database based on the retry results. By adopting the above technical means, by collecting the retry tasks for the client to perform remote service calls and instructing the corresponding clients to send remote call retry requests to the remote server based on the retry tasks, the persistent storage of the remote call retry tasks can be realized, and the local database can be updated according to the retry results of the retry tasks, thereby avoiding the risk of loss of remote call retry tasks, improving the reliability and stability of remote service calls, meeting the requirements of high-reliability business scenarios, and enhancing the business service experience.
[0081] Based on the above embodiments, Figure 4 This is a schematic structural diagram of a service remote call system provided by this application. Refer to Figure 4 , the service remote call system provided in this embodiment specifically includes: a receiving module 21, an instructing module 22, and an updating module 23.
[0082] Among them, the receiving module 21 is configured to receive the retry tasks submitted by the client corresponding to the remote call retry requests, save the retry tasks to the local database, and regularly extract the corresponding retry tasks from the local database based on the task retry time of the retry tasks and store them in the local first task queue, where the first task queue is used to store the retry tasks for performing remote call retries in a set future period, and the retry tasks are stored in the order of the task retry time;
[0083] The instructing module 22 is configured to sequentially issue task instructions to the corresponding clients according to the retry tasks in the first task queue, so as to instruct the corresponding clients to send remote call retry requests to the remote server based on the task instructions;
[0084] The updating module 23 is configured to receive the retry results of the retry tasks reported by the corresponding clients based on the task instructions, and update the local database based on the retry results.
[0085] Specifically, before saving the retry tasks to the local database, it further includes:
[0086] Determine multiple retry tasks belonging to the same call link, retain the retry task belonging to the highest level in the call link, and filter out the other retry tasks.
[0087] Determine multiple retry tasks belonging to the same call chain, including:
[0088] Read the identification bit preset in the context information of the retry task, and determine multiple retry tasks belonging to the same call chain based on the identification bit.
[0089] Before periodically extracting the corresponding retry tasks from the local database based on the task retry time of the retry tasks and storing them in the local first task queue, it also includes:
[0090] Configure the task retry time of the retry task according to the set retry time interval, and the retry time interval is set based on the Fibonacci sequence, exponential sequence or fixed time interval.
[0091] Specifically, periodically extract the corresponding retry tasks from the local database based on the task retry time of the retry tasks and store them in the local first task queue, including:
[0092] Periodically query the local database based on the task retry time of the retry task at the time interval of the future set period, determine the retry tasks for remote call retry in the future set period from the local database, extract the queried retry tasks and store them in the local first task queue in the order of task retry time.
[0093] Specifically, sequentially issue task instructions to the corresponding client according to the retry tasks in the first task queue, including:
[0094] When the client submitting the retry task is in the set normal state, sequentially issue task instructions to the client submitting the retry task according to the retry tasks in the first task queue;
[0095] When the client submitting the retry task is in the set abnormal state, determine the alternative client of the client submitting the retry task and issue task instructions to the corresponding alternative client.
[0096] Specifically, receive the retry task submitted by the client corresponding to the remote call retry request, including:
[0097] Receive the retry tasks corresponding to the remote call retry requests sequentially submitted by the client based on the second task queue, and the second task queue is used to sequentially store the retry tasks that the client submits and fails.
[0098] As described above, by receiving the retry tasks submitted by the client corresponding to the remote call retry requests, saving the retry tasks to the local database, and regularly extracting the corresponding retry tasks from the local database based on the task retry time of the retry tasks and storing them in the first task queue of the local area, the first task queue is used to store the retry tasks for performing remote call retries in a set future time period, and the retry tasks are stored in the order of the task retry time; sequentially sending task instructions to the corresponding clients according to the retry tasks in the first task queue, so as to instruct the corresponding clients to send remote call retry requests to the remote server based on the task instructions; receiving the retry results of the retry tasks reported by the corresponding clients based on the task instructions, and updating the local database based on the retry results. By adopting the above technical means, by collecting the retry tasks for the service remote calls of the client and instructing the corresponding client to send a remote call retry request to the remote server based on the retry tasks, the persistent storage of the service remote call retry tasks can be realized, and the local database can be updated according to the retry results of the retry tasks, thereby avoiding the risk of loss of remote call retry tasks, improving the reliability and stability of the service remote call, meeting the requirements of high-reliability business scenarios, and enhancing the business service experience.
[0099] The service remote call system provided by the embodiments of the present application can be configured to execute the service remote call method provided by the above embodiments, and has the corresponding functions and beneficial effects.
[0100] On the basis of the above actual example, the embodiments of the present application further provide a service remote call device. Referring to Figure 5 , the service remote call device includes: a processor 31, a memory 32, a communication module 33, an input device 34, and an output device 35. The memory, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the service remote call method described in any embodiment of the present application (for example, the receiving module, the instructing module, and the updating module in the service remote call system). The communication module is configured to perform data transmission. The processor runs the software programs, instructions, and modules stored in the memory, thereby executing various functional applications and data processing of the device, that is, implementing the above service remote call method. The input device can be configured to receive input digital or character information, and generate key signal inputs related to the user settings and function controls of the device. The output device may include a display device such as a display screen. The above-provided service remote call device can be configured to execute the service remote call method provided by the above embodiments, and has the corresponding functions and beneficial effects.
[0101] Based on the above embodiments, an embodiment of the present application further provides a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are configured to execute a service remote call method when executed by a computer processor. The storage medium can be any various types of memory devices or storage devices. Of course, for the non-volatile computer-readable storage medium provided by an embodiment of the present application, its computer-executable instructions are not limited to the service remote call method as described above, and can also execute related operations in the service remote call method provided by any embodiment of the present application.
[0102] Based on the above embodiments, an embodiment of the present application further provides a computer program product. Essentially, or the part that contributes to the prior art, or all or part of the technical solution of the present application can be embodied in the form of a software product. The computer program product is stored in a storage medium and includes several instructions for causing a computer device, a mobile terminal, or a processor therein to execute all or part of the steps of the service remote call method described in various embodiments of the present application.
Claims
1. A service remote calling method, characterized in that: include: Receive a retry task submitted by a client corresponding to a remote call retry request, save the retry task to a local database, extract the corresponding retry task from the local database based on the task retry time of the retry task and store it in a local first task queue, the first task queue is used to store the retry task for executing the remote call retry in a future set period, and the retry tasks are stored in the order of the task retry time; issuing task instructions to the corresponding client in sequence according to the retry tasks of the first task queue, so as to instruct the corresponding client to send a remote call retry request to a remote server based on the task instructions; Receive a retry result of the retry task reported by the corresponding client based on the task instruction, and update the local database based on the retry result.
2. The service remote calling method according to claim 1, characterized in that: The timing extracts the corresponding retry task from the local database based on the task retry time of the retry task and stores it in the local first task queue, including: The local database is queried based on the task retry time of the retry task at a time interval of the future set time period, the retry task for executing the remote call retry in the future set time period is determined from the local database, the queried retry tasks are extracted and stored in the local first task queue in the order of the task retry time.
3. The service remote calling method according to claim 1, characterized in that: The sending of task instructions to the corresponding clients according to the retry tasks in the first task queue in sequence includes: When the client that submitted the retry task is in a set normal state, issuing task instructions to the client that submitted the retry task in sequence according to the retry tasks in the first task queue; When the client that submitted the retry task is in a set abnormal state, an alternative client of the client that submitted the retry task is determined, and a task instruction is issued to the corresponding alternative client.
4. The service remote calling method according to claim 1, characterized in that: Before the timing extracts the corresponding retry task from the local database based on the task retry time of the retry task and stores it in the local first task queue, the method further includes: The task retry time of the retry task is configured according to a set retry time interval, and the retry time interval is set based on a Fibonacci sequence, an exponential sequence or a fixed time interval.
5. The service remote calling method according to any one of claims 1 to 4, characterized in that: Before saving the retry task to the local database, the method further includes: Determine a plurality of the retry tasks that belong to the same call link, retain the retry tasks that belong to the highest level in the call link, and filter out the other retry tasks.
6. The service remote calling method according to claim 5, characterized in that: The determining of the multiple retry tasks belonging to the same call link includes: The preset identification bit of the context information of the retry task is read, and the multiple retry tasks belonging to the same call link are determined based on the identification bit.
7. The service remote calling method according to any one of claims 1 to 4, characterized in that: The receiving the retry task submitted by the client in response to the remote call retry request includes: Retry tasks corresponding to the remote call retry request submitted in sequence by the client based on a second task queue are received, and the second task queue is used to sequentially store the retry tasks that failed to be submitted by the client.
8. A service remote calling system, characterized in that: include: A receiving module is configured to receive a retry task submitted by a client corresponding to a remote call retry request, save the retry task to a local database, extract the corresponding retry task from the local database based on the task retry time of the retry task and store it in a local first task queue, wherein the first task queue is used to store the retry task for executing the remote call retry in a future set period, and the retry tasks are stored in the order of the task retry time; an instruction module, configured to issue task instructions to the corresponding client in sequence according to the retry tasks in the first task queue, so as to instruct the corresponding client to send a remote call retry request to a remote server based on the task instructions; The updating module is configured to receive the retry result of the retry task reported by the corresponding client based on the task instruction, and update the local database based on the retry result.
9. A service remote calling device, characterized in that: include: memory and one or more processors; The memory is configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the service remote calling method as described in any one of claims 1-7.
10. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a computer processor, they are configured to execute the service remote calling method according to any one of claims 1 to 7.
11. A computer program product, characterized in that The computer program product includes instructions, and when the instructions are executed on a computer or a processor, the computer or the processor executes the service remote calling method according to any one of claims 1 to 7.