apisix~限流插件的利用

参考：

• https://i4t.com/19399.html
  
• https://github.com/apache/apisix/issues/9193
  
• https://github.com/apache/apisix/issues/9830
  
• https://apisix.apache.org/docs/apisix/plugins/limit-conn/
  
• https://blog.frankel.ch/different-rate-limits-apisix/
  

在 Apache APISIX 中，限流共提供了三种方式，下面说一下

• limit-req 插件利用漏桶算法限制单个客户端对服务的请求速率
  
• limit-conn 插件用于限制客户端对单个服务的并发请求数。当客户端对路由的并发请求数达到限制时，可以返回自定义的状态码和响应信息。
  
• limit-count 件利用固定时间窗口算法，主要用于限制单个客户端在指定的时间范围内对服务的总请求数，并且会在 HTTP 响应头中返回剩余可以请求的个数。该插件原理与 GitHub API 的速率限制雷同
  

请求的限制参数

key_type

• ["var", "var_combination"]
  
• var就是一个变更，不需要加$前缀
  
• var_combination是一组变更的组合，如key为：$http_sub $http_x_forwarded_for
  

key

• ["remote_addr", "server_addr", "http_x_real_ip", "http_x_forwarded_for", "consumer_name"]
  
• 如果限流标识是在请求头里，如请求头是sub，那么key可以配置为http_sub
  
• 
  

var和var_combination范例对应的配置

• var_combination
  

1. "plugins": {
2. "limit-req": {
3.   "burst": 10,
4.   "key": "$consumer_name $remote_addr",
5.   "key_type": "var_combination",
6.   "rate": 2,
7.   "rejected_code": 502
8. }
9. }

复制代码

• var
  

1. "plugins": {
2.     "limit-req": {
3.       "burst": 2,
4.       "key": "remote_addr",
5.       "key_type": "var",
6.       "rate": 3,
7.       "rejected_code": 502
8.      },
9.     "limit-count": {
10.           "allow_degradation": false,
11.           "count": 5,
12.           "key": "http_sub",
13.           "key_type": "var",
14.           "policy": "local",
15.           "rejected_code": 429,
16.           "rejected_msg": "请求太多了",
17.           "show_limit_quota_header": true,
18.           "time_window": 60
19.         }
20. }

复制代码

配置redis

• redis中key的构成plugin-limit-countroute540160115966214871:2389086815:347c9e9e-076c-45e3-be74-c482fffcc6e5
  
  
  
  • plugin-插件名route路由id::limit里的key值
    
  
  
• 单节点
  

1. "plugins": {
2.     "limit-count": {
3.         "count": 2,
4.         "time_window": 60,
5.         "rejected_code": 503,
6.         "key": "remote_addr",
7.         "policy": "redis",
8.         "redis_host": "127.0.0.1",
9.         "redis_port": 6379,
10.         "redis_password": "password",
11.         "redis_database": 1,
12.         "redis_timeout": 1001
13.     }
14. }

复制代码

• 集群模式
  

1. "plugins": {
2.     "limit-count": {
3.         "count": 2,
4.         "time_window": 60,
5.         "rejected_code": 503,
6.         "key": "remote_addr",
7.         "policy": "redis-cluster",
8.         "redis_cluster_nodes": [
9.           "127.0.0.1:5000",
10.           "127.0.0.1:5001"
11.         ]
12.     }
13. }

复制代码

插件的解释

• limit-req
  

1. rate:
2.     含义：每秒允许的请求数量。
3.     示例：rate: 3 表示每个客户端（根据配置的 key）每秒最多可以发送 3 个请求。
5. burst:
6.     含义：突发请求的最大数量。
7.     示例：burst: 2 表示在短时间内，客户端可以突发额外的 2 个请求，即在正常速率为 3 的情况下，可以在某些时刻达到 5 个请求（3 + 2）。

复制代码

• limit-count
  

1. count:
2.     含义：在指定的时间窗口内允许的最大请求次数。
3.     示例：count: 2 表示每个客户端（根据配置的 key）在 time_window 指定的时间段内最多可以发送 2 个请求。
5. time_window:
6.     含义：时间窗口的长度，以秒为单位。
7.     示例：time_window: 60 表示时间窗口为 60 秒。在这 60 秒内，客户端最多可以发送 2 个请求。

