Nginx启动期做了哪些事

nginx是个多进程web容器，不同的配置下它的启动方式也是不同的，这里我只说说最典型的启动方式。

它有1个master进程，和多个worker进程（最优配置的数量与CPU核数相关）。那么，首先我们要找到main函数，它在src/core/nginx.c文件中。谈到源码了，这时我们先简单看下源码的目录结构吧。

nginx主要有下列目录：

src/core，这个目录存放了基础的数据结构像LIST、红黑树、nginx字符串，贯穿始终的一些逻辑结构如ngx_cycle_s、ngx_connection_s等，还有对一些底层操作的封装如log、文件操作、共享内存、内存池等，最后还有个nginx.c这个main启动函数了。

src/event，这个目录下存放与抽象事件相关的结构和钩子函数。nginx是以事件驱动处理流程的，事件自然是整个体系的核心了，这里定义了最核心的ngx_event_s结构。

src/event/modules目录存放了具体的种种事件驱动方式，例如epoll、kqueue、poll、aio、select等，它们通过ngx_event_actions_t结构体中的钩子挂在nginx中。nginx启动时会根据配置来决定使用哪种实现方式。

src/os/unix中存放了unix系统下许多函数调用的UNIX实现。

src/http目录存放到http module的相关实现，这个module负责处理http请求，包括协议的解析以及访问backend server的代码。

src/http/module目录存放http module类型的一些特定用途的module，比如gzip处理加密，图片压缩等。

有个初步了解后，回到main函数中，顺序看看我们感兴趣的事情。它先执行了ngx_time_init，为什么要初始化时间呢？nginx考虑的还是很周到的，取系统时间gettimeofday是系统调用，这意味着，需要发送中断给linux内核，内核需要做进程间切换来处理这个调用。这是一个不能忽视成本的函数。nginx封装了时间函数，这样，每次我们需要处理时间时，并不是调用gettimeofday，而是nginx自己缓存的时间，这样大量减少了系统调用，取当前时间这事可是谁都爱干的。

那么，nginx是怎么维护自己的这个时钟呢？如何保证用户取到的当前时间是有意义的？nginx设计者的出发点是，nginx是事件驱动机制，当一批事件发生时，也就是epoll_wait返回时，会取一次gettimeofday来更新自己的时间，然后调用各个事件对应的处理函数。这些函数都会保证自己是无阻塞的，也就是毫秒级的处理能力，所以，在任何一个事件处理函数中，取到的时间都是之前epoll_wait刚返回时取到的时间，这样，即使拿到的时间慢了几毫秒也无所谓。关键是，每个函数都是无阻塞的，都要迅速的把控制权交还给nginx，这是基本设计原则哈。

main函数初始化时间后，建立了最核心的数据结构ngx_cycle，之后无论是worker进程还是master进程都是围绕着它进行的。下面，我们要超级关注ngx_init_cycle这个函数，启动过程中大量的工作是在这完成的，代码就不列了，这个函数有800行，超大，也可见其之关键。ngx_init_cycle里做的第一件事就是调用所有nginx module里的create_conf方法。好，现在我们才来详细看下nginx module是什么。

nginx 抽象出一个ngx_module_s结构用来描述各个module，每个module处理它感兴起的事件。nginx里共有多少个module既是写死在代码中的，也是可以灵活配置的，呵呵，nginx式的玩法。回想下，下载nginx源码包后，我们也要执行它提供的configure操作，这个命令会生成makefile和ngx_modules文件，makefilel决定编译哪些module源文件，而生成的ngx_modules.c文件决定编译出的执行文件究竟使用哪些module。ngx_modules.c里面会生成一个数组ngx_modules，这是整个nginx工程都在使用的全局变量，它的形式如下：

ngx_module_t *ngx_modules[] = {
    &ngx_core_module,
    &ngx_errlog_module,
    &ngx_conf_module,
    ... ...
}

这个通过configure生成的全局变量很关键，只有它才知道，一个请求可能会用哪些module处理。

接上文，ngx_init_cycle就是通过ngx_modules数组来调用所有module的create_conf方法的（每个module有权力决定是否实现这个方法，如果不实现的话，当然不会调用了）。然后，开始处理配置文件，这里我们需要重点关注ngx_conf_parse函数，因为它里面调用了ngx_conf_handler方法，ngx_conf_handler方法会调用每个module里自己实现的set钩子函数，让每个module处理自己感兴趣的配置项。所以，如果你在nginx.conf里没有配置某个module想要的东东，这个module虽然编译进去了，却会一直不执行的。这里我们要看下module的结构了，不能总是干说哈。

