You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ErrRate: 0.3, // requests will be blocked if error rate >= 30%
52
+
MinSample: 200, // this config takes effect if sampled requests are more than `MinSample`
53
+
})
54
+
55
+
// send requests with the client above
56
+
...
53
57
}
58
+
59
+
54
60
```
55
61
56
62
### Introduction
@@ -59,29 +65,24 @@ Kitex provides a set of CBSuite that encapsulates both service-level breaker and
59
65
60
66
- Service-Level Breaker
61
67
62
-
Statistics by service granularity, enabled via WithMiddleware.
63
-
64
-
The specific division of service granularity depends on the Circuit Breaker Key, which is the key for breaker statistics. When initializing the CBSuite, you need to pass it in **GenServiceCBKeyFunc**. The default key is `circuitbreak.RPCInfo2Key`, and the format of RPCInfo2Key is ` fromServiceName/toServiceName/method`.
65
-
68
+
- Statistics by service granularity, enabled via WithMiddleware.
69
+
- The specific service granularity depends on the Circuit Breaker Key, which is the key for breaker statistics. When initializing the CBSuite, you need to pass it in **GenServiceCBKeyFunc**. The default key is `circuitbreak.RPCInfo2Key`, and the format of RPCInfo2Key is `fromServiceName/toServiceName/method`.
66
70
- Instance-Level Breaker
67
71
68
-
Statistics by instance granularity, enabled via WithInstanceMW.
69
-
70
-
Instance-Level Breaker is used to solve the single-instance exception problem. If it's triggered, the framework will automatically retry the request.
71
-
72
-
Note that the premise of retry is that you need to enable breaker with **WithInstanceMW**, which will be executed after load balancing.
73
-
72
+
- Statistics by instance granularity, enabled via WithInstanceMW.
73
+
- Instance-Level Breaker is used to solve the single-instance exception problem. If it’s triggered, the framework will automatically retry the request.
74
+
- Note that the premise of retry is that you need to enable breaker with **WithInstanceMW**, which will be executed after load balancing.
74
75
- Threshold and **Threshold Change**
75
76
76
-
The default breaker threshold is `ErrRate: 0.5, MinSample: 200`, which means it's triggered by an error rate of 50% and requires the count of requests > 200.
77
+
The default breaker threshold is `ErrRate: 0.5, MinSample: 200`, which means it’s triggered by an error rate of 50% and requires the amount of requests > 200.
77
78
78
79
If you want to change the threshold, you can modify the `UpdateServiceCBConfig` and `UpdateInstanceCBConfig` in CBSuite.
79
80
80
81
## The Role of Circuit Breaker
81
82
82
83
When making RPC calls, errors are inevitable for downstream services.
83
84
84
-
When a downstream has a problem, if the upstream continues to make calls to it, it both prevents the downstream from recovering and wastes the upstream's resources.
85
+
When a downstream has a problem, if the upstream continues to make calls to it, it both prevents the downstream from recovering and wastes the upstream’s resources.
85
86
86
87
To solve this problem, you can set up some dynamic switches that manually shut down calls to the downstream when it goes wrong.
87
88
@@ -115,16 +116,15 @@ In general, the transition of the three states is roughly as follows:
115
116
The timeout for cooling
116
117
| v
117
118
+-- detect succeed --<-[HALFOPEN]-->--+
119
+
118
120
```
119
121
120
122
### Trigger Strategies
121
123
122
124
Kitex provides three basic fuse triggering strategies by default:
123
125
124
126
- Number of consecutive errors reaches threshold (ConsecutiveTripFunc)
Of course, you can write your own triggering strategy by implementing the TripFunc function.
@@ -145,9 +145,9 @@ During HALFOPEN, the breaker will let a request go every "interval", and after a
145
145
146
146
The process is a gradual-trial process.
147
147
148
-
Both the "interval" (DetectTimeout) and the "number" (DEFAULT_HALFOPEN_SUCCESSES) are configurable.
148
+
Both the “interval” (DetectTimeout) and the "number" (DEFAULT_HALFOPEN_SUCCESSES) are configurable.
149
149
150
-
## Statistics
150
+
## Statistics Algothrithm
151
151
152
152
### Default Config
153
153
@@ -171,14 +171,12 @@ As time moves, the oldest bucket in the window expires. The jitter occurs when t
171
171
172
172
As an example:
173
173
174
-
- You divide 10 seconds into 10 buckets, bucket 0 corresponds to a time of [0S, 1S), bucket 1 corresponds to [1S, 2S), ... , and bucket 9 corresponds to [9S, 10S).
175
-
174
+
- You divide 10 seconds into 10 buckets, bucket 0 corresponds to a time of [0S, 1S), bucket 1 corresponds to [1S, 2S), … , and bucket 9 corresponds to [9S, 10S).
176
175
- At 10.1S, a Succ is executed, and the following operations occur within the circuitbreaker.
177
176
178
-
- (1) detects that bucket 0 has expired and discards it;
179
-
- (2) creates a new bucket 10, corresponding to [10S, 11S);
180
-
- (3) puts that Succ into bucket 10.
181
-
177
+
- (1) detects that bucket 0 has expired and discards it;
178
+
- (2) creates a new bucket 10, corresponding to [10S, 11S);
179
+
- (3) puts that Succ into bucket 10.
182
180
- At 10.2S, you execute Successes() to query the number of successes in the window, then you get the actual statistics for [1S, 10.2S), not [0.2S, 10.2S).
183
181
184
182
Such jitter cannot be avoided if you use time-window-bucket statistics. A compromise approach is to increase the number of buckets, which can reduce the impact of jitter.
0 commit comments