Nginx on codedump notes

OpenResty Lua Stream实现分析

Wed, 01 May 2019 15:03:45 +0800

概述 #

OpenResty（以下简称OR）是Lua应用的典范，其最大的亮点在于，使用Lua协程搭配上异步非阻塞的IO，这样开发者可以使用同步方式来编写代码，而底层IO调度、唤醒等操作留给C编写的引擎层。

实际上，使用类协程的技术，让异步操作同步化，已经有很多相关的技术了，比如腾讯的libco、百度的brpc都是自己在C层面实现了类协程的机制，不过这一类技术用的最广泛的还是OR。市面上分析OR内部实现的文章并不算很多，所以这段时间研究了一下OR的实现。

OR内部，其实是分7层HTTP的ngx_lua模块，以及四层TCP的lua_stream实现，两者在很多部分都很相近，以下分析以4层的lua_stream来解释，对应的版本是openresty-1.13.6.1和ngx_stream_lua-0.0.3的实现。

既然OR在这里选择了使用协程来将用户的异步操作同步化，那么实际上内部其实实现了一个简易版本的操作系统内核的“CPU调度”，其中一个一个的协程就是CPU调度单位，因此在这里分为几部分来分析：

维护协程的数据结构。
创建新协程的时候如何进行初始化？
协程调度算法？
如何将异步操作同步化？

在这里，先列举出来OR中与“调度”相关的核心数据结构和函数：

调度相关核心组件	数据结构或函数
调度单元	Lua协程（lua_State）
保存协程信息	ngx_stream_lua_co_ctx_t
当前调度协程信息	ngx_stream_lua_ctx_t.cur_co_ctx成员，指向一个ngx_stream_lua_co_ctx_t类型指针
调度函数	ngx_stream_lua_run_thread

协程的维护 #

OR中有以下两种场景能够创建出来一个协程：

一个tcp请求自动对应一个协程。这种场景用户不能控制，即默认就是这么实现的，当收到一个TCP请求默认创建出来一个协程与之绑定。
Lua代码内部显示调用thread.spawn函数创建一个用户线程时。与前者不同，这种场景就是用户可以自己控制的。

lua stream内部，协程相关的数据结构存储在ngx_stream_lua_co_ctx_t中，既然OR里面使用协程来模拟用户线程，不难想象这个数据结构内部应该有以下的成员：

维护协程内部栈关系的数据。由于OR采用了Lua协程，这部分当然就是留给Lua协程来处理了。
保存协程状态的数据。
维护协程之间关系的数据，比如父子协程、僵尸子协程，等等。

下面简单的看一下其成员：

void *data：存储用户相关数据。
lua_State *co：存储Lua协程指针。
ngx_stream_lua_co_ctx_t *parent_co_ctx：存储父协程指针。
ngx_stream_lua_posted_thread_t *zombie_child_threads：将该协程管理的僵尸子进程放在这个队列中。
int co_ref：在Lua的registry表中对应该协程指针的引用值。
unsigned waited_by_parent：为1的情况下表示该协程的父协程在等待该协程的退出。
unsigned co_status：当前协程状态。
unsigned is_uthread：为1的情况下表示该协程是用户线程，即上面提到的场景2创建出来的协程。
unsigned thread_spawn_yielded：为1的情况下表示当前协程是由于创建了用户线程（前面的场景2）才让出的执行权。

ngx_stream_lua_co_ctx_t

另外，还有一个全局变量ngx_stream_lua_ctx_t，其中的cur_co_ctx指针指向当前被调度执行的ngx_stream_lua_co_ctx_t指针。

协程的初始化 #

上一部分提到了创建协程的两种场景，这里就来分析这两种场景下面协程的初始化。

新建立连接的协程 #

OR通过在nginx配置文件中填写"content_by_lua_block"等，来配置新建一个连接时对应的Lua脚本，这种场景下OR会默认创建出来一个Lua协程来执行这段脚本代码。

对应创建Lua协程的代码在函数ngx_stream_lua_new_thread中，下面来分析这个函数的流程。

OR中需要在Registry表中存储每个创建出来的Lua协程的reference，这个存储协程的表在Registry表中对应的key是全局变量ngx_stream_lua_coroutines_key的指针，因此下面这段代码就是从Registry表中查询这个表返回到栈顶：

