Analysis of 204 problems reported in circular requests

background

Merchants need to add accessories independently ( Freemarker+JQuery front-end and back-end unseparated items), the batch copy and paste accessories in the additional accessories pop-up window will call the interface for obtaining association words in a loop. If there are many accessory names copied and pasted (20+), only some of the requests are successful (status) Code 200) returns the response body, other requests are successful (status code 204) but no response body is returned.

problem analysis

Comparing the post inquiry page and the additional accessories page, it is found that these three pages have the same problem. Why does it report 204 when calling the interface in a loop? After communicating with the operation and maintenance and architecture, I found that the root cause of this problem is that the gateway layer has more anti-climbing and current limiting processing, because when our system is frequently requested, the system may be overwhelmed. With a gateway, then You can limit the flow in the gateway system, because all requests need to pass through the gateway system before they can be routed to the microservices.

Token bucket algorithm

The token bucket algorithm is one of the more common current limiting algorithms. It is roughly described as follows:

1) All requests need to get a usable token before they can be processed;

2) According to the current limit, set a certain rate to add tokens to the bucket;

3) The bucket sets the maximum token placement limit. When the bucket is full, newly added tokens are discarded or rejected;

4) After the request is reached, the token in the token bucket must be obtained first, and then other business logic can be carried out with the token. After the business logic is processed, the token is directly deleted;

5) The token bucket has a minimum limit. When the token in the bucket reaches the minimum limit, the token will not be deleted after the request is processed, so as to ensure sufficient current limit

As shown below:

In the cass-webagent gateway project, the current limiting configuration is as follows:

icec:
  limiter:
    enabled: true
    pathConfig:
      burstCapacity: 10 #令牌桶的容量，同一个地址允许在一秒钟内完成的最大请求数
      replenishRate: 5 #允许用户每秒处理多少个请求
    routeConfig:
      burstCapacity: 50 #令牌桶的容量，同一个服务允许在一秒钟内完成的最大请求数
      replenishRate: 20 #允许用户每秒处理多少个请求
    customConfigs: #自定义令牌桶的容量
    - name: "path:/agentBuy/decodePartNo"
      config.burstCapacity: 500
    - name: "path:/agentBuy/getFastOEMore"
      config.burstCapacity: 500
    - name: "path:/maindata/llq/getDitchPriceSingle"
      config.burstCapacity: 100
    #- name: "route:web-market"
    #  config.burstCapacity: 51

When the number of user requests exceeds 20 in one second, some of the requests may return 204 ( no content )

solution

1. The front-end controls the number of concurrent requests per second

For example, if a certain amount of request is sent in each time period, and the main thread is blocked by a pseudo-definite loop, the experience will be very bad.

//第一种，使用while循环
function sleep(delay) {
    var start = (new Date()).getTime();
    while((new Date()).getTime() - start < delay) {
        continue;
    }
}

//或者使用for循环
function sleep(delay) {
    for(var t = Date.now(); Date.now() - t <= d;);
}

2. Add customizing certain interface paths in the gateway to allow users to process requests per second, which will increase the pressure on back-end services

3. Change the cyclic call to a batch interface, this is the most thorough solution

Summarize

This article is just an analysis record of this kind of problem, we should avoid this kind of cyclic calling interface scene in the development.