SpringCloud Alibaba - Sentinel current limiting rules (case + JMeter test analysis)

In SpringMVC, the request is first routed to the corresponding method in the Controller, then the method in the Service is called in the method, and finally the corresponding Mapper interface is called. This process is a calling link.

Each interface monitored in the link is a resource (RequestMapping is resource routing). By default, each endpoint of SpringMVC is monitored (that is, each resource in the Controller), so each endpoint in SpringMVC is a call chain. a resource in .

Traffic flow, fuses, etc. are all set for the resources in the cluster point link.

1.2. Flow control mode

1.2.1. Direct flow control mode

After accessing /order/{orderId}, open the Sentinle console and select "Cluster Point Link" to see the picture below.

Click the flow control button behind the resource/order/{orderId}, and a form will pop up, after which you can add flow limiting rules.

Here we first take a look at the direct flow control mode (after opening the advanced options, you can see that it is selected by default)

For the source: The default is default, which is valid for all requests. Generally, no modifications are made here.
Threshold type: Just use qps here, which is the maximum number of requests processed per second.
Single machine threshold: Set the maximum number of requests processed per second.
Traffic mode: There are three types here. Currently, we will look at the first one, which is to count the current resource requests. If it exceeds the single-machine threshold, the flow will be limited.
Flow control effect: Fast failure is the default, which means that after reaching the threshold, new requests will be immediately rejected and a FlowException will be thrown.

Here the single-machine threshold is set to 5.

Then use the JMeter test tool to send 10 requests per second, lasting a total of 2s.

Set up HTTP request

Start the script and observe the running results. You can see that almost every 5 items succeed and 5 items fail.

You can observe the passing and rejecting status of QPS in Sentinel.

1.2.2. Associated flow control mode

Association mode: used to count another resource related to the current resource. When the threshold is triggered, the current resource is limited.

For example, if you buy something on Taobao, after completing the payment, you will modify the order status. At the same time, you will also check the order, but the query and modification will compete for the lock of the database, creating competition. According to the business needs, , the update order business is given priority, and then the user query business is carried out. Therefore, when the order business trigger threshold is modified, the query order business needs to be limited.

It can be seen that the applicable scenarios of associated flow control mode meet the following conditions:

The two resources are in competition.
One has high priority and one has low priority.

Here is a case to demonstrate: Create two endpoints in OrderController, /order/query and /order/update, without implementing the business, and then configure the flow control rules. When the QPS accessed to the /order/update resource exceeds 5, the /order/query request current limit.

The specific implementation steps are as follows:

a) Create two new endpoints in OrderController.

Create /order/query and /order/update endpoints.

    @RequestMapping("/query")
    public String queryOrder() {
        return "订单查询成功！";
    }

    @RequestMapping("update")
    public String updateOrder() {
        return "订单修改成功！";
    }

b) Perform flow control on the order query endpoint in the Sentinel console

Set the single-machine threshold to 5, select "Association" as the flow control mode, and the associated resource is /order/update.

In other words , when /order/update reaches the threshold, sending an /order/query request will throw an exception.

c) Test using JMeter

Set to send 10 requests per second, for a total of 1,000 requests.

Just send a request to /order/update here.

d) Analysis results

While JMeter is running, if you manually send an /order/query request, you will find that the request fails.

This is because /order/update has exceeded the threshold at this time. If the /order/query request is sent again at this time, the total number of the two requests must also exceed the threshold. Therefore, the "flow control effect" is set to fail quickly. , so an exception is thrown here.

1.2.3. Link flow control mode

Link mode: Only statistics are made on requests that access the current specified resource from the specified link. If the threshold is exceeded, the current link will be flow-limited.

For example, there are currently two request links:

/test1 -> /tools
/test2 -> /tools

If you only want to count the requests entering /tools from /test2, then once the threshold is exceeded (assuming the threshold is 5), only this line will be flow-limited, you can configure the following:

Here is a case to demonstrate: The existing inquiry order and creation order business both need to query the product business. The demand refers to counting the requests for query order -> querying the product and setting the flow control (threshold is 2).

The specific implementation steps are as follows:

a) Add the queryGoods method in OrderService (no need to implement business).

Used to represent the query product business that must be accessed by both query order and create order businesses.

    @SentinelResource("goods") //设置资源名称
    public void queryGoods() {
        //使用 err 是为了高亮显示，方便观察日志信息
        System.err.println("查询订单成功！");
    }

Notice! ! !

1. The default value of Sentinel only marks the methods in the Controller as resources. If you want to mark other methods, you need to use the @SentinelResource annotation to identify the resource name.

2. Plus! By default, Sentinel only integrates the context of methods in the Controller, which causes the link mode flow control to fail. The following configuration needs to be added to application.yml:

spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合

Triggering two endpoints, you can see that in the "cluster point link", goods is a sub-resource of the two endpoint resources, as follows

b) Create two endpoints in OrderController, namely /order/query and /order/save

Both endpoints need to call the queryGoods method in the Order Service.

    @RequestMapping("/query")
    public String queryOrder() {
        orderService.queryGoods();
        return "订单查询成功！";
    }

    @RequestMapping("/save")
    public String saveOrder() {
        orderService.queryGoods();
        return "保存订单成功！";
    }

