nginx脚本引擎与设计设计(三)

        这一部分我们将探讨一些较细节的东西，加上前面(一)，(二)两篇文章对典型情景的分析，我相信应该会对大家理解nginx的脚本解析机制有很大的帮助的。

 

        这里我们关注ngx_http_core_main_conf_t（下面简写为cmcf）结构中的这两个成员，cmcf->variables_keys和cmcf->variables，其中variables_keys是个hash数组，变量hash值相同的放到一个数组中，而且是唯一的，重复时会报错。重要的是这个hash数组，即cmcf->variables_keys，保存了整个系统中所有预定义的，自定义，几乎所有的变量(一些特定前缀的变量除外，如“http_”等，在函数ngx_http_variables_init_vars中都列出来了)。

 

我们分条目来看：

1.  系统中所有可能用到变量都会放到cmcf->variables_keys中。

 

2.  配置中出现的变量(在处理请求时会用到的)，会放到cmcf->variables中。总体上来看，除去一些有特定前缀的变量(这类变量后面会讲)，cmcf->variables可以看做是ngx_http_variables_init_vars的子集。从这里的设计可以看出来，系统定义的变量在请求处理时，并不会全部用到，我们只需根据配置，拿到有用的就可以了，所以cmcf->variables_keys使用了temp_pool(实际的元素则使用cf->pool)，当variables收集变量完成之后，variables_keys结构也就没什么用处了。

 

3.  cmcf->variables是一个数组，它的元素类型为ngx_http_variable_t。

struct ngx_http_variable_s {

   // 变量名字符串

    ngx_str_t                    name; 

// 使用变量中的值设置request的某个成员的值，所谓set

    ngx_http_set_variable_pt   set_handler;

// 根据request中成员(如uri，args等)的值来设置，r->variables中对应变量的内容。 

    ngx_http_get_variable_pt   get_handler;

// 需要具体处理的具体内容，因为这个结构是通用的，那么具体处理的信息就放到// data成员中

    uintptr_t                    data;

// 一些标识信息，区别不同处理，后面会详细讲

    ngx_uint_t                   flags;

// 该变量在cmcf->variables数组中的下标

    ngx_uint_t                   index;

};

4.  在init_request阶段，我们看到有这样的处理：

r->variables =ngx_pcalloc(r->pool, cmcf->variables.nelts * sizeof(ngx_http_variable_value_t));

这里的设计思想是这样的，cmcf->variables是每个变量的处理信息的封装，而r-> variables里面则是处理该变量得到的内容(即value)，所以cmcf->variables跟r->variables是一一对应的，成员之间就是var对value的关系，这不过这里的var和value是封装了很多信息的结构，不是单纯的值或字符串。这里我们看下r->variables的成员。

typedef struct {

    unsigned    len:28;

    unsigned    valid:1;          // 表示该变量在数组中并且有效，可以使用

// 表示使用该变量时，需要重新通过get_handler来获取，因为该变量的实际内容// 可能已经改变了。

    unsigned    no_cacheable:1; 

// 特定位置上的变量不存在(实际上是没有设置)，那么它就是“not found”!

    unsigned    not_found:1;

    unsigned    escape:1; // 这里不管它，跟我们的情景没有多大关系

    u_char     *data;

} ngx_variable_value_t;

 

我们看到这个结构中处理包含代表直接变量值的指针和大小(即data和len)外，剩下的都是一些标记位。

 

下面我们看几个宏：

#define NGX_HTTP_VAR_CHANGEABLE   1

#define NGX_HTTP_VAR_NOCACHEABLE  2

#define NGX_HTTP_VAR_INDEXED       4

#define NGX_HTTP_VAR_NOHASH        8

 

1.  NGX_HTTP_VAR_CHANGEABLE

使用这个宏的时候意味着，该变量可以重复配置，一般后配置的会覆盖前面的配置。如：

set $file $1

set $file $2

那么结果就是file的最终值就是$2所代表的。

2.  NGX_HTTP_VAR_NOCACHEABLE

这个宏所影响的正是ngx_variable_value_t结构中的no_cacheable，前面注释里面提到过，凡是有该标记的变量，都要通过get_handler来获取变量的值。如下面函数：

ngx_http_get_flushed_variable(ngx_http_request_t *r, ngx_uint_tindex)

{

   ngx_http_variable_value_t  *v;

   v = &r->variables[index];

// 找到变量，发现是有效的，但是由于属于NGX_HTTP_VAR_NOCACHEABLE，所以// 需要在cmcf->variables找到它的处理结构来重新获取新值。

   if (v->valid) {  // 变量有效，具备可以使用的潜质

       if (!v->no_cacheable) { //可以直接用，就返回了

            return v;

       }

       // 这是一个NGX_HTTP_VAR_NOCACHEABLE类型的变量，那么…

       v->valid = 0;

       v->not_found = 0;

   }

// 重新获取，这个函数就不看了，大家可以自己分析

   returnngx_http_get_indexed_variable(r, index);

}

 

这种变量往往是跟特定的请求紧密相关的，如host，uri，args之类的，处理时每次重新获取新值时必要的。

3.  NGX_HTTP_VAR_INDEXED和NGX_HTTP_VAR_NOHASH

这两个宏主要是在SSI相关处理中用到，而ssi的处理需要用到cmcf->variables_hash，这是hash表，可以高效的找到变量。NGX_HTTP_VAR_NOHASH类型的变量压根就不会被放到这个hash表中，而从hash表中找到的变量，是ngx_http_variable_t结构，如果我们从它flags发现NGX_HTTP_VAR_INDEXED标记，那么意味着我们可以直接到r->variables中去找，至于找到后可用与否，那要另作判断了！