使用ngx_lua构建高并发应用（1）

一. 概述

        Nginx是一个高性能，支持高并发的，轻量级的web服务器。目前，Apache依然web服务器中的老大，但是在全球前1000大的web服务器中，Nginx的份额为22.4%。Nginx采用模块化的架构，官方版本的Nginx中大部分功能都是通过模块方式提供的，比如Http模块、Mail模块等。通过开发模块扩展Nginx，可以将Nginx打造成一个全能的应用服务器，这样可以将一些功能在前端Nginx反向代理层解决，比如登录校验、js合并、甚至数据库访问等等。

        但是，Nginx模块需要用C开发，而且必须符合一系列复杂的规则，最重要的用C开发模块必须要熟悉Nginx的源代码，使得开发者对其望而生畏。淘宝的agentzh和chaoslawful开发的ngx_lua模块通过将lua解释器集成进Nginx，可以采用lua脚本实现业务逻辑，由于lua的紧凑、快速以及内建协程，所以在保证高并发服务能力的同时极大地降低了业务逻辑实现成本。

        本文向大家介绍ngx_lua，以及我在使用它开发项目的过程中遇到的一些问题。

二. 准备

        首先，介绍一下Nginx的一些特性，便于后文介绍ngx_lua的相关特性。

1. Nginx进程模型

        Nginx采用多进程模型，单Master—多Worker，由Master处理外部信号、配置文件的读取及Worker的初始化，Worker进程采用单线程、非阻塞的事件模型（Event Loop，事件循环）来实现端口的监听及客户端请求的处理和响应，同时Worker还要处理来自Master的信号。由于Worker使用单线程处理各种事件，所以一定要保证主循环是非阻塞的，否则会大大降低Worker的响应能力。

图1

2. Nginx处理Http请求的过程

        表面上看，当Nginx处理一个来自客户端的请求时，先根据请求头的host、ip和port来确定由哪个server处理，确定了server之后，再根据请求的uri找到对应的location，这个请求就由这个location处理。实际Nginx将一个请求的处理划分为若干个不同阶段（phase），这些阶段按照前后顺序依次执行，也就是说NGX_HTTP_POST_READ_PHASE在第一个，NGX_HTTP_LOG_PHASE在最后一个。

NGX_HTTP_POST_READ_PHASE,     //0读取请求phase      
NGX_HTTP_SERVER_REWRITE_PHASE,//1这个阶段主要是处理全局的(server block)的rewrite
NGX_HTTP_FIND_CONFIG_PHASE,   //2这个阶段主要是通过uri来查找对应的location，然后根据loc_conf设置r的相应变量  
NGX_HTTP_REWRITE_PHASE,       //3这个主要处理location的rewrite
NGX_HTTP_POST_REWRITE_PHASE,  //4postrewrite，这个主要是进行一些校验以及收尾工作，以便于交给后面的模块。
NGX_HTTP_PREACCESS_PHASE,     //5比如流控这种类型的access就放在这个phase，也就是说它主要是进行一些比较粗粒度的access。
NGX_HTTP_ACCESS_PHASE,        //6这个比如存取控制，权限验证就放在这个phase，一般来说处理动作是交给下面的模块做的.这个主要是做一些细粒度的access   
NGX_HTTP_POST_ACCESS_PHASE,   //7一般来说当上面的access模块得到access_code之后就会由这个模块根据access_code来进行操作
NGX_HTTP_TRY_FILES_PHASE,     //8try_file模块，就是对应配置文件中的try_files指令，可接收多个路径作为参数，当前一个路径的资源无法找到，则自动查找下一个路径
NGX_HTTP_CONTENT_PHASE,       //9内容处理模块
NGX_HTTP_LOG_PHASE            //10log模块  

        每个阶段上可以注册handler，处理请求就是运行每个阶段上注册的handler。Nginx模块提供的配置指令只会一般只会注册并运行在其中的某一个处理阶段。比如，set指令属于rewrite模块的，运行在rewrite阶段，deny和allow运行在access阶段。

3. 子请求（subrequest）

        其实在Nginx 世界里有两种类型的“请求”，一种叫做“主请求”（main request），而另一种则叫做“子请求”（subrequest）。

        所谓“主请求”，就是由 HTTP 客户端从 Nginx 外部发起的请求。比如，从浏览器访问Nginx就是一个“主请求”。

        而“子请求”则是由 Nginx 正在处理的请求在 Nginx 内部发起的一种级联请求。“子请求”在外观上很像 HTTP 请求，但实现上却和 HTTP 协议乃至网络通信一点儿关系都没有。它是 Nginx 内部的一种抽象调用，目的是为了方便用户把“主请求”的任务分解为多个较小粒度的“内部请求”，并发或串行地访问多个 location 接口，然后由这些 location 接口通力协作，共同完成整个“主请求”。当然，“子请求”的概念是相对的，任何一个“子请求”也可以再发起更多的“子子请求”，甚至可以玩递归调用（即自己调用自己）。当一个请求发起一个“子请求”的时候，按照 Nginx 的术语，习惯把前者称为后者的“父请求”（parent request）。 

    location /main {
        echo_location /foo; 	# echo_location发送子请求到指定的location
        echo_location /bar;
    }
    location /foo {
        echo foo;
    }
    location /bar {
        echo bar;
    }

       输出：

$ curl location/main
$ foo
  bar

这里，main location就是发送2个子请求，分别到foo和bar，这