CN111258776A - Disaster recovery method and device for remote service calling - Google Patents
Disaster recovery method and device for remote service calling Download PDFInfo
- Publication number
- CN111258776A CN111258776A CN202010019828.7A CN202010019828A CN111258776A CN 111258776 A CN111258776 A CN 111258776A CN 202010019828 A CN202010019828 A CN 202010019828A CN 111258776 A CN111258776 A CN 111258776A
- Authority
- CN
- China
- Prior art keywords
- request
- retry
- calling
- call
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 85
- 238000011084 recovery Methods 0.000 title claims abstract description 31
- 238000004806 packaging method and process Methods 0.000 claims abstract description 20
- 230000000977 initiatory effect Effects 0.000 claims description 31
- 230000003139 buffering effect Effects 0.000 claims description 20
- 230000004044 response Effects 0.000 claims description 18
- 238000005538 encapsulation Methods 0.000 claims description 13
- 238000010586 diagram Methods 0.000 description 8
- 238000012545 processing Methods 0.000 description 6
- 238000004891 communication Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 238000012856 packing Methods 0.000 description 2
- 230000007547 defect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Telephonic Communication Services (AREA)
Abstract
The application discloses a disaster recovery method and equipment for remote service calling, which are characterized in that a remote calling connection between a client and a server is established, and when the remote calling needs to be initiated to the server, a calling request is initiated to the server; if the calling is failed, when the current retry times in the message corresponding to the calling request are smaller than the preset maximum retry times, packaging the calling request into an updated message, and adding 1 to the current retry times; and sending the updated message to an external request delay queue for caching until a preset retry condition is met, and then forwarding to the server to initiate a retry call request, so that the call requests corresponding to call failures are cached, the cache of the call requests when a large number of request failures occur at the same time is improved, and the retry capability of the call requests is improved.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a disaster recovery method and device for remote service invocation.
Background
Remote invocation of services adds uncertainty to service invocation due to the involvement of network transport and third party services. Remote invocation may fail when network congestion occurs or third party services are unavailable. In order to solve the problem of remote call failure, the following two common disaster recovery methods exist in the prior art:
(1) and the client retries. In the disaster recovery method of client retry, a client node locally starts a timing task retry call. The disaster recovery method of client retry is limited by local memory space, and the number of tasks in the retry queue is limited; when a large number of calls fail at the same time, the local retry queue will expand sharply, which puts a great deal of pressure on the memory. Therefore, the disaster recovery method retried at the client is only suitable for the case of short-time error reporting with a small amount, and cannot handle the case of long-time error reporting with a large amount.
(2) Fusing degrades. In the fusing degradation disaster recovery method, remote calling error amount is monitored, and when the error amount exceeds a threshold value, fusing is requested for a period of time; in the fusing time window, the request directly returns to the default value without really performing remote calling, but the fusing degradation disaster recovery method is not suitable for services with strong dependence on services.
Therefore, it is an urgent technical problem to be solved by those skilled in the art to find a disaster recovery processing method suitable for a large number of failed requests and a long-term unavailable service.
Disclosure of Invention
In view of the foregoing defects in the prior art, an object of the present application is to provide a disaster recovery method and device for remote invocation of a service, so as to solve the problems in the prior art caused by a large number of request failures and a long-term unavailability of the service, thereby improving the capacity of caching and retrying the requests when the large number of requests fail.
In order to achieve the above object, the present application provides a disaster recovery method for remote invocation of a service, which is characterized in that the method includes:
a disaster recovery method for service remote invocation is characterized in that the method comprises the following steps:
establishing remote calling connection between a client and a server;
initiating a calling request to the server;
if the calling is failed, when the current retry times in the message corresponding to the calling request are smaller than the preset maximum retry times, packaging the calling request into an updated message, and adding 1 to the current retry times;
and sending the updated message to an external request delay queue for caching until a preset retry condition is met, and then forwarding to the server to initiate a retry call request.
In a preferred embodiment of the present application, if the call fails, when it is checked that the current retry number in the message corresponding to the call request is smaller than the preset maximum retry number, encapsulating the call request into an updated message, and adding 1 to the current retry number, includes:
if the calling fails, checking the current retry times and the preset maximum retry times in the message corresponding to the calling request,
judging whether the current retry times in the message are less than the preset maximum retry times or not;
and if so, packaging the calling request into an updated message, adding 1 to the current retry number and assigning the current retry number to the current retry number in the updated message.
In a preferred embodiment of the present application, the encapsulating the invocation request into an updated message includes:
and packaging and encapsulating the request parameters in the calling request into the updated message.
In a preferred embodiment of the present application, while packing and encapsulating the request parameter in the invocation request into the updated message, the method further includes:
encapsulating the calling context state data corresponding to the calling request into a request context object;
and taking the callback object and the request context object which correspond to the calling request and are used for receiving the calling return value as parameters of the updated message.
In a preferred embodiment of the present application, after determining whether the current retry number in the message is less than the preset maximum retry number, the method further includes:
if not, directly calling back first response information used for indicating the failure of the service call and finishing the retry call.
In another preferred embodiment of the present application, the method further comprises:
and if the calling is successful, directly calling back second response information used for indicating that the service calling is successful and finishing the calling or retrying the calling.
In a preferred embodiment of the present application, the sending the updated message to an external request delay queue for caching until a preset retry condition is met, and then forwarding to initiate a retry call request to the server, includes:
sending the updated message to an external request delay queue for caching, and forwarding the calling request to a switch when the caching time of the updated message reaches a preset message timeout time so that the switch forwards the updated message to the request queue;
and consuming the message in the request queue to initiate the retry calling request to the server.
In a preferred embodiment of the present application, said consuming the message in the request queue to initiate the retry call request to the server includes:
analyzing the updated message in the request queue to obtain an interface name, a method name and a request parameter in the updated message;
and initiating the retry calling request to the server based on the interface name, the method name and the request parameter in the updated message.
In a preferred embodiment of the present application, the initiating a retry call request to the server includes:
determining retry interval time, initiating a retry call request to the server according to the retry interval time,
the retry interval time is an interval time preset by a user, or an initial retry interval time preset by the user is determined by an exponential back-off algorithm until a preset maximum retry interval time is reached.
The present application further provides a disaster recovery device for remote service invocation, which is characterized in that the device includes:
the connection establishing device is used for establishing remote calling connection between the client and the server;
the initiating and calling device is used for initiating a calling request to the server;
the request encapsulating device is used for encapsulating the calling request into an updated message and adding 1 to the current retry number when the current retry number in the message corresponding to the calling request is smaller than the preset maximum retry number if the calling fails;
and the retry buffer device is used for sending the updated message to an external request delay queue for buffering until a preset retry condition is met, and then forwarding to the server to initiate a retry call request.
In a preferred embodiment of the present application, the request encapsulation means is configured to:
if the calling fails, checking the current retry times and the preset maximum retry times in the message corresponding to the calling request,
judging whether the current retry times in the message are less than the preset maximum retry times or not;
and if so, packaging the calling request into an updated message, adding 1 to the current retry number and assigning the current retry number to the current retry number in the updated message.
In a preferred embodiment of the present application, the request encapsulation means is configured to:
and packaging and encapsulating the request parameters in the calling request into the updated message.
In a preferred embodiment of the present application, the request encapsulation apparatus is further configured to:
encapsulating the calling context state data corresponding to the calling request into a request context object;
and taking the callback object and the request context object which correspond to the calling request and are used for receiving the calling return value as parameters of the updated message.
In a preferred embodiment of the present application, the retry buffering means is configured to:
sending the updated message to an external request delay queue for caching, and forwarding the calling request to a switch when the caching time of the updated message reaches a preset message timeout time so that the switch forwards the updated message to the request queue;
and consuming the message in the request queue to initiate the retry calling request to the server.
In a preferred embodiment of the present application, the retry buffering means is configured to:
determining retry interval time, initiating a retry call request to the server according to the retry interval time,
the retry interval time is an interval time preset by a user, or an initial retry interval time preset by the user is determined by an exponential back-off algorithm until a preset maximum retry interval time is reached.
Compared with the prior art, the disaster recovery method and the disaster recovery equipment for remote service invocation have the following technical effects:
the method comprises the steps that a remote call connection between a client and a server is established, and when the remote call needs to be initiated to the server, a call request is initiated to the server; if the calling is failed, when the current retry times in the message corresponding to the calling request are smaller than the preset maximum retry times, packaging the calling request into an updated message, and adding 1 to the current retry times; and sending the updated message to an external request delay queue for caching until a preset retry condition is met, and then forwarding to the server to initiate a retry call request, so that the call requests corresponding to call failures are cached, the cache of the call requests when a large number of request failures occur at the same time is improved, and the retry capability of the call requests is improved.
The conception, specific structure and technical effects of the present application will be further described in conjunction with the accompanying drawings to fully understand the purpose, characteristics and effects of the present application.
Drawings
FIG. 1 is a schematic flow chart of a disaster recovery method for remote invocation of services according to an aspect of the present application;
fig. 2 is a schematic flowchart of a preferred embodiment in an actual application scenario of a disaster recovery method for remote invocation of a service according to an aspect of the present application.
Fig. 3 is a structural diagram of a disaster tolerance calling module of a micro-service communication framework in a disaster tolerance method for remote service calling according to an aspect of the present application;
fig. 4 is a packet body of a message corresponding to a call request or an updated message in a disaster recovery method for remote invocation of a service according to an aspect of the present application, and a parameter intention included in the packet body;
FIG. 5 is a schematic diagram illustrating an actual application scenario of a disaster recovery method for remote invocation of a service according to an aspect of the present application;
fig. 6 is a schematic structural diagram of a disaster recovery device for remote invocation of a service according to an aspect of the present application.
Detailed Description
The technical contents of the preferred embodiments of the present application will be more clearly and easily understood by referring to the drawings attached to the specification. The present application may be embodied in many different forms of embodiments and the scope of the present application is not limited to only the embodiments set forth herein.
In the drawings, structurally identical elements are represented by like reference numerals, and structurally or functionally similar elements are represented by like reference numerals throughout the several views. The size and thickness of each component shown in the drawings are arbitrarily illustrated, and the size and thickness of each component are not limited in the present application. The thickness of the components may be exaggerated where appropriate in the figures to improve clarity.
As shown in fig. 1, an embodiment of an aspect of the present application provides a flowchart of a disaster recovery method for remote service invocation, which is applied to a client corresponding to any client node in a client cluster in a remote service invocation process. The method comprises a step S11, a step S12, a step S13, a step S14 and a step S15, wherein the method specifically comprises the following steps:
and step S11, establishing the remote call connection between the client and the server. In the step S11, before the remote call is made between the client and the server, a connection for the remote call needs to be established between the client and the server, as shown in the lower half of the dotted line in fig. 2, which is a structure diagram for the remote call of the micro service communication framework in the prior art. In the process of establishing remote call connection between a client and a server, firstly, when a server node in a server cluster is started, service meta-information such as an IP address, a port number and the like of the server node is registered in a registration center; then, when the client node in the client cluster performs service remote calling, the registration center queries original service information such as an IP address, a port number and the like corresponding to the remotely called server node, and establishes connection for service remote calling with the server node through the IP address, so that remote calling connection between the client node and the server node is established through the registration center. After the remote call connection between the client node and the server node is completed, the client node can initiate remote call to the server node, so that the server node executes a corresponding service method to process the call request after receiving the call request, and returns an execution result to the client node after the execution is completed, so as to complete the remote call of the service.
When the client in the client cluster needs to initiate a remote call to the server, step S12 initiates a call request to the server.
If the call fails, the steps S13 and S14 are executed, and if the call succeeds, the step S15 is executed.
In step S13, when it is checked that the current retry number retryCount in the message corresponding to the invocation request is smaller than the preset maximum retry number totalCount, the invocation request is encapsulated into an updated message, and the current retry number is added by 1, that is, retryCount +1, so as to package the invocation request into a message and add 1 to the current retry number in the updated message in an accumulated manner when the invocation fails.
And step S14, sending the updated message to an external request delay queue for caching, and after a preset retry condition is met, forwarding to initiate a retry call request to the server.
If the call is successful, in step S15, the second response message indicating that the service call is successful is directly called back, and the call is ended or the call is retried. For example, in the step S15, when the call request is a first call, if the call is successful, the step S15 directly calls back second response information indicating that the service call is successful and ends the call; when the call request is not the first call, that is, belongs to the retried call request, if the call is successful, the step S15 directly calls back the second response information indicating that the service call is successful and ends the retried call, so as to implement the callback response when the remote call is successful.
Through the steps S11 to S15, the call requests during call failure are cached through the external request delay queue, so that the cache of the call requests during simultaneous occurrence of a large number of request failures is improved, and the retry capability of the call requests is improved; and when the calling is successful, calling back second response information used for indicating that the service calling is successful and finishing the calling or retrying the calling, so as to realize the calling back response when the remote calling is successful.
Next, in the above embodiment of the present application, after the step S12 initiates a call request to the server, if the call is successful, the call is directly called back to object. If the call fails, in step S13, when it is detected that the current retry number retryCount in the message corresponding to the call request is smaller than the preset maximum retry number totalCount, encapsulating the call request into an updated message, and adding 1 to the current retry number, which specifically includes:
if the calling fails, checking the current retry times and the preset maximum retry times in the message corresponding to the calling request,
judging whether the current retry times in the message are less than the preset maximum retry times or not;
and if so, packaging the calling request into an updated message, adding 1 to the current retry number and assigning the current retry number to the current retry number in the updated message.
For example, when the call fails, the step S13 checks values of a current retry number retryCount and a preset maximum retry number totalCount in the message corresponding to the call request (when the call request is the first call, the current retry number retryCount is 0), so as to determine whether to retry the call according to the values of the current retry number retryCount and the preset maximum retry number totalCount in the message corresponding to the call request. Judging whether the current retry time retryCount in the message is smaller than the preset maximum retry time totalCount or not, if so, the number of times of the retried call of the message corresponding to the call request is less than the preset maximum retry number, the retried call can be continued, the call request is encapsulated into an updated message, and before the updated message is sent each time, the current retry number is added with 1 and then assigned to the current retry number retryCount in the updated message, namely retryCount + 1, to realize that when the call fails and the current retry number in the message corresponding to the call request is less than the preset maximum retry number, and packaging the call request and putting the updated message obtained after the processing into a request delay queue for caching, thereby realizing the caching of the call failure request so as to retry the subsequent call.
Following the above embodiment of the present application, after the determining whether the current retry number in the message is smaller than the preset maximum retry number in step S13, the method further includes:
if not, directly calling back first response information used for indicating the failure of the service call and finishing the retry call.
For example, in step S13, it is determined whether the current retry number retryCount in the message corresponding to the call request is smaller than the preset maximum retry number totalCount, and if not, it indicates that the number of retried calls of the message corresponding to the call request is greater than or equal to the preset maximum retry number, the call request is not retried, the call request is directly called back to onerror (), a service call failure is notified, and the retry call flow is ended, so as to implement ending processing of the call request exceeding the preset maximum retry number, and save more call memory resources to satisfy another call request.
Next to the foregoing embodiment of the present application, the encapsulating the invocation request into an updated message in step S13 specifically includes:
and packaging and encapsulating the request parameters in the calling request into the updated message.
For example, when the call fails, if the current retry number retryCount in the message corresponding to the call request detected in step S13 is smaller than the preset maximum retry number totalCount, which indicates that the number of times that the message corresponding to the call request has been retried is smaller than the preset maximum retry number, and the retry call may be continued, the request parameter in the call request is packaged and encapsulated into an updated message, which includes a packet header and a packet body, as shown in fig. 3 and 4, fig. 3 shows the packet header and the parameters included in the packet header of the message corresponding to the call request or the updated message, fig. 4 shows the packet body of the message corresponding to the call request or the updated message and the parameters included in the packet body, and brief descriptions of the parameters in fig. 3 and 4 are shown in table 1.
TABLE 1 description of the various parameter fields in the message
| Field(s) | Description of the invention |
| retryCount | Current number of retries |
| totalCount | Maximum number of retries |
| retryPolicy | Retry strategy |
| Expiration | Message timeout time |
| Interface | Interface name |
| method | Name of method |
| context | Requesting context |
| requestJson | Request parameters |
| observer | Callback object for service registration |
Next to the foregoing embodiment of the present application, any client node of the client cluster may consume the call request in the request queue, so that the client node that initiates the retry call request may be different from the client node that initiates the first call request, and in order to facilitate notifying the service of the result of success or failure of the call after the retry call is completed, and to complete the subsequent service flow, the step S13 in this embodiment of the present application, while packing and encapsulating the request parameter in the call request into the updated message, further includes:
encapsulating the calling context state data corresponding to the calling request into a request context object;
and taking the callback object and the request context object which correspond to the calling request and are used for receiving the calling return value as parameters of the updated message.
For example, in the embodiment of the present application, when a service disaster tolerance call is performed, in addition to a request parameter in a call request, a parameter of a request context object context needs to be transmitted, and a callback object oberver of a service, that is, a callback method, is registered. When the request parameters are packaged and encapsulated in the message in step S13, the call context state data corresponding to the call request is further encapsulated into a request context object, and both the callback object for receiving the call return value and the request context object corresponding to the call request are used as parameters of the updated message, so that the context state data of the call request is transferred through the request context object, and the callback object for receiving the call return value is received through the callback object oberver, so that the user can package the parameters required by the service itself into the upper request context object context. When the callback object oberver is called back, the request context object context is transmitted to the callback method corresponding to the callback object oberver together with the return value, so that a user acquires the request context data during calling in the callback method and continues the subsequent service logic, the client nodes in the client cluster do not keep any calling context state, but encapsulate the calling context state data into the request context object context, and transmit the request context object context as the parameter in the message or the updated message together with the message or the updated message, therefore, any client node in the client cluster can consume the updated message corresponding to the calling request to retry calling. And when the disaster recovery calling is completed, calling back the callback object obeser of the service, and transmitting the request context object to the callback object obeser, so that the callback object obeser continuously completes subsequent service logic according to the parameters in the request context object, thereby realizing the call back service after the client receives the called return value (whether the calling is successful or not) and completing the subsequent service logic.
Next to the above embodiment of the present application, the step S14 sends the updated message to an external request delay queue for caching, and after a preset retry condition is met, turns to initiate a retry call request to the server, specifically including:
sending the updated message to an external request delay queue for caching, and forwarding the calling request to a switch when the caching time of the updated message reaches a preset message timeout time so that the switch forwards the updated message to the request queue; here, the preset message timeout time may include, but is not limited to, any duration of time, and the like.
And consuming the message in the request queue to initiate the retry calling request to the server.
The request delay queue is used for storing the request of call failure and the corresponding encapsulated message, and the request queue is used for storing the request of the client node about to retry the call, so that the client node can consume the message in the request queue at any time to initiate the request of retry call.
For example, after the calling request with a failed call is packaged and encapsulated in step S13, the corresponding updated message is sent to the external request delay queue for buffering when the calling request needs to retry again in step S14, so that the updated message is accumulated in the request delay queue, and the buffering time of the message buffered in the request delay queue is recorded; when the buffering time of the message in the request delay queue reaches the preset message timeout time expiry, forwarding a calling request of the message corresponding to the timeout to the switch so that the switch forwards the updated message of the calling request to the request queue; so that the client can consume the message in the request queue to initiate the retry call request to the server, and thus after the call request and the message thereof enter the request delay queue for buffering, the message can be subsequently consumed by the client and forwarded to the request queue, for example, a frame diagram of the upper part of the client cluster in fig. 2 sending the retry call request to the request delay queue.
Following the above embodiment of the present application, the consuming the message in the request queue in step S14 to initiate the retry call request to the server, includes:
analyzing the updated message in the request queue to obtain an interface name, a method name and a request parameter in the updated message;
and initiating the retry calling request to the server based on the interface name, the method name and the request parameter in the updated message.
For example, the client parses an updated message corresponding to the call request forwarded to the request queue, and the parameters such as the interface name interface, the method name method, and the request parameter request Json parsed from the updated message, so that the client can initiate a retry call request for remote call to the server based on the parameters such as the interface name interface, the method name method, and the request parameter request Json obtained after parsing, and then go to step S12 to execute a remote call process to the server, so that the client consumes the message forwarded from the request delay queue to the request queue, and retry of the remote call is realized.
Next to the foregoing embodiment of the present application, the initiating a retry call request to the server in step S14 includes:
determining retry interval time, initiating a retry call request to the server according to the retry interval time,
the retry interval time is an interval time preset by a user, or an initial retry interval time preset by the user is determined by an exponential back-off algorithm until a preset maximum retry interval time is reached.
It should be noted that in the embodiment of the present application, when performing call retry, a plurality of retry policies retryPolicy may be adopted, and the following description is mainly made from two retry policies:
the method comprises the steps that a retry strategy I is adopted, a user of a client can set a preset maximum retry number totalCount and a retry interval time for remote call retry, when the client consumes a message in a request queue, a retry call request can be sent to a server according to the set retry interval time for the message in the request queue, if the call fails, the retry interval time is used again for initiating a next retry call request to the server, and the retry call request is initiated to the server until the call is successful or the preset maximum retry number totalCount is reached, so that the retry call request is initiated to the server according to the invariable retry interval time. Here, the retry interval time is greater than the preset message timeout time of the call request buffered in the request delay queue, so that the call request needing to be retried can enter the request queue to be consumed by the client after the call request buffered in the request delay queue expires.
And a retry strategy II, wherein the exponential backoff algorithm is an exponential backoff algorithm, the exponential backoff algorithm is based on the size of a collision window, each node is provided with a collision counter, the backoff time and the collision times have an exponential relationship, the backoff time is possibly longer as the collision times are more, and the node stops sending data if the limited collision times are reached. In the embodiment of the present application, a user of a client may set an initial retry interval for performing a subsequent call retry, where, along with occurrence of a call failure, a retry interval for initiating a retry call request for the first time is the initial retry interval, and retry intervals for initiating a retry call request to a server for the second time, the third time, and the subsequent nth (i.e., totalCount) time are:
and (2) baseSleepTimeMs Math.max (1, random. nextInt (1 < (retry Conut +1))) until the call is successful or a preset maximum retry number is reached, so that the retry interval time is changed at the client according to an exponential backoff algorithm, and the retry call request is initiated to the server by adopting different retry interval times. Where basesleeptimer represents the initial retry interval time and retryconcet represents the current number of retries.
As shown in fig. 5, in an actual application scenario of the disaster recovery method for remote invocation of service provided in the embodiment of the present application, after a remote invocation connection is proposed between a client and a server, when the client needs to initiate a remote invocation to the server, the client initiates the remote invocation to the server. Determining whether the calling is successful or not according to the return value, if the calling is successful, calling back the object. If the call fails, checking values of a current retry number retryCount and a preset maximum retry number totalCount in a message corresponding to the call request (when the call request is called for the first time, the current retry number retryCount is 0), so as to determine whether to retry the call according to the values of the current retry number retryCount and the preset maximum retry number totalCount in the message corresponding to the call request. Judging whether the current retry number retryCount in the message is smaller than the preset maximum retry number totalCount, if not, indicating that the number of times that the message corresponding to the call request has retried the call is larger than or equal to the preset maximum retry number, directly calling back an object. If so, indicating that the number of times of retried call of the message corresponding to the call request is less than the preset maximum number of times of retries, and continuing to perform the retried call, encapsulating the call request into an updated message, adding 1 to the current number of retries before sending the updated message each time, assigning the current number of retries retryCount in the updated message, namely retryCount + 1, encapsulating the call request, and putting the updated message obtained after processing into a request delay queue for caching, thereby realizing caching of the call failure request so as to perform the retries of the call subsequently.
In the process of call retry, when the buffering time of the message in the request delay queue reaches the preset message timeout time expiry, forwarding the call request of the message corresponding to the timeout to the switch, so that the switch forwards the updated message of the call request to the request queue, so that the client can consume the message in the request queue to initiate the retry call request to the server, and then going to step S12 to execute the remote call process to the server, so as to realize that the client consumes the message forwarded from the request delay queue to the request queue, thereby implementing retry of the remote call.
According to another aspect of the present application, as shown in fig. 6, an embodiment of an aspect of the present application further provides a schematic structural diagram of a disaster recovery device for service remote invocation, where the disaster recovery device includes a connection establishing device 11, an initiating invoking device 12, a request encapsulating device 13, a retry buffering device 14, and an invocation success device 15, where the method specifically includes the following steps:
and the connection establishing device 11 is used for establishing the remote call connection between the client and the server. In the connection establishing apparatus 11, before the remote call is made between the client and the server, a connection for the remote call needs to be established between the client and the server, as shown in the lower half of the dotted line in fig. 2, which is a structure diagram for the remote call of the micro service communication framework in the prior art. In the process of establishing remote call connection between a client and a server, firstly, when a server node in a server cluster is started, service meta-information such as an IP address, a port number and the like of the server node is registered in a registration center; then, when the client node in the client cluster performs service remote calling, the registration center queries original service information such as an IP address, a port number and the like corresponding to the remotely called server node, and establishes connection for service remote calling with the server node through the IP address, so that remote calling connection between the client node and the server node is established through the registration center. After the remote call connection between the client node and the server node is completed, the client node can initiate remote call to the server node, so that the server node executes a corresponding service method to process the call request after receiving the call request, and returns an execution result to the client node after the execution is completed, so as to complete the remote call of the service.
When a client in the client cluster needs to initiate a remote call to a server, the initiating and calling device 12 is configured to initiate a call request to the server.
If the call fails, the execution request encapsulation means 13 and the retry cache means 14 execute the call success means 15.
The request encapsulating device 13 is configured to encapsulate the invocation request into an updated message and add 1 to the current retry number, that is, retryCount +1, when it is checked that the current retry number retryCount in the message corresponding to the invocation request is smaller than the preset maximum retry number totalCount, so as to package the invocation request into the message and add 1 to the current retry number in the updated message in an accumulated manner when the invocation fails.
The retry buffer device 14 is configured to send the updated message to an external request delay queue for buffering until a preset retry condition is met, and then forward to initiate a retry call request to the server.
And if the call is successful, the call success device 15 is used for directly calling back second response information used for indicating that the service call is successful and finishing the call or retrying the call. For example, in the call success apparatus 15, when the call request is a first call, if the call is successful, the call success apparatus 15 directly calls back the second response information for indicating that the service call is successful and ends the call; when the call request is not the first call, that is, belongs to the retried call request, if the call is successful, the call success apparatus 15 directly calls back the second response information indicating that the service call is successful and ends the retried call, so as to implement the callback response when the remote call is successful.
Through the connection establishing device 11, the call initiating device 12, the request encapsulating device 13, the retry buffer device 14 and the call success device 15, the call requests during call failure are buffered through an external request delay queue, so that the buffer of the call requests during simultaneous occurrence of a large number of request failures is improved, and the retry capability of the call requests is improved; and when the calling is successful, calling back second response information used for indicating that the service calling is successful and finishing the calling or retrying the calling, so as to realize the calling back response when the remote calling is successful.
Following the above embodiment of the present application, the call initiating device 12 is specifically configured to:
if the calling fails, checking the current retry times and the preset maximum retry times in the message corresponding to the calling request,
judging whether the current retry times in the message are less than the preset maximum retry times or not;
and if so, packaging the calling request into an updated message, adding 1 to the current retry number and assigning the current retry number to the current retry number in the updated message.
For example, when the call fails, the request encapsulation device 13 checks values of a current retry number retryCount and a preset maximum retry number totalCount in a message corresponding to the call request (when the call request is a first call, the current retry number retryCount is 0), so as to determine whether to retry the call according to the values of the current retry number retryCount and the preset maximum retry number totalCount in the message corresponding to the call request. Judging whether the current retry time retryCount in the message is smaller than the preset maximum retry time totalCount or not, if so, the number of times of the retried call of the message corresponding to the call request is less than the preset maximum retry number, the retried call can be continued, the call request is encapsulated into an updated message, and before the updated message is sent each time, the current retry number is added with 1 and then assigned to the current retry number retryCount in the updated message, namely retryCount + 1, to realize that when the call fails and the current retry number in the message corresponding to the call request is less than the preset maximum retry number, and packaging the call request and putting the updated message obtained after the processing into a request delay queue for caching, thereby realizing the caching of the call failure request so as to retry the subsequent call.
Following the above-described embodiments of the present application, the request encapsulation apparatus 13 is further configured to:
if not, directly calling back first response information used for indicating the failure of the service call and finishing the retry call.
For example, in the request encapsulating device 13, it is determined whether the current retry number retryCount in the message corresponding to the call request is smaller than the preset maximum retry number totalCount, if not, it indicates that the number of retried calls of the message corresponding to the call request is greater than or equal to the preset maximum retry number, the call request is not retried, the call request is directly called back to onerror (), the service call failure is notified, and the retry call flow is ended, so as to implement ending processing of the call request exceeding the preset maximum retry number, and save more call memory resources to satisfy another call request.
Following the above embodiments of the present application, the request encapsulation apparatus 13 is specifically configured to:
and packaging and encapsulating the request parameters in the calling request into the updated message.
For example, when the call fails, if the current retry number retryCount in the message corresponding to the call request detected by the request encapsulation device 13 is less than the preset maximum retry number totalCount, which indicates that the number of times that the message corresponding to the call request has been retried is less than the preset maximum retry number, and the retry call may be continued, then the request parameter in the call request is encapsulated and encapsulated into an updated message, where the updated message includes a packet header and a packet body, as shown in fig. 3 and 4, fig. 3 shows the packet header and the parameters included in the packet header of the message corresponding to the call request or the updated message, fig. 4 shows the packet body of the message corresponding to the call request or the updated message and the parameters included in the packet body, and brief descriptions of the parameters in fig. 3 and 4 are shown in table 1.
TABLE 1 description of the various parameter fields in the message
| Field(s) | Description of the invention |
| retryCount | Current number of retries |
| totalCount | Maximum number of retries |
| retryPolicy | Retry strategy |
| Expiration | Message timeout time |
| Interface | Interface name |
| method | Name of method |
| context | Requesting context |
| requestJson | Request parameters |
| observer | Callback object for service registration |
Next to the foregoing embodiment of the present application, any client node of the client cluster may consume the call request in the request queue, so that the client node that initiates the retry call request may be different from the client node that initiates the first call request, and in order to notify the result of success or failure of the call to the service after the retry call is completed and complete the subsequent service flow, the request encapsulating device 13 in this embodiment of the present application is further configured to:
encapsulating the calling context state data corresponding to the calling request into a request context object;
and taking the callback object and the request context object which correspond to the calling request and are used for receiving the calling return value as parameters of the updated message.
For example, in the embodiment of the present application, when a service disaster tolerance call is performed, in addition to a request parameter in a call request, a parameter of a request context object context needs to be transmitted, and a callback object oberver of a service, that is, a callback method, is registered. When the request parameters are packaged and encapsulated in the message in the request encapsulation device 13, the call context state data corresponding to the call request is further encapsulated into a request context object, and both the callback object for receiving the call return value and the request context object corresponding to the call request are used as parameters of the updated message, so that the context state data of the call request is transferred through the request context object, and the callback object for receiving the call return value is received through the callback object oberver, so that the user can package the parameters required by the service itself into the upper request context object context. When the callback object oberver is called back, the request context object context is transmitted to the callback method corresponding to the callback object oberver together with the return value, so that a user acquires the request context data during calling in the callback method and continues the subsequent service logic, the client nodes in the client cluster do not keep any calling context state, but encapsulate the calling context state data into the request context object context, and transmit the request context object context as the parameter in the message or the updated message together with the message or the updated message, therefore, any client node in the client cluster can consume the updated message corresponding to the calling request to retry calling. And when the disaster recovery calling is completed, calling back the callback object obeser of the service, and transmitting the request context object to the callback object obeser, so that the callback object obeser continuously completes subsequent service logic according to the parameters in the request context object, thereby realizing the call back service after the client receives the called return value (whether the calling is successful or not) and completing the subsequent service logic.
Next to the above embodiments of the present application, the retry buffering apparatus 14 is specifically configured to:
sending the updated message to an external request delay queue for caching, and forwarding the calling request to a switch when the caching time of the updated message reaches a preset message timeout time so that the switch forwards the updated message to the request queue; here, the preset message timeout time may include, but is not limited to, any duration of time, and the like.
And consuming the message in the request queue to initiate the retry calling request to the server.
The request delay queue is used for storing the request of call failure and the corresponding encapsulated message, and the request queue is used for storing the request of the client node about to retry the call, so that the client node can consume the message in the request queue at any time to initiate the request of retry call.
For example, after the request encapsulation device 13 encapsulates and packages the call request that fails to be invoked, the retry cache device 14 sends the updated message corresponding to the call request that needs to be retried again to an external request delay queue for caching, so that the updated message is accumulated in the request delay queue, and records the cache time of the message cached in the request delay queue; when the buffering time of the message in the request delay queue reaches the preset message timeout time expiry, forwarding a calling request of the message corresponding to the timeout to the switch so that the switch forwards the updated message of the calling request to the request queue; so that the client can consume the message in the request queue to initiate the retry call request to the server, and thus after the call request and the message thereof enter the request delay queue for buffering, the message can be subsequently consumed by the client and forwarded to the request queue, for example, a frame diagram of the upper part of the client cluster in fig. 2 sending the retry call request to the request delay queue.
Next to the above embodiments of the present application, the retry buffering apparatus 14 is specifically configured to:
analyzing the updated message in the request queue to obtain an interface name, a method name and a request parameter in the updated message;
and initiating the retry calling request to the server based on the interface name, the method name and the request parameter in the updated message.
For example, the client analyzes the updated message corresponding to the call request forwarded to the request queue, and the parameters such as the interface name interface, the method name method, and the request parameter request Json analyzed from the updated message, so that the client can initiate a retry call request for remote call to the server based on the parameters such as the interface name interface, the method name method, and the request parameter request Json obtained after analysis, and then transfer to the initiating call device 12 to execute a remote call process to the server, so that the client consumes the message forwarded from the request delay queue to the request queue, and retry of the remote call is realized.
Next to the above embodiments of the present application, the retry buffering apparatus 14 is specifically configured to:
determining retry interval time, initiating a retry call request to the server according to the retry interval time,
the retry interval time is an interval time preset by a user, or an initial retry interval time preset by the user is determined by an exponential back-off algorithm until a preset maximum retry interval time is reached.
It should be noted that in the embodiment of the present application, when performing call retry, a plurality of retry policies retryPolicy may be adopted, and the following description is mainly made from two retry policies:
the method comprises the steps that a retry strategy I is adopted, a user of a client can set a preset maximum retry number totalCount and a retry interval time for remote call retry, when the client consumes a message in a request queue, a retry call request can be sent to a server according to the set retry interval time for the message in the request queue, if the call fails, the retry interval time is used again for initiating a next retry call request to the server, and the retry call request is initiated to the server until the call is successful or the preset maximum retry number totalCount is reached, so that the retry call request is initiated to the server according to the invariable retry interval time. Here, the retry interval time is greater than the preset message timeout time of the call request buffered in the request delay queue, so that the call request needing to be retried can enter the request queue to be consumed by the client after the call request buffered in the request delay queue expires.
And a retry strategy II, wherein the exponential backoff algorithm is an exponential backoff algorithm, the exponential backoff algorithm is based on the size of a collision window, each node is provided with a collision counter, the backoff time and the collision times have an exponential relationship, the backoff time is possibly longer as the collision times are more, and the node stops sending data if the limited collision times are reached. In the embodiment of the present application, a user of a client may set an initial retry interval for performing a subsequent call retry, where, along with occurrence of a call failure, a retry interval for initiating a retry call request for the first time is the initial retry interval, and retry intervals for initiating a retry call request to a server for the second time, the third time, and the subsequent nth (i.e., totalCount) time are:
base S1eepTimeMs Math.max (1, random. nextInt (1 < (retry Conut +1))) until the call is successful or the preset maximum retry number is reached, so that the retry interval time is changed at the client according to an exponential backoff algorithm, and the retry call request is initiated to the server by adopting different retry interval times. Where basesleeptimer represents the initial retry interval time and retryconcet represents the current number of retries.
As shown in fig. 5, in an actual application scenario of the disaster recovery method for remote invocation of service provided in the embodiment of the present application, after a remote invocation connection is proposed between a client and a server, when the client needs to initiate a remote invocation to the server, the client initiates the remote invocation to the server. Determining whether the calling is successful or not according to the return value, if the calling is successful, calling back the object. If the call fails, checking values of a current retry number retryCount and a preset maximum retry number totalCount in a message corresponding to the call request (when the call request is called for the first time, the current retry number retryCount is 0), so as to determine whether to retry the call according to the values of the current retry number retryCount and the preset maximum retry number totalCount in the message corresponding to the call request. Judging whether the current retry number retryCount in the message is smaller than the preset maximum retry number totalCount, if not, indicating that the number of times that the message corresponding to the call request has retried the call is larger than or equal to the preset maximum retry number, directly calling back an object. If so, indicating that the number of times of retried call of the message corresponding to the call request is less than the preset maximum number of times of retries, and continuing to perform the retried call, encapsulating the call request into an updated message, adding 1 to the current number of retries before sending the updated message each time, assigning the current number of retries retryCount in the updated message, namely retryCount + 1, encapsulating the call request, and putting the updated message obtained after processing into a request delay queue for caching, thereby realizing caching of the call failure request so as to perform the retries of the call subsequently.
In the process of call retry, when the buffering time of the message in the request delay queue reaches the preset message timeout time expiry, the call request of the message corresponding to the timeout is forwarded to the switch, so that the switch forwards the updated message of the call request to the request queue, so that the client can consume the message in the request queue, and initiate the retry call request to the server, and then forward to the process of executing the remote call to the server in the call initiating device 12, so that the client consumes the message forwarded from the request delay queue to the request queue, and retry of the remote call is realized.
In summary, the method includes the steps that a remote call connection between a client and a server is established, and when a remote call needs to be initiated to the server, a call request is initiated to the server; if the calling is failed, when the current retry times in the message corresponding to the calling request are smaller than the preset maximum retry times, packaging the calling request into an updated message, and adding 1 to the current retry times; and sending the updated message to an external request delay queue for caching until a preset retry condition is met, and then forwarding to the server to initiate a retry call request, so that the call requests corresponding to call failures are cached, the cache of the call requests when a large number of request failures occur at the same time is improved, and the retry capability of the call requests is improved.
The foregoing detailed description of the preferred embodiments of the present application. It should be understood that numerous modifications and variations can be devised by those skilled in the art in light of the present teachings without departing from the inventive concepts. Therefore, the technical solutions available to those skilled in the art through logic analysis, reasoning and limited experiments based on the concepts of the present application should be within the scope of protection defined by the claims.
Claims (15)
1. A disaster recovery method for service remote invocation is characterized in that the method comprises the following steps:
establishing remote calling connection between a client and a server;
initiating a calling request to the server;
if the calling is failed, when the current retry times in the message corresponding to the calling request are smaller than the preset maximum retry times, packaging the calling request into an updated message, and adding 1 to the current retry times;
and sending the updated message to an external request delay queue for caching until a preset retry condition is met, and then forwarding to the server to initiate a retry call request.
2. The method of claim 1, wherein if the call fails, when it is checked that a current retry number in a message corresponding to the call request is less than a preset maximum retry number, encapsulating the call request into an updated message, and adding 1 to the current retry number, comprises:
if the calling fails, checking the current retry times and the preset maximum retry times in the message corresponding to the calling request,
judging whether the current retry times in the message are less than the preset maximum retry times or not;
and if so, packaging the calling request into an updated message, adding 1 to the current retry number and assigning the current retry number to the current retry number in the updated message.
3. The method of claim 1 or 2, wherein said encapsulating the invocation request into an updated message comprises:
and packaging and encapsulating the request parameters in the calling request into the updated message.
4. The method of claim 3, wherein packaging and encapsulating the request parameters in the invocation request into the updated message further comprises:
encapsulating the calling context state data corresponding to the calling request into a request context object;
and taking the callback object and the request context object which correspond to the calling request and are used for receiving the calling return value as parameters of the updated message.
5. The method of claim 2, wherein said determining whether the current number of retries in the message is less than the preset maximum number of retries further comprises:
if not, directly calling back first response information used for indicating the failure of the service call and finishing the retry call.
6. The method of claim 1, wherein the method further comprises:
and if the calling is successful, directly calling back second response information used for indicating that the service calling is successful and finishing the calling or retrying the calling.
7. The method of claim 1, wherein sending the updated message to an external request delay queue for buffering until a preset retry condition is met, and then forwarding to initiate a retry call request to the server, comprises:
sending the updated message to an external request delay queue for caching, and forwarding the calling request to a switch when the caching time of the updated message reaches a preset message timeout time so that the switch forwards the updated message to the request queue;
and consuming the message in the request queue to initiate the retry calling request to the server.
8. The method of claim 1, wherein said consuming the message in the request queue to initiate the retry call request to the server, comprises:
analyzing the updated message in the request queue to obtain an interface name, a method name and a request parameter in the updated message;
and initiating the retry calling request to the server based on the interface name, the method name and the request parameter in the updated message.
9. The method of any of claims 1 to 8, wherein the initiating a retry call request to the server comprises:
determining retry interval time, initiating a retry call request to the server according to the retry interval time,
the retry interval time is an interval time preset by a user, or an initial retry interval time preset by the user is determined by an exponential back-off algorithm until a preset maximum retry interval time is reached.
10. A disaster recovery device for remote invocation of services, said device comprising:
the connection establishing device is used for establishing remote calling connection between the client and the server;
the initiating and calling device is used for initiating a calling request to the server;
the request encapsulating device is used for encapsulating the calling request into an updated message and adding 1 to the current retry number when the current retry number in the message corresponding to the calling request is smaller than the preset maximum retry number if the calling fails;
and the retry buffer device is used for sending the updated message to an external request delay queue for buffering until a preset retry condition is met, and then forwarding to the server to initiate a retry call request.
11. The apparatus of claim 10, wherein the request encapsulation means is to:
if the calling fails, checking the current retry times and the preset maximum retry times in the message corresponding to the calling request,
judging whether the current retry times in the message are less than the preset maximum retry times or not;
and if so, packaging the calling request into an updated message, adding 1 to the current retry number and assigning the current retry number to the current retry number in the updated message.
12. The apparatus of claim 10 or 11, wherein the request encapsulation means is to:
and packaging and encapsulating the request parameters in the calling request into the updated message.
13. The apparatus of claim 12, wherein the request encapsulation means is further for:
encapsulating the calling context state data corresponding to the calling request into a request context object;
and taking the callback object and the request context object which correspond to the calling request and are used for receiving the calling return value as parameters of the updated message.
14. The apparatus of claim 10, wherein the retry buffering means is to:
sending the updated message to an external request delay queue for caching, and forwarding the calling request to a switch when the caching time of the updated message reaches a preset message timeout time so that the switch forwards the updated message to the request queue;
and consuming the message in the request queue to initiate the retry calling request to the server.
15. The apparatus of any of claims 10 to 14, wherein the retry buffering means is to:
determining retry interval time, initiating a retry call request to the server according to the retry interval time,
the retry interval time is an interval time preset by a user, or an initial retry interval time preset by the user is determined by an exponential back-off algorithm until a preset maximum retry interval time is reached.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010019828.7A CN111258776A (en) | 2020-01-09 | 2020-01-09 | Disaster recovery method and device for remote service calling |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010019828.7A CN111258776A (en) | 2020-01-09 | 2020-01-09 | Disaster recovery method and device for remote service calling |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111258776A true CN111258776A (en) | 2020-06-09 |
Family
ID=70954096
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010019828.7A Pending CN111258776A (en) | 2020-01-09 | 2020-01-09 | Disaster recovery method and device for remote service calling |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111258776A (en) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111984437A (en) * | 2020-08-31 | 2020-11-24 | 平安医疗健康管理股份有限公司 | DRG packet server RPC service processing method and device and computer equipment |
| CN112087510A (en) * | 2020-09-08 | 2020-12-15 | 工银科技有限公司 | Request processing method and device, electronic equipment and medium |
| CN113783826A (en) * | 2020-09-22 | 2021-12-10 | 北京沃东天骏信息技术有限公司 | Micro-service exception handling method and device |
| CN113778567A (en) * | 2021-07-29 | 2021-12-10 | 广州酷车信息科技有限公司 | Service call retry method, device, equipment and storage medium |
| CN113778702A (en) * | 2021-01-12 | 2021-12-10 | 北京沃东天骏信息技术有限公司 | Method and device for determining timeout time, electronic equipment and storage medium |
| CN113794622A (en) * | 2021-08-17 | 2021-12-14 | 北京达佳互联信息技术有限公司 | Message processing method and device, electronic equipment and storage medium |
| CN113810266A (en) * | 2021-08-13 | 2021-12-17 | 北京达佳互联信息技术有限公司 | Retry operation method, device, equipment and storage medium for message object |
| CN113965482A (en) * | 2021-10-19 | 2022-01-21 | 北京天融信网络安全技术有限公司 | Data transmission method and device based on gRPC and storage medium |
| CN114911633A (en) * | 2021-02-07 | 2022-08-16 | 北京字节跳动网络技术有限公司 | Remote procedure call retry method, device and equipment |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2012022074A1 (en) * | 2010-08-19 | 2012-02-23 | 中兴通讯股份有限公司 | User information query method and multimedia messaging service center |
| CN106250250A (en) * | 2016-08-09 | 2016-12-21 | 广州唯品会信息科技有限公司 | Data communications method and device |
| CN106502769A (en) * | 2016-09-30 | 2017-03-15 | 华为技术有限公司 | Distributed transaction processing method, apparatus and system |
| CN110224922A (en) * | 2019-05-21 | 2019-09-10 | 成都路行通信息技术有限公司 | A kind of asynchronous message based on RabbitMQ retries method, system and system constituting method |
| CN110377410A (en) * | 2019-07-16 | 2019-10-25 | 中信百信银行股份有限公司 | Method for scheduling task, system, electronic equipment and computer readable storage medium |
-
2020
- 2020-01-09 CN CN202010019828.7A patent/CN111258776A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2012022074A1 (en) * | 2010-08-19 | 2012-02-23 | 中兴通讯股份有限公司 | User information query method and multimedia messaging service center |
| CN106250250A (en) * | 2016-08-09 | 2016-12-21 | 广州唯品会信息科技有限公司 | Data communications method and device |
| CN106502769A (en) * | 2016-09-30 | 2017-03-15 | 华为技术有限公司 | Distributed transaction processing method, apparatus and system |
| CN110224922A (en) * | 2019-05-21 | 2019-09-10 | 成都路行通信息技术有限公司 | A kind of asynchronous message based on RabbitMQ retries method, system and system constituting method |
| CN110377410A (en) * | 2019-07-16 | 2019-10-25 | 中信百信银行股份有限公司 | Method for scheduling task, system, electronic equipment and computer readable storage medium |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111984437A (en) * | 2020-08-31 | 2020-11-24 | 平安医疗健康管理股份有限公司 | DRG packet server RPC service processing method and device and computer equipment |
| CN112087510A (en) * | 2020-09-08 | 2020-12-15 | 工银科技有限公司 | Request processing method and device, electronic equipment and medium |
| CN112087510B (en) * | 2020-09-08 | 2022-10-28 | 中国工商银行股份有限公司 | Request processing method, device, electronic equipment and medium |
| CN113783826A (en) * | 2020-09-22 | 2021-12-10 | 北京沃东天骏信息技术有限公司 | Micro-service exception handling method and device |
| CN113783826B (en) * | 2020-09-22 | 2023-08-04 | 北京沃东天骏信息技术有限公司 | Micro-service exception handling method and device |
| CN113778702A (en) * | 2021-01-12 | 2021-12-10 | 北京沃东天骏信息技术有限公司 | Method and device for determining timeout time, electronic equipment and storage medium |
| CN114911633A (en) * | 2021-02-07 | 2022-08-16 | 北京字节跳动网络技术有限公司 | Remote procedure call retry method, device and equipment |
| CN113778567A (en) * | 2021-07-29 | 2021-12-10 | 广州酷车信息科技有限公司 | Service call retry method, device, equipment and storage medium |
| CN113810266A (en) * | 2021-08-13 | 2021-12-17 | 北京达佳互联信息技术有限公司 | Retry operation method, device, equipment and storage medium for message object |
| CN113794622A (en) * | 2021-08-17 | 2021-12-14 | 北京达佳互联信息技术有限公司 | Message processing method and device, electronic equipment and storage medium |
| CN113965482A (en) * | 2021-10-19 | 2022-01-21 | 北京天融信网络安全技术有限公司 | Data transmission method and device based on gRPC and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111258776A (en) | Disaster recovery method and device for remote service calling | |
| US8804513B2 (en) | Methods and systems for controlling SIP overload | |
| US8374079B2 (en) | Proxy server, communication system, communication method and program | |
| US20210126888A1 (en) | Methods, Central Unit and Distributed Unit of a Radio Network Node, for Handling a Message for Transmission to a Wireless Device | |
| CN105635083A (en) | Service processing method and service processing system based on server and client architecture | |
| CN113765976A (en) | Communication method and system | |
| CN113986501A (en) | Real-time database API (application program interface) uninterrupted calling method, system, storage medium and server | |
| EP3736696A1 (en) | Early gx/rx session failure detection and response | |
| WO2019042032A1 (en) | Data transmission method, rlc entity and pdcp entity | |
| US9137703B2 (en) | Technique for handling a data packet stream | |
| CN117040692A (en) | Method and device for transmitting service data, electronic equipment and storage medium | |
| US11424864B2 (en) | Data packet retransmission method and apparatus | |
| EP3613238A1 (en) | Methods and service nodes for transferring a service session for a wireless device | |
| CN110301152B (en) | Monitoring and handling radio line faults in an inactive state | |
| CN113891499A (en) | Method and device for solving inconsistency of user plane states of core network and base station | |
| US20100312848A1 (en) | Method and System for Parallel Call Setup | |
| CN111654480B (en) | RPC connection establishment method, device and storage medium | |
| CN114928592B (en) | User equipment and call restoration method executed by user equipment | |
| WO2022199306A1 (en) | A method of processing an incoming service request by a first network function, nf, instance, as well as the corresponding network functions | |
| WO2021190576A1 (en) | System and method for optimizing pdn synchronization between user equipment and network | |
| US20240323753A1 (en) | Communication method, apparatus, and system | |
| US20240284258A1 (en) | Communication method and apparatus | |
| CN109195183B (en) | Data processing method and device of PDCP layer and base station | |
| EP3613237A1 (en) | Methods and service nodes for transferring a service session for a wireless device between service nodes associated to different base stations | |
| CN116506081A (en) | Service data processing method and device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200609 |