nginx 전류 제한 모듈 소스 코드 분석

고동시성 시스템에는 캐싱, 다운그레이드 및 전류 제한의 세 가지 무기가 있습니다.

전류 제한의 목적은 동시 액세스/요청 속도를 제한하여 시스템을 보호하는 것입니다. 거부됨(오류 페이지로 이동), 대기 중(빠른 종료), 다운그레이드(상향식 데이터 또는 기본 데이터로 돌아가기)

고동시성 시스템의 일반적인 현재 제한은 다음과 같습니다. 총 동시성 수 제한(데이터베이스) 연결 풀), 순간 동시성 수 제한(예: nginx의limit_conn 모듈, 순간 동시 연결 수를 제한하는 데 사용됨), 시간 창 내 평균 속도 제한(nginx의 Limit_req 모듈, 초당 평균 속도를 제한하는 데 사용됨)

또한 네트워크 연결 수, 네트워크 트래픽, CPU 또는 메모리 로드 등에 따라 흐름을 제한할 수도 있습니다.

1. 전류 제한 알고리즘

가장 간단하고 조잡한 전류 제한 알고리즘은 카운터 방법이며, 가장 일반적으로 사용되는 방법은 누출 버킷 알고리즘과 토큰 버킷 알고리즘입니다. 방법은 전류 제한입니다. 구현하기 가장 간단하고 쉬운 알고리즘입니다. 예를 들어 인터페이스 a의 경우 1분당 액세스 횟수가 100회를 초과할 수 없다고 규정합니다.

그런 다음 유효한 시간이 1분인 카운터 카운터를 설정할 수 있습니다(즉, 카운터는 매분 0으로 재설정됩니다). 요청이 올 때마다 카운터는 1씩 증가합니다. 100보다 크면 요청이 너무 많다는 뜻입니다. 이 알고리즘은 간단하지만 매우 치명적인 문제, 즉 중요도 문제를 안고 있습니다.

아래 그림과 같이 1시 이전 순간에 100개의 요청이 도착하고 1시 카운터가 재설정되며 1시 이후 순간에 100개의 요청이 도착하며 당연히 카운터는 100을 초과하지 않습니다. 요청은 차단되지 않습니다.

그러나 이 기간 동안 요청 횟수는 100을 훨씬 초과하는 200에 도달했습니다.

1.2 Leaky Bucket Algorithm

아래 그림과 같이 용량이 고정된 Leaky Bucket이 있고, 물통이 비어 있으면 물방울이 일정한 속도로 흘러나오며, 물통이 비어 있으면 물방울이 떨어지지 않습니다. 물 흐름 속도는 임의적입니다. 유입되는 물이 버킷의 용량을 초과하면 유입되는 물이 넘치게 됩니다(폐기됨).

누출 버킷 알고리즘은 본질적으로 요청 속도를 제한하고 트래픽 형성 및 제한에 사용됩니다.

1.3 토큰 버킷 알고리즘

토큰 버킷은 고정된 용량의 토큰을 버킷에 추가합니다. 버킷이 가득 차면 새로 추가된 토큰이 삭제됩니다.

요청이 도착하면 버킷에서 토큰을 가져오려고 시도합니다. 요청하지 않으면 줄을 서거나 직접 폐기합니다. 예 누출 버킷 알고리즘의 유출 속도는 일정하거나 0인 반면 토큰 버킷 알고리즘의 유출 속도는 r보다 클 수 있습니다.

2. nginx에 대한 기본 지식

nginx에는 주로 두 가지 전류 제한 방법이 있습니다. 연결 수로 전류 제한(ngx_http_limit_conn_module), 요청 속도로 전류 제한(ngx_http_limit_req_module)

현재 제한 모듈을 배우기 전에, 또한 nginx의 http 요청 처리, nginx 이벤트 처리 등을 이해해야 합니다.

2.1 http 요청 처리

nginx는 http 요청 처리 프로세스를 11단계로 나눕니다. 단계(그 중 4개는 사용자 정의 핸들러를 추가할 수 없음) nginx가 http 요청을 하나씩 추가합니다. 모든 핸들러를 호출합니다.

