Location>code7788 >text

Use of the apisix~flow-limiting plugin

Popularity：624 ℃/2024-11-14 20:00:24

Reference:

  • /
  • /apache/apisix/issues/9193
  • /apache/apisix/issues/9830
  • /docs/apisix/plugins/limit-conn/
  • /different-rate-limits-apisix/

In Apache APISIX, there are three ways to limit the flow, as described below

  • The limit-req plugin uses a leaky bucket algorithm to limit the rate of requests from a single client to a service
  • The limit-conn plugin is used to limit the number of concurrent client requests to a single service. When the number of concurrent client requests for a route reaches the limit, a customized status code and response message can be returned.
  • The limit-count file uses a fixed time-window algorithm to limit the total number of requests a single client can make to a service within a specified timeframe, and returns the number of remaining requests in the HTTP response header. The plugin works similarly to the GitHub API's rate limiting

Limiting parameters of the request

key_type

  • ["var", "var_combination"]
  • var is just a change without the $ prefix
  • var_combination is a combination of a set of changes such as key for:$http_sub $http_x_forwarded_for

key

  • ["remote_addr", "server_addr", "http_x_real_ip", "http_x_forwarded_for", "consumer_name"]
  • If the flow-limiting identifier is in the request header, e.g., if the request header is sub, then the key can be configured ashttp_sub

Configurations corresponding to var and var_combination types

  • var_combination
"plugins": {
"limit-req": {
  "burst": 10,
  "key": "$consumer_name $remote_addr",
  "key_type": "var_combination",
  "rate": 2,
  "rejected_code": 502
}
}
  • var
"plugins": {
    "limit-req": {
      "burst": 2,
      "key": "remote_addr",
      "key_type": "var",
      "rate": 3,
      "rejected_code": 502
     },
    "limit-count": {
          "allow_degradation": false,
          "count": 5,
          "key": "http_sub",
          "key_type": "var",
          "policy": "local",
          "rejected_code": 429,
          "rejected_msg": "Too many requests.",
          "show_limit_quota_header": true,
          "time_window": 60
        }
}

Configuring redis

  • Composition of keys in redisplugin-limit-countroute540160115966214871:2389086815:347c9e9e-076c-45e3-be74-c482fffcc6e5
    • key value in plugin-plugin-name route route id::limit
  • single node
"plugins": {
    "limit-count": {
        "count": 2,
        "time_window": 60,
        "rejected_code": 503,
        "key": "remote_addr",
        "policy": "redis",
        "redis_host": "127.0.0.1",
        "redis_port": 6379,
        "redis_password": "password",
        "redis_database": 1,
        "redis_timeout": 1001
    }
}
  • clustering mode
"plugins": {
    "limit-count": {
        "count": 2,
        "time_window": 60,
        "rejected_code": 503,
        "key": "remote_addr",
        "policy": "redis-cluster",
        "redis_cluster_nodes": [
          "127.0.0.1:5000",
          "127.0.0.1:5001"
        ]
    }
}

Explanation of plug-ins

  • limit-req
rate.
    Meaning: The number of requests allowed per second.
    Example: rate: 3 means each client (based on the configured key) can send up to 3 requests per second.

burst: Meaning
    Meaning: Maximum number of burst requests.
    Example: burst: 2 means that for a short period of time, the client can burst an additional 2 requests, i.e. with a normal rate of 3, it can reach 5 requests (3 + 2) at some point.
  • limit-count
count.
    Meaning: Maximum number of requests allowed in the specified time window.
    Example: count: 2 means that each client (according to the configured key) can send at most 2 requests within the time_window specified.

time_window.
    Meaning: The length of the time window in seconds.
    Example: time_window: 60 means the time window is 60 seconds. In this 60 seconds, the client can send at most 2 requests.

Explanation of redis-key

Use in APISIXlimit-count When plugging in, the generated Redis key usually contains multiple sections that are used to identify specific flow limiting policies and related information. The example key you mentioned is:

plugin-limit-countroute540160115966214871:2389086815:347c9e9e-076c-45e3-be74-c482fffcc6e5

We can break this key down into parts for understanding:

Key components

  1. plugin-limit-count：

    • This is a fixed prefix that indicates that the key was created by thelimit-count Plugin Generated.

  2. route540160115966214871：

    • This section usually represents information related to a specific route (route).
    • 540160115966214871 is a unique identifier (ID) of a route that corresponds to a specific route configured in APISIX. This allows a flow limiting policy to be applied to a specific route.

  3. 2389086815：

    • This section usually indicates the identifier of the dimension or time window of the flow restriction, which may be a timestamp or a part of the request count.
    • The exact meaning depends on your flow-limiting configuration, for example it may be used to differentiate the count of requests in different time periods.

  4. 347c9e9e-076c-45e3-be74-c482fffcc6e5：

    • This section is typically a user identifier (such as a client ID or other unique identifier) that is used to distinguish between different users or clients in a flow-limiting policy.
    • This design allows separate flow-limiting controls for different users or clients.

summarize

The entire key is structured to ensure that each instance of flow limiting is unique and can be precisely associated with specific routes and users. With this design, APISIX can efficiently manage and apply flow-limiting policies to guarantee system stability and performance.

Usage Scenarios for redis-count and redis-req

Leaky Bucket and Fixed Window are two common flow-limiting strategies, which are applicable to different usage scenarios. The following are the characteristics of these two flow limiting strategies and their application scenarios:

Leaky Bucket.

Features:

  • smooth output: The leaky bucket algorithm allows requests to be processed at a fixed rate, although the input requests can be irregular.
  • water level limit: There is a capacity limit in the bucket, and when the upper limit is reached, excess requests are discarded or rejected.
  • time delay: Since requests are "funneled" at a fixed rate, some latency may be introduced.

Usage Scenarios:

  1. network traffic control: Suitable for scenarios that require smooth traffic output, such as video streaming, audio streaming, etc.
  2. API call restrictions: In the event of the need to preventburst flowThe impact on back-end services can be balanced by using a leaky bucket algorithm to balance the volume of requests.
  3. Real-time data processing: Suitable for scenarios that deal with real-time data streams, such as message consumption in message queues.
  4. User Behavior Restrictions: For example, limiting the number of operations a user can perform within a certain period of time to prevent vote-scrubbing, order-scrubbing, and other behaviors.

Fixed Window Flow Limiting (Fixed Window)

Features:

  • time window: Divide time into fixed-length windows, allowing a certain number of requests within each window.
  • sudden: All requests are instantly accessible at the beginning of the window, but no new requests are accepted until the end of the window, until the next window begins.
  • Easy to implement: Fixed windows are simpler to implement compared to other current limiting algorithms.

Usage Scenarios:

  1. Daily Access Control: Ideal for controlling the frequency of user access during a specific time period, such as limiting the number of times a user can log in per day.
  2. API interface call: Used to limit the frequency of external system calls to internal APIs to ensure system stability.
  3. Short time high concurrency scenario: For example, during e-commerce promotions, a large number of requests can be processed quickly, but the frequency of requests per user needs to be limited.
  4. statistical analysis: Suitable for simple statistical calculations, such as recording the number of visits within a certain time window.

summarize

  • leaky bucket algorithmIt is more suitable for scenarios that require smooth flow control, and can effectively prevent system stress caused by unexpected traffic.
  • Fixed-window flow limitingOn the other hand, it is suitable for short time request control, simple and easy to use, suitable for some applications that do not require strict time window.

According to the specific business requirements and system architecture, you can choose the appropriate flow-limiting strategy to ensure the stability and availability of the system.

<Previous