可乐爱上咖啡

俄罗斯大牛在nginx中给我们封装了非常好用的数组，在做nginx模块开发的时候，不必再使用原始的数组了。nginx使用以下结构来维护数组 struct ngx_array_s { void *elts; ngx_uint_t nelts; size_t size; ngx_uint_t nalloc; ngx_pool_t *pool;}; elts指向一块向系统申请的内存；在nginx中，这块内存是通过malloc

<br />所谓神图就是只有自己才能看懂的图，哈哈。此图描述的是nginx配置文件解析过程生成的内存模型图，所有的配置数据，模块handler等信息都是存储在这个图中的。<br /> <br /><br /> <br /> 

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

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进程的情况。首先找到worker进程的入口地方——ngx_worker_process_cycle。这个函数不光是worker进程的入口函数，同时也是worker进程循环工作的主体函数，看函数名含有一个cycle嘛。进入这个cycle函数，第一件事就是调用ngx_worker_process_init(cycle, 1);对worker进程进行初始化操作。先看看这个worker进程的初始化过程。

Nginx虽然有着多种进程模型，但生产环境一般都是用master-worker模型来工作。本文着重分析Nginx的master进程做了哪些事情，它是如何管理好各个worker进程的。我们知道在main函数中完成了Nginx启动初始化过程，启动初始化过程中的一个重要环节就是解析配置文件，回调各个配置指令的回调函数，因此完成了各个模块的配置及相互关联。在所有的这些重要及不重要的初始化完成后，main函数就开始为我们打开进程的“大门”——调用ngx_master_process_cycle(cycle); 接下来

在Nginx启动初始化过程（一）中提到main函数会调用ngx_init_cycle()初始化一个全局cycle变量，本文就来看看这个ngx_init_cycle()函数究竟做了哪些初始化工作。ngx_cycle_t结构类型被定义在src/core/ngx_cycle.h文件中，多达23个成员变量（nginx-0.7.67），初次目睹这个结构类型的时候，最让我震惊的是成员变量void ****conf_ctx，想必大家都知道我为何而震惊了吧，也许仅仅只是我见识太少吧，呵呵。由于ngx_init_cycle(

Nginx的启动初始化在src/core/nginx.c的main函数中完成，当然main函数是整个Nginx的入口，除了完成启动初始化任务以外，也必定是所有功能模块的入口之处。Nginx的初始化工作主要围绕一个类型为ngx_cycle_t类型的全局变量（cycle）展开。下面具体看一下main函数为Nginx的启动过程做了哪些初始化方面的事情。main函数做的第一件事情就是对参数选项进行处理，和普通的Linux程序如出一辙，如下：if (ngx_get_options(argc, argv) != NGX

转载申明：本文可以任意转载，但需注明原文地址，谢谢！Nginx的内存池实现得很精巧，代码也很简洁。总的来说，所有的内存池基本都一个宗旨：申请大块内存，避免“细水长流”。一、创建一个内存池nginx内存池主要有下面两个结构来维护，他们分别维护了内存池的头部和数据部。此处数据部就是供用户分配小块内存的地方。

Linux平台上，Nginx使用epoll完成事件驱动，实现高并发；本文将不对epoll本身进行介绍（网上一堆一堆的文章介绍epoll的原理及使用方法，甚至源码分析等），仅看一下Nginx是如何使用epoll的。

本文的标题让我纠结了好久，不知道是connections数组合适，还是connections链表更合适；Nginx在此或多或少的注入了二者的特点，先不管是叫数组还是叫链表吧，只要能够弄明白这个connections是怎么回事就大功告成。Nginx的每个worker进程都使用一个相同的connections数组来维护每个连接。当有一个新的连接建立时，Nginx需要从这个数组取出一个slot来存放这个连接；相反，有一个连接断开时，也需要将相应的slot归还给connections数组。本文就来看一下这个conn

nginx封装的list和我们在学习数据结构时的list略有点区别。nginx的list算是数组和链表的结合。其用以下两个结构来维护一个list。struct ngx_list_part_s { void *elts; ngx_uint_t nelts; ngx_list_part_t *next;};typedef struct { ngx_list_part_t *last; ngx_list_par

前不久Nginx官方放出了SPDY的patch，到目前为止都还未合并进nginx源码，主要还是由于此patch还远不成熟，代码和功能都还不足够完善。个人感觉spdy patch合并进nginx源码还有些时日。本文是基于目前的patch，初窥一下nginx官方是如何在实现spdy。上图是nginx处理一个请求的大致流程，这里只是绘制了简单的模型，实际过程还是相当的复杂的。图中