lua_pushlightuserdata(L, &ngx_stream_lua_coroutines_key);
lua_rawget(L, LUA_REGISTRYINDEX);

接着下来就是创建了一个新的协程，同时初始化其全局表：

// 创建Lua协程
co = lua_newthread(L);
// 创建该协程的全局表
ngx_stream_lua_create_new_globals_table(co, 0, 0);
// 再创建一个新表
lua_createtable(co, 0, 1);
// 拿到全局表
ngx_stream_lua_get_globals_table(co);
// 全局表的__index指向新创建的表
lua_setfield(co, -2, "__index");
// 全局表的meta table指向新创建的表
lua_setmetatable(co, -2);
// set 全局表回去
ngx_stream_lua_set_globals_table(co);

从上面的代码可以看出，新创建的协程，其全局表目前是一个空表。

Nginx源码阅读笔记-内存池的设计

Thu, 14 Feb 2019 14:48:24 +0800

nginx中所有请求都单独对应一个内存池，在这个请求的过程中，所有涉及到内存分配的地方，都到该请求相关的内存池中处理，而中间不会去释放回收内存，内存池的生命周期与请求一样，请求完毕则直接回收内存。这样的好处在于：统一分配和统一释放，降低了内存泄露问题的出现。

nginx的内存池设计的比较简单了，一个内存池中分为两个部分：

超过max大小的内存分配，走大块内存分配，这部分内存管理由ngx_pool_large_t结构体负责。
否则就是在ngx_pool_t遍历符合要求的ngx_pool_t结构体，找到符合要求大小的pool直接返回，否则就申请一块新的内存pool。

ngx_pool_data_t #

先来看结构体ngx_pool_data_t，它存储每个ngx_pool_t结构体的meta元数据：

u_char *last：指向分配空间的可用空间。
u_char *end：指向分配空间的最后位置。
ngx_pool_t *next：指向下一个ngx_pool_t指针。
ngx_uint_t failed：存储本ngx_pool_t结构体分配失败次数。

ngx_pool_data_t

failed成员的引入是为了避免某个pool虽然还有可用的空间，但是由于空间很小了所以经常性的分配空间失败，当累计失败的次数达到某个阈值时，下一次再次查找内存就直接跳过这个pool，而去寻找内存池链表中的下一个pool。

ngx_pool_large_t #

ngx_pool_large_t结构体用于保存大内存块，这一块就比较简单粗暴了，直接分配一块大内存来使用。另外，多个大内存块之间也是以链表形式来组织数据。

// 管理超大空间的结构体
struct ngx_pool_large_s {
  // 指向下一个指针
  ngx_pool_large_t     *next;
  // 直接指向内存区域的指针
  void                 *alloc;
};

ngx_pool_t #

再来看ngx_pool_t结构体，该数据结构用于表示一个内存池，内存池内部以链表形式来组织数据。如下图：

ngx_pool_t

需要说明的是：

内存池内部以链表形式组织起来，完成这个工作的就是前面的ngx_pool_data_t的next成员。
current指针，用于表示当前该内存池在使用的pool指针。除了内存池链表的头结点之外，内存池链表其他节点的该指针无效。之所以需要这个指针，就是前面提到的，在某个内存池多次失效的情况下，下一次直接跳过该内存池查找空间，current指针保存当前在内存池链表的哪一个内存池上面查找空间。
large指针，指向ngx_pool_large_t结构体，管理大块内存。

有了以上数据结构的了解，从内存池分配内存的流程就很简单了：

memory-pool

Nginx源码阅读笔记-处理HTTP请求

Wed, 13 Feb 2019 09:09:19 +0800

前面分析了nginx如何读取一个HTTP请求、如何查询到HTTP对应的配置，本节分析如何处理HTTP请求。

处理HTTP请求的11个阶段 #

nginx将处理HTTP请求划分为了11个阶段，原因在于nginx是一个重度模块化的系统，划分为不同阶段以后，不同的模块可以根据自己的需求在相应的模块中添加自己的处理函数。

简单看看这11个模块的定义：