typedef enum {
 ngx_http_post_read_phase = 0, //目前只有realip模块会注册handler（nginx作为代理服务器时有用，后端以此获取客户端原始ip）
 
 ngx_http_server_rewrite_phase, //server块中配置了rewrite指令，重写url
 
 ngx_http_find_config_phase, //查找匹配location；不能自定义handler；
 ngx_http_rewrite_phase,  //location块中配置了rewrite指令，重写url
 ngx_http_post_rewrite_phase, //检查是否发生了url重写，如果有，重新回到find_config阶段；不能自定义handler；
 
 ngx_http_preaccess_phase,  //访问控制，限流模块会注册handler到此阶段
 
 ngx_http_access_phase,  //访问权限控制
 ngx_http_post_access_phase, //根据访问权限控制阶段做相应处理；不能自定义handler；
 
 ngx_http_try_files_phase,  //只有配置了try_files指令，才会有此阶段；不能自定义handler；
 ngx_http_content_phase,  //内容产生阶段，返回响应给客户端
 
 ngx_http_log_phase   //日志记录
} ngx_http_phases;

nginx는 ngx_module_s 구조를 사용하여 모듈을 나타냅니다. 여기서 필드는 ctx입니다. 모듈 컨텍스트 구조는 다음과 같습니다(컨텍스트 구조의 필드는 모두 함수 포인터입니다):

typedef struct {
 ngx_int_t (*preconfiguration)(ngx_conf_t *cf);
 ngx_int_t (*postconfiguration)(ngx_conf_t *cf); //此方法注册handler到相应阶段
 
 void  *(*create_main_conf)(ngx_conf_t *cf); //http块中的主配置
 char  *(*init_main_conf)(ngx_conf_t *cf, void *conf);
 
 void  *(*create_srv_conf)(ngx_conf_t *cf); //server配置
 char  *(*merge_srv_conf)(ngx_conf_t *cf, void *prev, void *conf);
 
 void  *(*create_loc_conf)(ngx_conf_t *cf); //location配置
 char  *(*merge_loc_conf)(ngx_conf_t *cf, void *prev, void *conf);
} ngx_http_module_t;

ngx_http_limit_req_module 모듈을 예로 들면, 사후 구성 방법은 다음과 같이 간단하게 구현됩니다. 2.2 nginx 이벤트 처리에 대한 간략한 소개

nginx가 epoll을 사용한다고 가정합니다.

nginx는 epoll에 관심 있는 모든 fd를 등록하고 다음과 같이 메소드 수명을 추가해야 합니다.

static ngx_int_t ngx_http_limit_req_init(ngx_conf_t *cf)
{
 h = ngx_array_push(&cmcf->phases[ngx_http_preaccess_phase].handlers);
 
 *h = ngx_http_limit_req_handler; //ngx_http_limit_req_module模块的限流方法；nginx处理http请求时，都会调用此方法判断应该继续执行还是拒绝请求
 
 return ngx_ok;
}

메소드의 첫 번째 매개변수는 nginx가 관심 있는 읽기 또는 쓰기 이벤트를 나타내는 ngx_event_t 구조 포인터입니다. 이벤트에 대한 시간 초과 설정 장치는 이벤트 시간 초과 상황을 처리할 수 있습니다. 정의는 다음과 같습니다.

static ngx_int_t ngx_epoll_add_event(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);

일반적으로 epoll_wait는 모든 fd를 모니터링하고 발생하는 읽기 및 쓰기 이벤트를 처리하기 위해 주기적으로 호출됩니다. 마지막 매개변수 timeout은 타임아웃 시간, 즉 여전히 이벤트가 발생하지 않는 경우 최대 차단 타임아웃 시간입니다.

타임아웃 타임아웃을 설정할 때 nginx는 최근에 만료될 노드를 검색합니다. 위에서 언급한 타임아웃 타이머를 기록하는 레드-블랙 트리는 다음과 같이 epoll_wait의 타임아웃 시간으로 사용됩니다. 위 코드에서 볼 수 있듯이

struct ngx_event_s {
 
 ngx_event_handler_pt handler; //函数指针：事件的处理函数
 
 ngx_rbtree_node_t timer;  //超时定时器，存储在红黑树中（节点的key即为事件的超时时间）
 
 unsigned   timedout:1; //记录事件是否超时
 
};

