Sentinel flow control rules

Sentinel mainly uses traffic as the entry point to help you protect the stability of your service from multiple dimensions such as flow control, circuit breaker degradation, and system load protection. One of its jobs is flow control, so we need Understand and master flow control rules. (This is a compilation of my study notes on flow control rules)

What is flow control?

  • Flow control, which is used to adjust the sending data of network packets. However, from the perspective of system stability, requests arriving at any time are random and uncontrollable, and the system’s processing capacity is limited. We need to control the flow based on the system’s processing capabilities.
  • Its principle is to monitor indicators such as QPS or the number of concurrent threads of application traffic, and control the traffic when it reaches a specified threshold to avoid being overwhelmed by instantaneous traffic peaks, thus ensuring the high availability of applications.
  • There are two main types of statistics for flow control, one is to count the number of concurrent threads, and the other is to count QPS.

Sentinel’s noun explanation for flow control:

  • Resource name: unique name, default request path
  • For resources: sentinel can limit the current flow for the caller, fill in the microservice name, and default (does not distinguish the source)
  • Threshold type/single machine threshold:
  • QPS (number of requests per second): When the QPS of calling the API reaches the threshold, the current will be limited.
  • Number of threads: When the number of threads calling the API reaches the threshold, the current will be limited.
  • Whether to cluster: No cluster required
  • Traffic pattern:
  • Direct: When the api reaches the current limiting condition, the current will be limited directly.
  • Association: When the associated resource reaches the threshold, it will limit its own flow.
  • Link: Only record the traffic on the specified link (the traffic coming from the entrance resource of the specified resource, if it reaches the threshold, the flow will be limited) [Api level source]
  • Flow control effect:
  • Fail fast: fail directly and throw an exception
  • Warm Up: According to the value of codeFactor (cold load factor, default 3), the set QPS threshold is reached after the warm-up time from threshold/codeFactor
  • Queuing and waiting: queue at a uniform speed, allowing requests to pass at a uniform speed. The threshold type must be set to QPS, otherwise it will fail.

Sentinel flow control

1. An attempt at Sentinel-QPS-direct-fast failure (system default Blocked by Sentinel (flow limiting)):

Test results:

When we quickly click to visit
http://localhost:8401/testA, no more than once per second, normal access

If accessed more than once per second, it will directly fail and prompt

2. Try Sentinel-number of threads-direct-fast failure (system default Blocked by Sentinel (flow limiting)):

Test results:

According to Sentinel’s noun explanation for flow control: Number of threads: When the number of threads calling the API reaches the threshold, the flow will be limited.

We set the threshold here to 1. In order to make it easier for us to observe, we modify the code of TestA (when accessing on the browser, stay for two seconds):

 @GetMapping("/testA")
    public String testA(){
        try {
           TimeUnit.MILLISECONDS.sleep(Long.parseLong("2000"));
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "-----testA";
    }

If you send two requests using the same browser, one of them will fail directly.

3. For Sentinel-QPS- Association – fast-fail (system default Blocked by Sentinel (flow limiting)) attempts:

Test results:

What this means here is thatwhen the QPS of testB reaches the threshold 1, A will hang up and limit the current. That is, in reality, when the payment interface cannot withstand the threshold and reaches the threshold, the order interface associated with it does not need to be used. , restricting its flow

4. For Sentinel-QPS- Direct-Warm Up (system default Blocked by Sentinel (flow limiting)) attempt:

Test results:

My understanding of this case: For the flow control effect Warm Up, in reality, I am afraid that the flow rate is obviously 0 or very low, and suddenly surges to an extremely high number, which may overwhelm the system. Through preheating, that is, “cold start”, the traffic is slowly increased and returned to the set QPS threshold within a certain period of time. That is, according to the Warm Up preheating formula, it is slowly increased from (initialization threshold –> to normal QPS threshold), the initial initialization threshold is (QPS setting threshold/cold load factor default 3)

5. Attempts to Sentinel-QPS-direct-queuing (system default is (Blocked by Sentinel (flow limiting)):

Test results:

  • No matter how many concurrent requests there are, I set the current limit rule to wait in line, so they have to be processed one by one, and the others are queued behind.
  • Uniform queuing allows requests to pass at a uniform speed. The threshold type must be set to QPS, otherwise it will be invalid.
  • Setting meaning: /TestB requests once per second. If it exceeds, it will queue up and wait. The waiting timeout is 20000 milliseconds. The purpose is to process requests at a uniform speed and ensure the uniformity of the service, rather than processing a large number of requests at once. There are no requests to process. .

Modify the code here:

    @GetMapping("/testB")
    public String testB(){
        log.info("test" + Thread.currentThread().getName() + "testB");
        return "-----testB";
    }

Open Postman

Conclusion of Sentinel flow control rules:

Here I mainly show the QPS flow control based on QPS/concurrency flow control in the flow control. One thought to answer here is the system default Blocked by Sentinel (flow limiting) error message displayed when a rapid failure occurs. Our subsequent processing There is a fallback method.