typedef enum {
  // 在接收到完整的HTTP头部后处理的HTTP阶段
  NGX_HTTP_POST_READ_PHASE = 0,

  // 在将请求的URI与location表达式匹配前，修改请求的
  // URI（所谓的重定向）是一个独立的HTTP阶段
  NGX_HTTP_SERVER_REWRITE_PHASE,

  // 根据请求的URL寻找匹配的location表达式，这个阶段
  // 只能由ngx_http_core_module模块实现，不建议其他HTTP
  // 模块模块重新定义这一阶段的行为
  NGX_HTTP_FIND_CONFIG_PHASE,

  // 在NGX_HTTP_FIND_CONFIG_PHASE阶段寻找到匹配的location
  // 之后再修改请求的URI
  NGX_HTTP_REWRITE_PHASE,

  // 这一阶段用于在rewrite重写URL后，防止错误的nginx配置导致
  // 死循环（递归地修改URI），因此，这一阶段仅由ngx_http_core_module
  // 模块处理。目前，控制死循环的方法就是看rewrite次数，超过一定阈值
  // 就认为出现了死循环，返回500
  NGX_HTTP_POST_REWRITE_PHASE,

  // 表示在处理NGX_HTTP_ACCESS_PHASE阶段决定请求的访问权限前，HTTP模块可以介入的处理阶段
  NGX_HTTP_PREACCESS_PHASE,

  // 这个阶段用于让HTTP模块判断是否允许这个请求访问Nginx服务器
  NGX_HTTP_ACCESS_PHASE,

  // 在NGX_HTTP_ACCESS_PHASE阶段中，当HTTP模块的handler处理函数返回不允许访问的错误码时（
  // 实际就是NGX_HTTP_FORBIDDEN或者NGX_HTTP_UNAUTHORIZED），这里将负责向用户发送拒绝服务的
  // 错误响应，因此这个阶段实际上用于给NGX_HTTP_ACCESS_PHASE阶段收尾
  NGX_HTTP_POST_ACCESS_PHASE,

  // 这个阶段完全为try_files配置项而设立的，当HTTP访问静态文件资源时，try_files配置项可以
  // 使这个请求顺序地访问多个静态文件资源，如果某一次访问失败，则继续访问try_files中指定的
  // 下一个静态资源。
  NGX_HTTP_PRECONTENT_PHASE,

  // 用于处理HTTP请求内容的阶段，这是大部分HTTP模块最愿意介入的阶段
  NGX_HTTP_CONTENT_PHASE,

  // 处理完请求记录日志的阶段。
  NGX_HTTP_LOG_PHASE
} ngx_http_phases;

这11个阶段里，有一些是可以由模块开发者插入自己的处理函数，有一些只能使用nginx的http框架的实现。另外，每个阶段并不是一定只能有一个处理函数，有的可以提供多个处理函数，在同一个阶段中顺序被调用。

Nginx源码阅读笔记-查询HTTP配置流程

Tue, 12 Feb 2019 09:54:25 +0800

概述 #

前面已经分析过nginx解析配置文件的整体流程，接下来看查询HTTP配置的流程。

HTTP属于nginx的core顶层模块，下面又包括了三部分：

main部分配置：即在HTTP块但是又不在任何server、location块中的配置，如下图中的sendfile配置指令。
server块：在server块内部的配置。
location块：在location块内部分配置。

http_config

解析HTTP模块的入口函数是ngx_http_block，这一点可以从http指令相关的配置看出：