동시에, 각 사이클이 끝날 때마다 nginx가 확인합니다. 레드-블랙 트리에서 이벤트가 만료되었는지 여부. 만료된 경우 timeout=1로 표시하고 이벤트 핸들러를 호출합니다.

void ngx_event_expire_timers(void)
{
 for ( ;; ) {
  node = ngx_rbtree_min(root, sentinel);
 
  if ((ngx_msec_int_t) (node->key - ngx_current_msec) <= 0) { //当前事件已经超时
   ev = (ngx_event_t *) ((char *) node - offsetof(ngx_event_t, timer));
 
   ev->timedout = 1;
 
   ev->handler(ev);
 
   continue;
  }
 
  break;
 }
}

nginx就是通过上面的方法实现了socket事件的处理，定时事件的处理；

ngx_http_limit_req_module模块解析

ngx_http_limit_req_module模块是对请求进行限流，即限制某一时间段内用户的请求速率；且使用的是令牌桶算法；

3.1配置指令

ngx_http_limit_req_module模块提供一下配置指令，供用户配置限流策略

//每个配置指令主要包含两个字段：名称，解析配置的处理方法
static ngx_command_t ngx_http_limit_req_commands[] = {
 
 //一般用法：limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
 //$binary_remote_addr表示远程客户端ip；
 //zone配置一个存储空间（需要分配空间记录每个客户端的访问速率，超时空间限制使用lru算法淘汰；注意此空间是在共享内存分配的，所有worker进程都能访问）
 //rate表示限制速率，此例为1qps
 { ngx_string("limit_req_zone"),
  ngx_http_limit_req_zone,
  },
 
 //用法：limit_req zone=one burst=5 nodelay;
 //zone指定使用哪一个共享空间
 //超出此速率的请求是直接丢弃吗？burst配置用于处理突发流量，表示最大排队请求数目，当客户端请求速率超过限流速率时，请求会排队等待；而超出burst的才会被直接拒绝；
 //nodelay必须与burst一起使用；此时排队等待的请求会被优先处理；否则假如这些请求依然按照限流速度处理，可能等到服务器处理完成后，客户端早已超时
 { ngx_string("limit_req"),
  ngx_http_limit_req,
  },
 
 //当请求被限流时，日志记录级别；用法：limit_req_log_level info | notice | warn | error;
 { ngx_string("limit_req_log_level"),
  ngx_conf_set_enum_slot,
  },
 
 //当请求被限流时，给客户端返回的状态码；用法：limit_req_status 503
 { ngx_string("limit_req_status"),
  ngx_conf_set_num_slot,
 },
};

注意：$binary_remote_addr是nginx提供的变量，用户在配置文件中可以直接使用；nginx还提供了许多变量，在ngx_http_variable.c文件中查找ngx_http_core_variables数组即可：

static ngx_http_variable_t ngx_http_core_variables[] = {
 
 { ngx_string("http_host"), null, ngx_http_variable_header,
  offsetof(ngx_http_request_t, headers_in.host), 0, 0 },
 
 { ngx_string("http_user_agent"), null, ngx_http_variable_header,
  offsetof(ngx_http_request_t, headers_in.user_agent), 0, 0 },
 …………
}

3.2源码解析

ngx_http_limit_req_module在postconfiguration过程会注册ngx_http_limit_req_handler方法到http处理的ngx_http_preaccess_phase阶段；

ngx_http_limit_req_handler会执行漏桶算法，判断是否超出配置的限流速率，从而进行丢弃或者排队或者通过；

当用户第一次请求时，会新增一条记录（主要记录访问计数、访问时间），以客户端ip地址（配置$binary_remote_addr）的hash值作为key存储在红黑树中（快速查找），同时存储在lru队列中（存储空间不够时，淘汰记录，每次都是从尾部删除）；当用户再次请求时，会从红黑树中查找这条记录并更新，同时移动记录到lru队列首部；

3.2.1数据结构

limit_req_zone配置限流算法所需的存储空间（名称及大小），限流速度，限流变量（客户端ip等），结构如下：

typedef struct {
 ngx_http_limit_req_shctx_t *sh;
 ngx_slab_pool_t    *shpool;//内存池
 ngx_uint_t     rate; //限流速度（qps乘以1000存储）
 ngx_int_t     index; //变量索引（nginx提供了一系列变量，用户配置的限流变量索引）
 ngx_str_t     var; //限流变量名称
 ngx_http_limit_req_node_t *node;
} ngx_http_limit_req_ctx_t;
 
