Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to solve the problem of Dubbo retries overtime retry mechanism". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to solve the problem of Dubbo retries overtime retry mechanism.

Exception log

[com.alibaba.dubbo.rpc.filter.TimeoutFilter]-[DUBBO] invoke time out. Method: sendMessagearguments: [{* content *}], url is dubbo://*.*:20882/cn.demo.api.IDemoProviderApi?anyhost=true&application=demo&dubbo=2.8.4&generic=false&interface=cn.demo.api.IDemoProviderApi&methods=sendMessage,resetSendCount&pid=13008&revision=0.0.1-SNAPSHOT&side=provider&timeout=6000 × tamp=1521449123489&version=1.0, invoke elapsed 10863 ms., dubbo version: 2.8.4, current host: 127.0.0.1

Abnormal cause

Dubbo service provider, exposed through annotations, the parameters are set as follows:

@ Service (version = "1.0", timeout = 6000)

The consumer invokes the dubbo service and the request times out, and the dubbo service has a timeout retry mechanism, so there will be three calls to the submitted business.

Solution

Modify the dubbo service provider. Set the timeout timeout to 20000ms. Or set retries= "0". Disable the timeout retry mechanism.

Xml mode (consumer side):

Annotation method (provider):

@ Service (version = "1. 0", timeout = 20000) Dubbo timeout retry mechanism

1. The request service timed out, but the final program was executed 3 times. For the business of submitting an order, only one new order can be added, which is not allowed.

2. Dubbo:provider can set the timeout timout and the number of times it is reconnected if the timeout is allowed.

3. Dubbo:reference can set the timeout, and if the timeout timout, allow the number of times to reconnect to the service retries; if the server has set retries, the consumer can not set this parameter.

4. The default value of dubbo:reference retries is the same as that of consumer, while consumer defaults to 2 times.

Dubbo:consumer

Retries

Default.retries

Int

Optional

two

#-the following is reproduced-

1. Timeout setting

The timeout time set by the DUBBO consumer needs to be set according to the actual business situation.

If the setting time is too short, some complex businesses will take a long time to complete, resulting in the normal business processing cannot be completed within the set timeout period.

In this way, if the consumer reaches the timeout, dubbo will retry the mechanism. Unreasonable retry may cause many problems in some special business scenarios, so you need to set the API timeout reasonably.

For example, if you send an email, multiple duplicate emails may be sent, and multiple duplicate registration data will be inserted when the registration request is executed.

(1) the idea of reasonable allocation of timeout and reconnection.

1. For the core service center, remove the dubbo timeout retry mechanism and re-evaluate the setting timeout.

two。 The business processing code must be placed on the server side, and the client only does parameter verification and service invocation, and does not involve business process processing.

(2) Dubbo timeout and reconnection configuration example

two。 Reconnection mechanism

When dubbo invokes the service unsuccessfully, it retries 2 times by default.

Dubbo's routing mechanism will route timed-out requests to other machines instead of local attempts, so dubbo's retry machine can also guarantee the quality of service to a certain extent.

However, if the number of retries is not reasonably configured, it will be retried many times when it fails, so that there will be a performance problem at a certain point in time, and the caller will call again and again.

When the system request becomes retries times of the normal value, the system pressure will increase greatly, which can easily cause service avalanche. You need to plan how to handle the exception and when to retry according to the business situation.

Add: dubbo RPC cannot directly pass array types as described below.

Today, I encountered a big pit. A RPC interface is provided to check the Redis data in batches. Due to the uncertain data type, map is used as the return type. One of the checked result sets is an array type, and the code does not report a problem, but it has been RPC exception all the time. All kinds of shit attempts to troubleshoot and finally locate the problem.

The simplest solution is to convert all value to String types.

Visual observation is that dubbo serialization does not allow you to pass array types directly, which will be examined later.

At this point, I believe you have a deeper understanding of "how to solve the problem of Dubbo retries timeout retry mechanism". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.