{ ngx_string("http),
  NGX_MAIN_CONF|NGX_CONF_BLOCK|NGX_CONF_NOARGS,
  ngx_http_block,
  0,
  0,
  NULL }

在这个解析函数的开始，就创建了ngx_http_conf_ctx_t结构体，所以看的出来这个结构体是HTTP模块的第一级配置，它的定义如下：

typedef struct {
  void        **main_conf;
  void        **srv_conf;
  void        **loc_conf;
} ngx_http_conf_ctx_t;

下面列举出来这几部分相关的函数以及数据结构：

块	入口函数	数据结构
http	ngx_http_block	ngx_http_conf_ctx_t
main		ngx_http_core_main_conf_t
server	ngx_http_core_server	ngx_http_core_srv_conf_t
location	ngx_http_core_location	ngx_http_core_loc_conf_t

ngx_http_module

另外，由于HTTP块内的一些配置，作用域可以在多种块中，因此需要涉及到合并配置的流程，即：

如果子作用域某配置项在解析过程中未被赋值，则将父作用域的相同的配置项值拷贝至此配置项里；
如果子作用域配置项在解析过程中被赋值了，则保留原样；如果子作用域配置项和父作用域配置项都没有被初始化，则填入代码中预设的默认值。

相关的合并配置函数列举如下：

块	合并函数
server	ngx_http_merge_servers
location	ngx_http_merge_locations

以下具体看看一次HTTP请求如何查找到相关HTTP配置的流程，分为两步：

根据Host查找server块
根据URI查找location块

根据Host查找server块流程 #

前面分析nginx接收HTTP请求流程中分析到，nginx在接收HTTP请求流程中，将调用ngx_http_process_request_headers函数来处理请求头。

nginx使用一个ngx_http_header_t结构体，定义了哪些请求头需要进行特定的函数回调处理，函数ngx_http_process_request_headers会根据这个表来查询接收到的请求头都需要哪些回调函数来处理：

ngx_http_header_t  ngx_http_headers_in[] = {
  { ngx_string("Host"), offsetof(ngx_http_headers_in_t, host),
    ngx_http_process_host },

  { ngx_string("Connection"), offsetof(ngx_http_headers_in_t, connection),
    ngx_http_process_connection },
  ....
}

可以看到，针对Host这个header，会调用ngx_http_process_host函数，这个函数最终会调用ngx_http_set_virtual_server函数来根据Host头确定对应的server块。

Nginx源码阅读笔记-接收HTTP请求流程

Fri, 01 Feb 2019 17:50:37 +0800

前面已经描述过nginx的事件模块了，接下来具体分析nginx如何接收一个HTTP请求，下一部分接着解析nginx解析HTTP请求的流程。

协议状态机编程模式 #

TCP协议是一种流协议（stream protocol），这意味着数据是以字节流形式给数据接收者的，一次网络接收不一定能接收完毕，需要上面的应用层根据自己协议的情况来解析处理。它的数据没有边界，需要应用层自己根据协议来判断边界的存在。

如果两次请求，分开为几次接收，但是某次接收的数据中，有跨两次请求的数据，这就是所谓的“粘包(sticky-package)”问题。如下图所示：

sticky-package-problem

结合epoll之类的事件派发器来设计一个TCP协议的服务器时，因为并不能确保每一次接收数据，都能完整的接收到协议所需的所有数据。因此一般而言，写一个高性能服务器的协议解析部分，会以状态机的方式来实现，即定义了协议数据的每个部分，如下伪代码所示：

// 定义协议头数据
typedef struct header_t {
  // 协议版本号
  int version;
  // 定义body部分大小
  int size;
} header_t;

// 定义协议数据
typedef struct protocol_t {
  header_t header;
  char body[0];
} protocol;

// 定义接收数据的状态机类型
enum state_t {
  RECV_HEADER,        // 接收包头
  RECV_BODY,          // 接收包体
  PROCESS_PROTOCOL,   // 处理协议
  SEND_RESPONSE       // 发送回复
};

// 处理请求的状态机
void statemachine() {
  switch (state) {
  case RECV_HEADER:
    // 接收协议包头数据
    // 接收完毕之后，切换state到RECV_BODY
  case RECV_BODY:
    // 接收协议包体数据
    // 接收完毕之后，切换state到PROCESS_PROTOCOL
  case PROCESS_PROTOCOL:
    // 处理协议
    // 处理完毕之后，切换state到SEND_RESPONSE
  case SEND_RESPONSE:
    // 发送应答
  }
}

如上面的伪代码所示，接收一个请求之后，会初始化一个变量state用于保存当前协议处理的状态类型，假如第一次接收数据时还不能接收完毕协议的数据，就将接收fd重新放入到事件派发器中，下一次被唤醒之后再根据当前的状态继续接收数据进行处理。

Nginx源码阅读笔记-事件处理模块

Thu, 31 Jan 2019 21:12:01 +0800

大概做高性能服务器的，都绕不开事件处理模块来，一般一个事件模块，会分为以下几部分：

如何定义一个描述事件的数据结构。
如何在事件模块中支持定时器。
如果需要支持多平台，事件模块需要考虑如何统一以及区分各平台的具体实现。

下面就这三部分展开Nginx事件处理模块的分析。

ngx_event_t #

描述事件的数据结构，一般至少需要以下几部分数据：

用于保存用户相关的数据。
用于保存事件触发之后的回调函数。
用于表示事件状态、类型的数据。

nginx中，描述事件采用的数据结构是ngx_event_t中，其内部成员就是按照前面的三部分来划分了。

void *data：事件相关的数据。
ngx_event_handler_pt handler：事件被触发时的回调函数。
第三类数据，ngx_event_t中划分的比较仔细：
- unsigned write:1：可写标志位
- unsigned active:1：活跃标志位
- unsigned disabled:1：禁用标志位
- unsigned eof:1：为1表示字节流已经结束
- unsigned error:1：处理事件出错
- unsigned timedout:1：事件超时
- unsigned timer_set:1：为1表示这是一个超时事件
- unsigned deferred_accept:1：为1表示需要延迟接收TCP连接
除了以上三部分，还有其他一些重要的数据：
- ngx_rbtree_node_t timer：红黑树节点，用于实现定时器的，下面讨论定时器再展开。
- ngx_queue_t queue：延迟队列，如果事件不在轮询循环中直接处理，而是之后被处理，就放在这个队列中。

总体来看，event这个结构体为了涵盖所有可能的事件，做的大而全，不只是用来描述一般的IO事件，还包括了定时器事件，还包括了接收连接相关的数据。

定时器的实现 #

Nginx内部使用红黑树来实现定时器，目的在于能够快速的查询到哪些定时器超时了。不同的事件结构中，这部分实现采用的数据结构不一样，libevent、libuv采用的是最小堆，redis比较挫，这部分采用的是链表。

在一个事件循环中，因为既要考虑到一般的IO事件，又要考虑到定时器事件，所以都会以一个最近被触发的定时器来做为查询IO事件被触发的时间，即以下的伪代码：

查询最近将被触发的定时器超时时间返回t
将t做为epoll_wait之类的查询IO事件的超时时间，即最长等待t时间看有没有IO事件被触发
遍历定时器，查询已经超时的定时器进行回调处理

从这里可以看出，“迅速查询到距离当前最近被触发的定时器时间”以及“迅速查询到当前哪些定时器超时”，是这个定时器模块速度的关键。

由于红黑树、最小堆这种平衡数据结构，每次查询都排除掉当前一半的元素，可以做到时间复杂度O(logn)，所以就常用来实现定时器了。

事件模块的实现 #

由于nginx需要跑在多个平台下面，而不同平台使用的事件机制又不一样，比如linux是epoll，bsd是kqueue等，需要实现事件模块的时候，既需要统一事件模块的共性部分，又需要区分不同平台的差异部分。

这看上去又是一个面向对象的设计问题了：基类负责实现共性的部分，子类具体再来实现各平台相关的部分。

前面分析libuv的时候提到过，libuv多使用宏来模拟C++中的继承，不是很认可这个代码风格，来看看nginx类似场景的实现。

nginx中，将事件相关的操作函数统一放在结构体ngx_event_actions_t中，可以把这部分类比于子类需要实现的函数接口：

typedef struct {
  ngx_int_t  (*add)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);
  ngx_int_t  (*del)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);

  ngx_int_t  (*enable)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);
  ngx_int_t  (*disable)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);

  ngx_int_t  (*add_conn)(ngx_connection_t *c);
  ngx_int_t  (*del_conn)(ngx_connection_t *c, ngx_uint_t flags);

  ngx_int_t  (*notify)(ngx_event_handler_pt handler);

  ngx_int_t  (*process_events)(ngx_cycle_t *cycle, ngx_msec_t timer,
    ngx_uint_t flags);

  ngx_int_t  (*init)(ngx_cycle_t *cycle, ngx_msec_t timer);
  void       (*done)(ngx_cycle_t *cycle);
} ngx_event_actions_t;

