当前位置：网站首页>[ Kitex Source Code Interpretation ] Request to retry

[ Kitex Source Code Interpretation ] Request to retry

2022-08-09 19:02:00 【InfoQ】

Kitex

If you don't know Kitex yet, you can read "

[ CloudWeGo Microservice Practice - 01 ] Opening

If you want to participate in the CloudWeGo community and contribute code to Kitex and other components, you can read

How to contribute to CloudWeGo

CloudWeGo Source Code Interpretation

Kitex is a part of the CloudWeGo Microservice Middleware Collection, and all articles have been summarized into <

CloudWeGo Source Code Interpretation

div>

”.

Request retry

Microservices are different from monolithic architectures in that many RPC calls across services are between different machines.Such an architecture facilitates maintenance, expansion and separate iterations, but at the same time, this architecture also increases instability factors between networks, such as possible hardware problems such as CPU, network, disk, memory, network card, etc., or network jitter and packet loss., delay and other objective reasons will cause the call to fail.

For invocation failures, the microservice framework usually has a certain retry mechanism. There are actually three types of retry in Kitex, which can also be found in the official document "

Request to retry

” found in:

If the connection fails to retry (the framework will retry by default)

Retry on timeout

Backup Request

Retry if the connection fails to be established

The framework will retry by default. See the previous article "

[ Kitex Source Code Interpretation ] FusingHow the mechanism is implemented

"Part of the content about "framework automatic retry".

Timeout retry

A type of error retry, that is, when the client receives a timeout error, it initiates a retry request.

Code examples can refer to

kitex-examples/retry

Note

Confirm that your service is idempotent, and then enable retry

Timeout retry will increase delay

usage

 fp := retry.NewFailurePolicy()
 // optional configuration, the number of retries, default 2, does not include the first request
 fp.WithMaxRetryTimes(xxx)
 // optional configuration, total time, including the first failed request andIf the time required to retry the request reaches the limited duration, subsequent retries will be stopped.
 fp.WithMaxDurationMS(xxx)
 // Close the link and stop (the entire downstream link will be retried normally, there is a risk of retry amplification, please be careful.)
 fp.DisableChainRetryStop()
 // Enable DDL abort
 // This strategy is to judge whether retry is required from the timeout time of the link.
 // Note that Kitex does not have this implementation built-in, you need to register the DDL func through retry.RegisterDDLStop(ddlStopFunc), 
 // Combined with the link timeout judgment, the implementation recommends that the timestamp andTimeout judgment.
 fp.WithDDLStop()
 // Backoff strategy, no backoff strategy by default
 fp.WithFixedBackOff(fixMS int) // Fixed duration backoff
 fp.WithRandomBackOff(minMS int, maxMSint) // random duration backoff
 // enable retry fuse
 fp.WithRetryBreaker(errRate float64)
 // retry on the same node
 fp.WithRetrySameNode()

 cli, err := echo.NewClient(
 "echo",
 client.WithHostPorts("0.0.0.0:8888"),
 client.WithFailureRetry(fp),
 )
 if err != nil {
 log.Fatal(err)
 }
 for {
 req := &api.Request{Message: "my request"}
 resp, err := cli.Echo(context.Background(), req)
 if err != nil {
 log.Fatal(err)
 }
 log.Println(resp)
 time.Sleep(time.Second)
 }

Backup Request

Note

DisableChainRetryStop

Cancel the link suspension, after using this parameter, the entire downstream link will be retried normally

, which may cause retryTry zooming in, please use it carefully according to the situation.

The frame is closed by default

Link abort means that the retry request on the link will not be retried, such as A->B->C, A sends a retry request to B, ifB->C times out or Backup is configured, then B will not send a retry request to C.If the business identifies the retry request by itself, it can directly decide whether to continue the request to C.In short, link suspension prevents B from sending a retry request to C, which leads to retry amplification, and the business's own control can completely avoid the request from B to C.

原网站

版权声明
本文为[InfoQ]所创，转载请带上原文链接，感谢
https://yzsam.com/2022/221/202208091555192450.html