//同时会初始化共享存储空间
struct ngx_shm_zone_s {
 void      *data; //data指向ngx_http_limit_req_ctx_t结构
 ngx_shm_t     shm; //共享空间
 ngx_shm_zone_init_pt  init; //初始化方法函数指针
 void      *tag; //指向ngx_http_limit_req_module结构体
};

limit_req配置限流使用的存储空间，排队队列大小，是否紧急处理，结构如下：

typedef struct {
 ngx_shm_zone_t    *shm_zone; //共享存储空间
  
 ngx_uint_t     burst;  //队列大小
 ngx_uint_t     nodelay; //有请求排队时是否紧急处理，与burst配合使用（如果配置，则会紧急处理排队请求，否则依然按照限流速度处理）
} ngx_http_limit_req_limit_t;

前面说过用户访问记录会同时存储在红黑树与lru队列中，结构如下：

//记录结构体
typedef struct {
 u_char      color;
 u_char      dummy;
 u_short      len; //数据长度
 ngx_queue_t     queue; 
 ngx_msec_t     last; //上次访问时间
  
 ngx_uint_t     excess; //当前剩余待处理的请求数（nginx用此实现令牌桶限流算法）
 ngx_uint_t     count; //此类记录请求的总数
 u_char      data[1];//数据内容（先按照key（hash值）查找，再比较数据内容是否相等）
} ngx_http_limit_req_node_t;
 
//红黑树节点，key为用户配置限流变量的hash值；
struct ngx_rbtree_node_s {
 ngx_rbtree_key_t  key;
 ngx_rbtree_node_t  *left;
 ngx_rbtree_node_t  *right;
 ngx_rbtree_node_t  *parent;
 u_char     color;
 u_char     data;
};
 
 
typedef struct {
 ngx_rbtree_t     rbtree; //红黑树
 ngx_rbtree_node_t    sentinel; //nil节点
 ngx_queue_t     queue; //lru队列
} ngx_http_limit_req_shctx_t;
 
//队列只有prev和next指针
struct ngx_queue_s {
 ngx_queue_t *prev;
 ngx_queue_t *next;
};

思考1：ngx_http_limit_req_node_t记录通过prev和next指针形成双向链表，实现lru队列；最新访问的节点总会被插入链表头部，淘汰时从尾部删除节点；

ngx_http_limit_req_ctx_t *ctx;
ngx_queue_t    *q;
 
q = ngx_queue_last(&ctx->sh->queue);
 
lr = ngx_queue_data(q, ngx_http_limit_req_node_t, queue);//此方法由ngx_queue_t获取ngx_http_limit_req_node_t结构首地址，实现如下：
 
#define ngx_queue_data(q, type, link) (type *) ((u_char *) q - offsetof(type, link)) //queue字段地址减去其在结构体中偏移，为结构体首地址

思考2：限流算法首先使用key查找红黑树节点，从而找到对应的记录，红黑树节点如何与记录ngx_http_limit_req_node_t结构关联起来呢？在ngx_http_limit_req_module模块可以找到以代码：

size = offsetof(ngx_rbtree_node_t, color) //新建记录分配内存，计算所需空间大小
  + offsetof(ngx_http_limit_req_node_t, data)
  + len;
 
node = ngx_slab_alloc_locked(ctx->shpool, size);
 
node->key = hash;
 
lr = (ngx_http_limit_req_node_t *) &node->color; //color为u_char类型，为什么能强制转换为ngx_http_limit_req_node_t指针类型呢？
 
lr->len = (u_char) len;
lr->excess = 0;
 
ngx_memcpy(lr->data, data, len);
 
ngx_rbtree_insert(&ctx->sh->rbtree, node);
 
ngx_queue_insert_head(&ctx->sh->queue, &lr->queue);

通过分析上面代码，ngx_rbtree_node_s结构体的color与data字段其实是无意义的，结构体的生命形式与最终存储形式是不同的，nginx最终使用以下存储形式存储每条记录；

3.2.2限流算法

上面提到在postconfiguration过程会注册ngx_http_limit_req_handler方法到http处理的ngx_http_preaccess_phase阶段；