前面在分析到nginx如何解析配置的时候提到过，nginx中的配置是分层次的，event模块做为一个顶层的core模块，内部又有子模块，而这里的事件模块就是event模块中的子模块：

Nginx源码阅读笔记-Master Woker进程模型

Thu, 31 Jan 2019 09:53:57 +0800

master进程 #

Nginx采用的模型是master-worker模型，即：

由master进程负责创建worker进程，以及监控worker进程的情况，如需要更新配置的情况下发消息给worker进程重新加载配置等。
master进程负责具体网络事件。

将里面核心的流程和函数抽取出来，如下图所示：

master-worker

master进程的主循环在函数ngx_master_process_cycle中，主要负责：
- 调用ngx_start_worker_processes函数创建worker子进程。
- 监控各种信号量的变化做处理，比如需要停止进程、重新加载配置等。
master进程最终会调用函数ngx_spawn_process函数来创建出worker子进程：
- 使用共享内存创建出用于master-worker进程之间通信的channel。
- fork出子进程之后，进入worker进程的主函数ngx_worker_process_cycle。

以下列举出几个相关的信号量：

信号	对应全局变量	处理
QUIT	ngx_quit	优雅关闭整个Nginx服务
TERM或者INT	ngx_terminate	强制关闭Nginx服务
USR1	ngx_reopen	重新打开文件
WINCH	ngx_noaccept	所有worker进程不再接受新的连接，相当于给子进程发送QUIT信号
USR2	ngx_change_binary	平滑升级到新的Nginx二进制文件
HUP	ng_reconfigure	重新加载配置文件
CHLD	ngx_reap	需要监控所有子进程