struct ngx_module_s {
    ngx_uint_t            ctx_index;
    ngx_uint_t            index;
 ... ...
    void                 *ctx;
    ngx_command_t        *commands;
    ngx_uint_t            type;

    ngx_int_t           (*init_master)(ngx_log_t *log);
    ngx_int_t           (*init_module)(ngx_cycle_t *cycle);
    ngx_int_t           (*init_process)(ngx_cycle_t *cycle);
    ngx_int_t           (*init_thread)(ngx_cycle_t *cycle);
    void                (*exit_thread)(ngx_cycle_t *cycle);
    void                (*exit_process)(ngx_cycle_t *cycle);
    void                (*exit_master)(ngx_cycle_t *cycle);
... ...
};

ctx_index用来表示我们定义的一个module在上下文数组中的序号，index就表示在ngx_modules这个数组中的序号。

ctx这个指针指向module的上下文，type表示这个module的类型（module是分类的，每种type可以有多个module的），下面8个钩子函数，表示对应的事件发生时会调用这些方法（当然，module也可以不实现）。commands指向这个module所属的command结构，例如，http module是这么定义自己的command的：

static ngx_command_t  ngx_http_commands[] = {

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

      ngx_null_command
};

我们再看看ngx_command_s的定义：

struct ngx_command_s {
    ngx_str_t             name;
    ngx_uint_t            type;
    char               *(*set)(ngx_conf_t *cf, ngx_command_t *cmd, void *conf);
    ngx_uint_t            conf;
    ngx_uint_t            offset;
    void                 *post;
};

所以，上文我说过，ngx_conf_handler方法会调用每个module里自己实现的set钩子函数，如果我们编译了http module（默认都有），那么就会在ngx_conf_handler方法中调用上面的ngx_http_block函数。这个ngx_http_block函数值得详细说说，因为它这时读取配置文件，决定要监听哪些http端口，它会把这些信息通过传进来的ngx_conf_t指针塞给ngx_cycle这个核心变量。

ngx_event_core_module也是个核心module，之前说到的到底是由epoll、select、poll还是kqueue来实现IO多路复用，就是由这个module来搞定的。

继续向下。ngx_init_cycle函数再来调用所有module实现的init_conf钩子函数。之后，执行到现在nginx进程终于要开始监听端口了。这事很关键，刚刚调用过各个module的set钩子方法了，例如上面http module的ngx_http_block方法，这些方法已经给ngx_cycle的listening数组塞进了需要监听的端口。为什么要现在就开始listen呢？因为现在还没有fork出worker子进程哈。大家知道，linux系统下，fork出的子进程会共享父进程的地址空间，所以，需要在全部worker进程中做的事，就都放到ngx_init_cycle里来做吧。监听的句柄，会被所有nginx worker共享使用的。

监听完指定的端口后，开始调用所有module实现的init_module钩子函数。接下来，要准备进程间通讯的事了。一个master，多个worker，这些进程间通过什么方式通讯呢？这里不展开了，下次再细说。它们也通过共享内存交换数据，这时开始初始化共享内存。终于，ngx_init_cycle执行完了，松口气？

接着，main函数要初始化信号量，进程间的同步都是通过信号量来玩的。然后创建pidfile，这个文件用于启动完成以后通过nginx命令行，对nginx进程发送信号量来控制它。main函数的最后，开始执行ngx_master_process_cycle函数了，这个函数做master进程该做的事。它首先调用ngx_start_worker_processes去启动worker，按照配置文件中配置的worker数量，fork出许多子进程，每个子进程执行ngx_worker_process_cycle函数，这是个死循环函数，将开始处理真正的用户请求。

ngx_master_process_cycle函数再调用ngx_start_cache_manager_processes启动cache的管理进程，这块限于篇幅，下次有空再讲吧。最后，ngx_master_process_cycle进入死循环，开始准备接收信号量传来的命令，以及监控每一个worker的运行状态，如果有worker非正常死掉，还会重新拉起的。

最后声明下，我是以nginx-0.7.65版本做例子来说的，上面列到的源代码文件，都是针对这个版本的。当然，我说的这些都是核心函数，其实1.x版本与之差别非常小。

熟悉了nginx的启动过程，知道它干了哪些事，就可以研究worker进程如何处理用户请求了。