因此在处理http请求时，会执行ngx_http_limit_req_handler方法判断是否需要限流；

3.2.2.1漏桶算法实现

用户可能同时配置若干限流，因此对于http请求，nginx需要遍历所有限流策略，判断是否需要限流；

ngx_http_limit_req_lookup方法实现了漏桶算法，方法返回3种结果：

• ngx_busy：请求速率超出限流配置，拒绝请求；

• ngx_again：请求通过了当前限流策略校验，继续校验下一个限流策略；

• ngx_ok：请求已经通过了所有限流策略的校验，可以执行下一阶段；

• ngx_error：出错

//limit，限流策略；hash，记录key的hash值；data，记录key的数据内容；len，记录key的数据长度；ep，待处理请求数目；account，是否是最后一条限流策略
static ngx_int_t ngx_http_limit_req_lookup(ngx_http_limit_req_limit_t *limit, ngx_uint_t hash, u_char *data, size_t len, ngx_uint_t *ep, ngx_uint_t account)
{
 //红黑树查找指定界定
 while (node != sentinel) {
 
  if (hash < node->key) {
   node = node->left;
   continue;
  }
 
  if (hash > node->key) {
   node = node->right;
   continue;
  }
 
  //hash值相等，比较数据是否相等
  lr = (ngx_http_limit_req_node_t *) &node->color;
 
  rc = ngx_memn2cmp(data, lr->data, len, (size_t) lr->len);
  //查找到
  if (rc == 0) {
   ngx_queue_remove(&lr->queue);
   ngx_queue_insert_head(&ctx->sh->queue, &lr->queue); //将记录移动到lru队列头部
  
   ms = (ngx_msec_int_t) (now - lr->last); //当前时间减去上次访问时间
 
   excess = lr->excess - ctx->rate * ngx_abs(ms) / 1000 + 1000; //待处理请求书-限流速率*时间段+1个请求（速率，请求数等都乘以1000了）
 
   if (excess < 0) {
    excess = 0;
   }
 
   *ep = excess;
 
   //待处理数目超过burst（等待队列大小），返回ngx_busy拒绝请求（没有配置burst时，值为0）
   if ((ngx_uint_t) excess > limit->burst) {
    return ngx_busy;
   }
 
   if (account) { //如果是最后一条限流策略，则更新上次访问时间，待处理请求数目，返回ngx_ok
    lr->excess = excess;
    lr->last = now;
    return ngx_ok;
   }
   //访问次数递增
   lr->count++;
 
   ctx->node = lr;
 
   return ngx_again; //非最后一条限流策略，返回ngx_again，继续校验下一条限流策略
  }
 
  node = (rc < 0) ? node->left : node->right;
 }
 
 //假如没有查找到节点，需要新建一条记录
 *ep = 0;
 //存储空间大小计算方法参照3.2.1节数据结构
 size = offsetof(ngx_rbtree_node_t, color)
   + offsetof(ngx_http_limit_req_node_t, data)
   + len;
 //尝试淘汰记录（lru）
 ngx_http_limit_req_expire(ctx, 1);
 
  
 node = ngx_slab_alloc_locked(ctx->shpool, size);//分配空间
 if (node == null) { //空间不足，分配失败
  ngx_http_limit_req_expire(ctx, 0); //强制淘汰记录
 
  node = ngx_slab_alloc_locked(ctx->shpool, size); //分配空间
  if (node == null) { //分配失败，返回ngx_error
   return ngx_error;
  }
 }
 
 node->key = hash; //赋值
 lr = (ngx_http_limit_req_node_t *) &node->color;
 lr->len = (u_char) len;
 lr->excess = 0;
 ngx_memcpy(lr->data, data, len);
 
 ngx_rbtree_insert(&ctx->sh->rbtree, node); //插入记录到红黑树与lru队列
 ngx_queue_insert_head(&ctx->sh->queue, &lr->queue);
 
 if (account) { //如果是最后一条限流策略，则更新上次访问时间，待处理请求数目，返回ngx_ok
  lr->last = now;
  lr->count = 0;
  return ngx_ok;
 }
 
 lr->last = 0;
 lr->count = 1;
 
 ctx->node = lr;
 
 return ngx_again; //非最后一条限流策略，返回ngx_again，继续校验下一条限流策略
  
}