复制代码

对redis-key的解释

在 APISIX 中利用 limit-count 插件时，天生的 Redis 键通常包含多个部门，这些部门用来标识具体的限流计谋和相关信息。你提到的键示例是：

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

复制代码

我们可以将这个键分解为几个部门以便理解：
键的构成部门

• plugin-limit-count：
  
  
  
  • 这是固定的前缀，表示该键是由 limit-count 插件天生的。
    
  
  
• route540160115966214871：
  
  
  
  • 这一部门通常表示与特定路由（route）相关的信息。
    
  • 540160115966214871 是路由的唯一标识符（ID），它对应于 APISIX 中配置的某个具体路由。这使得限流计谋能够应用于特定的路由。
    
  
  
• 2389086815：
  
  
  
  • 这一部门通常表示限流的维度或时间窗口的标识符，可能是一个时间戳大概是请求计数的某一部门。
    
  • 具体寄义取决于你的限流配置，比如它可能是用于区分差别时间段内的请求计数。
    
  
  
• 347c9e9e-076c-45e3-be74-c482fffcc6e5：
  
  
  
  • 这一部门一般是用户标识符（如客户端 ID 大概其他唯一标识符），用于在限流计谋中区分差别的用户或客户端。
    
  • 这种计划答应对差别的用户或客户端分别进行限流控制。
    
  
  

总结

整个键的布局是为了确保每个限流实例都是唯一的，并且能够精确地与特定的路由和用户关联。通过这样的计划，APISIX 可以高效地管理和应用限流计谋，以保障系统的稳定性和性能。
redis-count和redis-req的利用场景

漏桶算法（Leaky Bucket）和固定窗口限流（Fixed Window）是两种常见的限流计谋，它们适用于差别的利用场景。以下是这两种限流计谋的特点及其适用场景：
漏桶算法（Leaky Bucket）

特点：

• 平滑输出：漏桶算法答应请求以固定速率被处置惩罚，尽管输入请求可以是不规则的。
  
• 水位限制：桶内有一个容量限制，当达到上限时，多余的请求将被扬弃或拒绝。
  
• 时间耽误：由于请求是以固定速率“漏出”的，因此可能会引入肯定的耽误。
  

利用场景：

• 网络流量控制：得当需要平稳流量输出的场景，如视频流、音频流等。
  
• API调用限制：在需要防止突发流量对后端服务造成影响的情况下，可以利用漏桶算法来均衡请求量。
  
• 实时数据处置惩罚：得当处置惩罚实时数据流的场景，比方消息队列中的消息消耗。
  
• 用户行为限制：比方限制用户在肯定时间内的操纵次数，以防止刷票、刷单等行为。
  

固定窗口限流（Fixed Window）

特点：

• 时间窗口：将时间划分为固定长度的窗口，在每个窗口内答应肯定数量的请求。
  
• 突发性：在窗口开始时，全部请求都可以瞬间进入，但在窗口结束前不会再担当新的请求，直到下一个窗口开始。
  
• 简单易实现：相对其他限流算法，固定窗口的实现较为简单。
  

利用场景：

• 日常访问控制：得当控制用户在特定时间段内的访问频率，比如限制用户每天的登录次数。
  
• API接口调用：用于限制外部系统对内部API的调用频率，确保系统稳定性。
  
• 短时间高并发场景：如电商促销活动期间，可以快速处置惩罚大量请求，但需要限制每个用户的请求频率。
  
• 统计分析：得当进行简单的统计计算，如记录某一时间窗口内的访问量。
  

总结

• 漏桶算法更得当需要平滑流量控制的场景，能够有效防止突发流量造成的系统压力。
  
• 固定窗口限流则得当短时间内的请求控制，简单易用，得当一些对时间窗口要求不严酷的应用。
  

根据具体的业务需求和系统架构，可以选择合适的限流计谋来保障系统的稳定性和可用性。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。