worker进程 #

worker进程的函数入口在ngx_worker_process_cycle中，其主要做的工作分为两部分：

调用ngx_process_events_and_timers处理IO事件以及定时器事件。
判断ngx_terminate、ngx_quit、ngx_reopen这几个变量是否被置位来做相应的处理。

下面主要谈网络IO事件的处理，即ngx_process_events_and_timers函数。

先来介绍几个与接收连接相关的全局变量：

ngx_use_accept_mutex：由配置项accept_mutex配置，表示是否需要使用accept锁，只有抢到该锁的worker才允许接收新的连接。
ngx_accept_mutex_delay：由配置项accept_mutex_delay配置，在开启accept_mutex的情况下，一个worker进程在抢不到accept锁的情况下，最长多少时间才重新接收新的连接。
ngx_accept_disabled：值为ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n，可以看到当链接数量到nginx.conf中配置的worker_connections的7/8以上时，这个变量ngx_accept_disabled为正数，此时不会接收新的连接，直到该值小于等于0为止。
ngx_accept_mutex_held：表示是否抢到了accept锁，只有抢到的才能接收新连接。

具体来看看ngx_process_events_and_timers函数中与接收连接相关的逻辑，伪代码如下：

如果开启了accept_mutex配置：
  如果当前ngx_accept_disabled大于0，表示不能接收新的连接，直接返回。
  否则尝试获取accept mutex。
  如果获取accept mutex锁成功：
    将调用事件轮询函数的标志位加上NGX_POST_EVENTS标志
  如果获取失败：
    调用事件轮询函数的事件参数不得超过ngx_accept_mutex_delay值。

  调用ngx_process_events函数处理轮询事件

  调用ngx_event_process_posted(cycle, &ngx_posted_accept_events)函数处理accept事件

  如果前面拿到了accept mutex锁，则释放这个锁，好让其他worker也有机会接收新的连接

  调用ngx_event_expire_timers处理定时器事件

  调用ngx_event_process_posted(cycle, &ngx_posted_events);函数处理除了accept事件以外的其他post事件

在ngx_process_events处理函数中，当传入的flags有NGX_POST_EVENTS标志时，意味着并不马上在这个函数中调用事件的回调函数进行处理，而是放在一个队列中，回头在后面的ngx_event_process_posted函数中再进行处理。

Nginx源码阅读笔记-配置解析流程

Thu, 03 Jan 2019 08:41:44 +0800

本系列文章基于openresty-1.13.6.1版本的代码做的笔记，其对应的nginx源码版本是nginx-1.13.6。

模块与配置值解析相关数据结构 #