举个例子，假如burst配置为0，待处理请求数初始为excess；令牌产生周期为t；如下图所示

3.2.2.2lru淘汰策略

上一节叩痛算法中，会执行ngx_http_limit_req_expire淘汰一条记录，每次都是从lru队列末尾删除；

第二个参数n，当n==0时，强制删除末尾一条记录，之后再尝试删除一条或两条记录；n==1时，会尝试删除一条或两条记录；代码实现如下：

static void ngx_http_limit_req_expire(ngx_http_limit_req_ctx_t *ctx, ngx_uint_t n)
{
 //最多删除3条记录
 while (n < 3) {
  //尾部节点
  q = ngx_queue_last(&ctx->sh->queue);
  //获取记录
  lr = ngx_queue_data(q, ngx_http_limit_req_node_t, queue);
   
  //注意：当为0时，无法进入if代码块，因此一定会删除尾部节点；当n不为0时，进入if代码块，校验是否可以删除
  if (n++ != 0) {
 
   ms = (ngx_msec_int_t) (now - lr->last);
   ms = ngx_abs(ms);
   //短时间内被访问，不能删除，直接返回
   if (ms < 60000) {
    return;
   }
    
   //有待处理请求，不能删除，直接返回
   excess = lr->excess - ctx->rate * ms / 1000;
   if (excess > 0) {
    return;
   }
  }
 
  //删除
  ngx_queue_remove(q);
 
  node = (ngx_rbtree_node_t *)
     ((u_char *) lr - offsetof(ngx_rbtree_node_t, color));
 
  ngx_rbtree_delete(&ctx->sh->rbtree, node);
 
  ngx_slab_free_locked(ctx->shpool, node);
 }
}

3.2.2.3 burst实现

burst是为了应对突发流量的，偶然间的突发流量到达时，应该允许服务端多处理一些请求才行；

当burst为0时，请求只要超出限流速率就会被拒绝；当burst大于0时，超出限流速率的请求会被排队等待 处理，而不是直接拒绝；

排队过程如何实现？而且nginx还需要定时去处理排队中的请求；

2.2小节提到事件都有一个定时器，nginx是通过事件与定时器配合实现请求的排队与定时处理；

ngx_http_limit_req_handler方法有下面的代码：

//计算当前请求还需要排队多久才能处理
delay = ngx_http_limit_req_account(limits, n, &excess, &limit);

//添加可读事件
if (ngx_handle_read_event(r->connection->read, 0) != ngx_ok) {
 return ngx_http_internal_server_error;
}

r->read_event_handler = ngx_http_test_reading;
r->write_event_handler = ngx_http_limit_req_delay; //可写事件处理函数
ngx_add_timer(r->connection->write, delay); //可写事件添加定时器（超时之前是不能往客户端返回的）

计算delay的方法很简单，就是遍历所有的限流策略，计算处理完所有待处理请求需要的时间，返回最大值；

if (limits[n].nodelay) { //配置了nodelay时，请求不会被延时处理，delay为0
 continue;
}
 
delay = excess * 1000 / ctx->rate;
 
if (delay > max_delay) {
 max_delay = delay;
 *ep = excess;
 *limit = &limits[n];
}

简单看看可写事件处理函数ngx_http_limit_req_delay的实现

static void ngx_http_limit_req_delay(ngx_http_request_t *r)
{
 
 wev = r->connection->write;
 
 if (!wev->timedout) { //没有超时不会处理
 
  if (ngx_handle_write_event(wev, 0) != ngx_ok) {
   ngx_http_finalize_request(r, ngx_http_internal_server_error);
  }
 
  return;
 }
 
 wev->timedout = 0;
 
 r->read_event_handler = ngx_http_block_reading;
 r->write_event_handler = ngx_http_core_run_phases;
 
 ngx_http_core_run_phases(r); //超时了，继续处理http请求
}

4.实战

4.1测试普通限流

1）配置nginx限流速率为1qps，针对客户端ip地址限流（返回状态码默认为503），如下：