c) Set current limiting rules for queryGoods

Limit the flow of the link from /order/query -> queryGoods, with a threshold of 2.

d) Test using JMeter

Sending 4 requests per second using JMeter to both endpoints.

You can see that all requests in the link /order/save -> goods were successful.

The link /order/query -> goods is restricted by the flow control mode.

You can also see the qps rejection situation of goods on the console (2 out of every 8 qps are rejected, and the ones rejected are requests that exceed the threshold on the /order/query link).

1.3. Flow control effect

1.3.1. Fast failure

Fast failure: After reaching the threshold, new requests will be rejected immediately and a FlowException exception will be thrown. This is the default processing method.

This method is used to achieve this effect in the demonstration flow control mode, so I won’t go into details here.

1.3.2、warm up

Warm up: Warm-up mode. Requests that exceed the threshold are also rejected and exceptions are thrown. However, the threshold in this mode will change dynamically, gradually increasing from a relatively small value to the set maximum threshold (the warm-up time here is need to be set).

The initial value of the request threshold is the set maximum threshold/coldFactor, and the default value of coldFactor is 3.

For example, if I set the maximum threshold of qps to 10 and the warm-up time to 5 seconds, then the initial threshold is 10 / 3, which after rounding is 3, and then gradually increases to 10 after 5 seconds.

Here I will demonstrate through a case: set the current limit for the resource /order/{orderId}, the maximum qps is 10, use the warm up effect, and the warm-up time is 5 seconds.

Specific steps are as follows:

a) Set current limiting rules

b) Use JMeter for testing

c) Analysis results

As you can see in the console, the initial qps pass only passed 3 (obtained after the initial threshold calculation), which is in line with expectations. Within 5 seconds, the number of qps passes gradually increased until the number of qps passes = 10 and then stabilized.

1.3.3. Waiting in line

In this method of queuing and waiting, when the request exceeds the qps threshold, an exception will not be thrown directly. Instead, the extra requests will first enter a queue for queuing, and then be executed sequentially according to the time interval allowed by the threshold. If all requests in the queue are The sum of the request processing times is exactly equal to the waiting time, then the new request at this time will be rejected.

For example, setting qps = 5 means that a request in the queue will be processed every 200ms. If the timeout is set to 2000ms, it means that if there are 10 requests in the queue, the time will be full. At this time, if a new request comes , will be rejected.

Here is a case to demonstrate: set the current limit for the resource /order/{orderId}, the maximum qps is 10, use the flow control effect of queuing, and set the timeout to 5s.

a) Configure flow control rules

b) Use JMeter for testing

c) Analysis results

When it is time to start, all the requests are processed successfully because the newly added requests will enter the queue first, and the request at the head of the queue is also processed.

Later, because the speed of requests was greater than the speed of queue processing, the queue would eventually fill up within the timeout period, so QPS was rejected.

After the final request is sent, the queue will continue to process the request and the timeout will not be exceeded, so the final qps are all passed.

1.3.4. Hotspot parameter current limiting

The previous current limiting was to count all requests to access a resource to determine whether it exceeded the qps threshold, while the hotspot parameter current limiting was to count requests with the same parameter value to determine whether it exceeded the qps threshold.

For example, if we make statistics on parameter No. 0 (the first parameter) of the hot resource, the number of requests for the same parameter per second cannot exceed 5, as shown below.

In addition, in the advanced options of hotspot parameter current limiting, you can also impose additional restrictions on some parameters.

Parameter type: What data type is the parameter pointed to by the parameter index (only Java data types are supported).

Parameter value: The parameter value passed in.

Current limiting threshold: the maximum threshold of qps within the window duration.

For example, if the parameter value is 100, the allowed qps per second is 10, as shown below.

Here I use a case to demonstrate: add hotspot parameter current limit to the resource /order/{orderId}, the rules are as follows:

The default hotspot parameter rule is that the number of requests per 1 second does not exceed 2.
Set an exception for this parameter 102: the number of requests per 1 second does not exceed 4.
Set an exception for the 103 parameter: the number of requests per 1 second does not exceed 10.

The specific implementation steps are as follows:

a) Add the @SentinelResource annotation to the hotspot parameter current limiting object

Note: Hotspot parameter current limiting is invalid for the default SpringMVC resource, so you need to add @SentinelResource to specify the resource and name it.

    @SentinelResource("hot")
    @GetMapping("{orderId}")
    public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
        // 根据id查询订单并返回
        return orderService.queryOrderById(orderId);
    }

b) Configure current limiting rules

c) Use JMeter for testing

There are three sending paths, as follows:

d) Analyze test results

You can see the request 101. According to the default current limiting rule, qps = 2, as follows.

102 For this request, according to the advanced settings, the exception configuration is qps = 4, as follows.

103 For this request, according to the advanced settings, the exception configuration is qps = 10. Because the number of requests per second is 5, all requests pass.

It can also be seen in the hot resource monitoring, 11 every time, and 4 rejected.

This is because only 2 of the 101 request default rules passed, plus 4 of the 102 request exception settings, plus 5 of the 103 request exception settings, the total of which was successful was 11.