Nginx的内存池实现得很精巧，代码也很简洁。总的来说，所有的内存池基本都一个宗旨：申请大块内存，避免“细水长流”。 一、创建一个内存池 nginx内存池主要有下面两个结构来维护，他们分别维护了内存池的头部和数据部。此处数据部就是供用户分配小块内存的地方。 //该结构用来维护内存池的数据块，供用户分配之用。 typedef struct { u_char *last; //当前内存分配结束位置，即下一段可分配内存的起始位置 u_char *end; //内存池结束位置 ngx_pool_t *next; //链接到下一个内存池 ngx_uint_t failed; //统计该内存池不能满足分配请求的次数 } ngx_pool_data_t; //该结构维护整个内存池的头部信息。 struct ngx_pool_s { ngx_pool_data_t d; //数据块 size_t max; //数据块的大小，即小块内存的最大值 ngx_pool_t *current; //保存当前内存池 ngx_chain_t *chain; //可以挂一个chain结构 ngx_pool_large_t *large; //分配大块内存用，即超过max的内存请求 ngx_pool_cleanup_t *cleanup; //挂载一些内存池释放的时候，同时释放的资源。 ngx_log_t *log; };

Linux平台上，Nginx使用epoll完成事件驱动，实现高并发；本文将不对epoll本身进行介绍（网上一堆一堆的文章介绍epoll的原理及使用方法，甚至源码分析等），仅看一下Nginx是如何使用epoll的。 Nginx在epoll模块中定义了好几个函数，这些函数基本都是作为回调注册到事件抽象层的对应接口上，从而实现了事件驱动的具体化，我们看如下的一段代码： ngx_event_module_t ngx_epoll_module_ctx = { &epoll_name, ngx_epoll_create_conf, /* create configuration */ ngx_epoll_init_conf, /* init configuration */ { ngx_epoll_add_event, /* add an event */ ngx_epoll_del_event, /* delete an event */ ngx_epoll_add_event, /* enable an event */ ngx_epoll_del_event, /* disable an event */ ngx_epoll_add_connection, /* add an connection */ ngx_epoll_del_connection, /* delete an connection */ NULL,

事件循环这个概念貌似在windows编程中提得更多，Linux程序却很少提及这个概念。本文所提及的事件循环其实就是worker cycle，由于此处将关注的不再是worker进程，而是worker进程在循环过程中关于事件处理的环节，因此就盗用了事件循环这个概念。在具体看代码前，先看一下这个“循环”的概貌：

本文的标题让我纠结了好久，不知道是connections数组合适，还是connections链表更合适；Nginx在此或多或少的注入了二者的特点，先不管是叫数组还是叫链表吧，只要能够弄明白这个connections是怎么回事就大功告成。Nginx的每个worker进程都使用一个相同的connections数组来维护每个连接。当有一个新的连接建立时，Nginx需要从这个数组取出一个slot来存放这个连接；相反，有一个连接断开时，也需要将相应的slot归还给connections数组。本文就来看一下这个connections数组是如何构造的，能够让Nginx方便，快速的获取/释放一个slot。我从ngx_event_process_init()函数中拼凑了如下一段代码： /*分配数组*/ cycle->connections = ngx_alloc(sizeof(ngx_connection_t) * cycle->connection_n, cycle->log); if (cycle->connections == NULL) { return NGX_ERROR; } c = cycle->connections; i = cycle->connection_n; next = NULL;

Nginx的高性能应该算是事件驱动的功劳。Nginx事件处理的相关代码位于src/event目录中，事件驱动是Nginx的核心，所以代码量相对也比较大。事件驱动初始化的过程主要由下图中的三步组成。

前面单独分析了master进程和worker的工作情况，本文就大概看一下master进程和worker进程之间是如何使用channel来完成通信的。这部分实现的源码主要分布于src/os/unix/channel.h和channel.c两个文件中。实现极其简单，没有什么复杂的逻辑。下面，我绘制了一个简单的master进程和worker进程间的关系，图中的箭头符号指出数据是由master进程传给worker进程，而没有从worker到master；这是因为channel不是一个普通的数据传输管道，在Nginx中它仅仅是用着master发送指令给worker的一个管道，master借此channel来告诉worker进程该做什么了，worker却不需要告诉master该做什么，所以是一个单向的通道。

上一篇博文分析了master进程，本文着手分析一下worker进程的情况。首先找到worker进程的入口地方——ngx_worker_process_cycle。这个函数不光是worker进程的入口函数，同时也是worker进程循环工作的主体函数，看函数名含有一个cycle嘛。进入这个cycle函数，第一件事就是调用ngx_worker_process_init(cycle, 1);对worker进程进行初始化操作。先看看这个worker进程的初始化过程。

Nginx分为Single和Master两种进程模型，Single模型即为单进程方式工作，具有较差的容错能力，不适合生产之用。Master模型即为一个master进程+N个worker进程的工作方式。生产环境都是用master-worker模型来工作。本文着重分析Nginx的master进程做了哪些事情，它是如何管理好各个worker进程的。在具体分析代码之前，先附上一张master进程的全貌图：

在Nginx启动初始化过程（一）中提到main函数会调用ngx_init_cycle()初始化一个全局cycle变量，本文就来看看这个ngx_init_cycle()函数究竟做了哪些初始化工作。ngx_cycle_t结构类型被定义在src/core/ngx_cycle.h文件中，多达23个成员变量（nginx-0.7.67），由于ngx_init_cycle()函数的代码多达近800行，绝对算大函数了（当然，我也相信还有更加变态的函数，将整个世界都写到一个函数中的情况也是有可能的），在此就挑一些相对关键的代码来看吧。 ngx_timezone_update(); /* force localtime update with a new timezone */ tp = ngx_timeofday(); tp->sec = 0; ngx_time_update(); 这几个函数都是来自于Nginx的时间管理，对时区和时间进行一次更新操作。一个高性能服务器需要合理的调用gettimeofday()，减少gettimeofday()的调用次数有利于提高服务器的性能。Nginx对时间的管理也是值得我们去学习的，这部分代码就放后续分析吧。

Nginx的启动初始化在src/core/nginx.c的main函数中完成，当然main函数是整个Nginx的入口，除了完成启动初始化任务以外，也必定是所有功能模块的入口之处。Nginx的初始化工作主要围绕一个类型为ngx_cycle_t类型的全局变量（cycle）展开。下面具体看一下main函数为Nginx的启动过程做了哪些初始化方面的事情。（以下代码段都是顺序从main函数中摘取出来的， 对照源码阅读可能更易明白）