http{
 limit_req_zone $binary_remote_addr zone=test:10m rate=1r/s;
 
 server {
  listen  80;
  server_name localhost;
  location / {
   limit_req zone=test;
   root html;
   index index.html index.htm;
  }
}

2）连续并发发起若干请求；3）查看服务端access日志，可以看到22秒连续到达3个请求，只处理1个请求；23秒到达两个请求，第一个请求处理，第二个请求被拒绝

xx.xx.xx.xxx - - [22/sep/2018:23:33:22 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:33:22 +0800] "get / http/1.0" 503 537 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:33:22 +0800] "get / http/1.0" 503 537 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:33:23 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:33:23 +0800] "get / http/1.0" 503 537 "-" "apachebench/2.3"

4.2测试burst

1）限速1qps时，超过请求会被直接拒绝，为了应对突发流量，应该允许请求被排队处理；因此配置burst=5，即最多允许5个请求排队等待处理；

http{
 limit_req_zone $binary_remote_addr zone=test:10m rate=1r/s;
 
 server {
  listen  80;
  server_name localhost;
  location / {
   limit_req zone=test burst=5;
   root html;
   index index.html index.htm;
  }
}

2）使用ab并发发起10个请求，ab -n 10 -c 10 http://xxxxx；

3）查看服务端access日志；根据日志显示第一个请求被处理，2到5四个请求拒绝，6到10五个请求被处理；为什么会是这样的结果呢？

查看ngx_http_log_module，注册handler到ngx_http_log_phase阶段（http请求处理最后一个阶段）；

因此实际情况应该是这样的：10个请求同时到达，第一个请求到达直接被处理，第2到6个请求到达，排队延迟处理（每秒处理一个）；第7到10个请求被直接拒绝，因此先打印access日志；

第2到6个请求米诶秒处理一个，处理完成打印access日志，即49到53秒每秒处理一个；

xx.xx.xx.xxx - - [22/sep/2018:23:41:48 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:41:48 +0800] "get / http/1.0" 503 537 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:41:48 +0800] "get / http/1.0" 503 537 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:41:48 +0800] "get / http/1.0" 503 537 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:41:48 +0800] "get / http/1.0" 503 537 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:41:49 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:41:50 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:41:51 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:41:52 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [22/sep/2018:23:41:53 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"

4）ab统计的响应时间见下面，最小响应时间87ms，最大响应时间5128ms，平均响应时间为1609ms：

min mean[+/-sd] median max
connect:  41 44 1.7  44  46
processing: 46 1566 1916.6 1093 5084
waiting:  46 1565 1916.7 1092 5084
total:   87 1609 1916.2 1135 5128

4.3测试nodelay

1）4.2显示，配置burst后，虽然突发请求会被排队处理，但是响应时间过长，客户端可能早已超时；因此添加配置nodelay，使得nginx紧急处理等待请求，以减小响应时间：

http{
 limit_req_zone $binary_remote_addr zone=test:10m rate=1r/s;
 
 server {
  listen  80;
  server_name localhost;
  location / {
   limit_req zone=test burst=5 nodelay;
   root html;
   index index.html index.htm;
  }
}

2）使用ab并发发起10个请求，ab -n 10 -c 10 http://xxxx/；

3）查看服务端access日志；第一个请求直接处理，第2到6个五个请求排队处理（配置nodelay，nginx紧急处理），第7到10四个请求被拒绝

xx.xx.xx.xxx - - [23/sep/2018:00:04:47 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [23/sep/2018:00:04:47 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [23/sep/2018:00:04:47 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [23/sep/2018:00:04:47 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [23/sep/2018:00:04:47 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [23/sep/2018:00:04:47 +0800] "get / http/1.0" 200 612 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [23/sep/2018:00:04:47 +0800] "get / http/1.0" 503 537 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [23/sep/2018:00:04:47 +0800] "get / http/1.0" 503 537 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [23/sep/2018:00:04:47 +0800] "get / http/1.0" 503 537 "-" "apachebench/2.3"
xx.xx.xx.xxx - - [23/sep/2018:00:04:47 +0800] "get / http/1.0" 503 537 "-" "apachebench/2.3"

4）ab统计的响应时间见下面，最小响应时间85ms，最大响应时间92ms，平均响应时间为88ms：

min mean[+/-sd] median max
connect:  42 43 0.5  43  43
processing: 43 46 2.4  47  49
waiting:  42 45 2.5  46  49
total:   85 88 2.8  90  92

위 내용은 nginx 전류 제한 모듈 소스 코드 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!