整个Nginx是以模块的方式来组织的，即使是核心的组件如epoll之类的，最终也是以模块的方式注册到nginx中的。所以先了解整个nginx模块的结构很有必要。

与模块相关的核心数据结构有以下这几个。

ngx_module_t结构体用于定义nginx模块相关的数据结构，其中包括几个核心的数据：

void *ctx：用于存储每个模块相关的context数据。
ngx_command_t *commands：用于存储与该模块相关的配置命令解析数据。所谓的配置命令，就是对应的nginx配置文件中的语句，如”event“、”include“等，每个配置语句最终一定有一个相关的ngx_command_t数据与之对应，负责解析这个命令。
ngx_uint_t type：用于保存模块的类型，目前包括NGX_HTTP_MODULE，NGX_CORE_MODULE，NGX_CONF_MOULE，NGX_EVENT_MODULE，NGX_MAIL_MODULE这几种类型。
一组回调函数：用于在解析配置的时候进行回调。

而上面的ngx_command_t结构体又有以下成员：

ngx_str_t name：配置文件里对应的配置项名称。如前面提到的nginx配置文件中的”event“、”include“等。
ngx_uint_t type：配置项类型，这里会存储如该配置项应该出现在什么位置（http块、server块、location块等），以及配置项参数数量，以便于解析过程中进行合法性的判断。
- 命令的作用域，即该命令能够出现在什么位置（http块、server块、location块等），这些与作用域相关的类型有NGX_MAIN_CONF、NGX_EVENT_CONF、NGX_HTTP_MAIN_CONF、NGX_HTTP_SRV_CONF、 NGX_HTTP_LOC_CONF、NGX_MAIL_MAIN_CONF、NGX_MAIL_SRV_CONF 等。
- 命令能够接受的参数数量，如NGX_CONF_NOARGS、NGX_CONF_TAKE1等。
ngx_uint_t offset：该配置命令所要修改的配置项在该模块配置结构体中的偏移量。
ngx_uint_t conf：该配置在子模块配置项中的索引。
回调函数set：在解析到配置项的时候进行回调。

下图中给出一个简单的nginx配置文件的作用域示意图：

ngx-conf-scope

有了以上两个核心数据结构，可以知道每个nginx模块注册时的方式：

定义一组与本模块相关的ngx_command_t，用于定义本模块相关的配置项信息。
定义一个与本模块相关的数据结构，注册为ngx_module_t的ctx指针，用于保存本模块相关的数据结构。
最后，将上面的数据放到ngx_module_t中，nginx解析配置的时候会自动回调对应的处理函数了。

以epoll模块来说，其ngx_module_t结构体是如下组织的。

epoll-module

根据上面的图示，不难想象，nginx在配置解析的时候是如何解析epoll相关的配置的：

首先解析到event模块，也就是nginx配置文件中的event{}部分，此时会把对用的context指针指向ngx_epoll_module_ctx，开始进行event模块的解析工作。
如果在event块中遇到名为“epoll_events”或者“worker_aio_requests”开始的配置，那么就知道是上面ngx_epoll_commands数组中定义的配置命令，nginx首先会根据这里定义的type来分析其出现的位置（是否出现在event块）以及参数数量（NGX_CONF_TAKE1）是否正确，都检测通过之后，才会调用ngx_command_t中set回调函数进行配置解析。

Nginx on codedump notes

OpenResty Lua Stream实现分析

概述 #

协程的维护 #

协程的初始化 #

新建立连接的协程 #

Nginx源码阅读笔记-内存池的设计

ngx_pool_data_t #

ngx_pool_large_t #

ngx_pool_t #

Nginx源码阅读笔记-处理HTTP请求

处理HTTP请求的11个阶段 #

Nginx源码阅读笔记-查询HTTP配置流程

概述 #

根据Host查找server块流程 #

Nginx源码阅读笔记-接收HTTP请求流程

协议状态机编程模式 #

Nginx源码阅读笔记-事件处理模块

ngx_event_t #

定时器的实现 #

事件模块的实现 #

Nginx源码阅读笔记-Master Woker进程模型

master进程 #

worker进程 #

Nginx源码阅读笔记-配置解析流程

模块与配置值解析相关数据结构 #

解析配置流程 #

相关核心函数 #