转自：http://blog.csdn.net/chosen0ne/article/details/7304192

一. 概述

        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在最后一个。

        每个阶段上可以注册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）。 

       输出：

这里，main location就是发送2个子请求，分别到foo和bar，这就类似一种函数调用。

        “子请求”方式的通信是在同一个虚拟主机内部进行的，所以 Nginx 核心在实现“子请求”的时候，就只调用了若干个 C 函数，完全不涉及任何网络或者 UNIX 套接字（socket）通信。我们由此可以看出“子请求”的执行效率是极高的。

4. 协程（Coroutine）

三. ngx_lua

1. 原理

        ngx_lua将Lua嵌入Nginx，可以让Nginx执行Lua脚本，并且高并发、非阻塞的处理各种请求。Lua内建协程，这样就可以很好的将异步回调转换成顺序调用的形式。ngx_lua在Lua中进行的IO操作都会委托给Nginx的事件模型，从而实现非阻塞调用。开发者可以采用串行的方式编写程序，ngx_lua会自动的在进行阻塞的IO操作时中断，保存上下文；然后将IO操作委托给Nginx事件处理机制，在IO操作完成后，ngx_lua会恢复上下文，程序继续执行，这些操作都是对用户程序透明的。

        每个NginxWorker进程持有一个Lua解释器或者LuaJIT实例，被这个Worker处理的所有请求共享这个实例。每个请求的Context会被Lua轻量级的协程分割，从而保证各个请求是独立的。

        ngx_lua采用“one-coroutine-per-request”的处理模型，对于每个用户请求，ngx_lua会唤醒一个协程用于执行用户代码处理请求，当请求处理完成这个协程会被销毁。每个协程都有一个独立的全局环境（变量空间），继承于全局共享的、只读的“comman data”。所以，被用户代码注入全局空间的任何变量都不会影响其他请求的处理，并且这些变量在请求处理完成后会被释放，这样就保证所有的用户代码都运行在一个“sandbox”（沙箱），这个沙箱与请求具有相同的生命周期。

        得益于Lua协程的支持，ngx_lua在处理10000个并发请求时只需要很少的内存。根据测试，ngx_lua处理每个请求只需要2KB的内存，如果使用LuaJIT则会更少。所以ngx_lua非常适合用于实现可扩展的、高并发的服务。

2. 典型应用

        官网上列出：

·  Mashup'ing and processing outputs of various nginx upstream outputs(proxy, drizzle, postgres, redis, memcached, and etc) in Lua,

·  doing arbitrarily complex access control and security checks in Luabefore requests actually reach the upstream backends,

·  manipulating response headers in an arbitrary way (by Lua)

·  fetching backend information from external storage backends (likeredis, memcached, mysql, postgresql) and use that information to choose whichupstream backend to access on-the-fly,

·  coding up arbitrarily complex web applications in a content handlerusing synchronous but still non-blocking access to the database backends andother storage,

·  doing very complex URL dispatch in Lua at rewrite phase,

·  using Lua to implement advanced caching mechanism for nginxsubrequests and arbitrary locations.

3. Hello Lua！

        配置：

        输出：

        这样就实现了一个很简单的ngx_lua应用，如果这么简单的模块要是用C来开发的话，代码量估计得有100行左右，从这就可以看出ngx_lua的开发效率。

4. Benchmark

        通过和nginx访问静态文件还有nodejs比较，来看一下ngx_lua提供的高并发能力。

        返回的内容都是”Hello World!”，151bytes

        通过.ab -n 60000   取10次平均

        从图表中可以看到，在各种并发条件下ngx_lua的rps都是最高的，并且基本维持在10000rps左右，nginx读取静态文件因为会有磁盘io所以性能略差一些，而nodejs是相对最差的。通过这个简单的测试，可以看出ngx_lua的高并发能力。

        ngx_lua的开发者也做过一个测试对比nginx+fpm+php和nodejs，他得出的结果是ngx_lua可以达到28000rps，而nodejs有10000多一点，php则最差只有6000。可能是有些配置我没有配好导致ngx_lua rps没那么高。

5. ngx_lua安装

        ngx_lua安装可以通过下载模块源码，编译Nginx，但是推荐采用openresty。Openresty就是一个打包程序，包含大量的第三方Nginx模块，比如HttpLuaModule，HttpRedis2Module，HttpEchoModule等。省去下载模块，并且安装非常方便。

        ngx_openresty bundle: openresty

        ./configure --with-luajit&& make && make install

        默认Openresty中ngx_lua模块采用的是标准的Lua5.1解释器，通过--with-luajit使用LuaJIT。

6. ngx_lua的用法

        ngx_lua模块提供了配置指令和Nginx API。

        配置指令：在Nginx中使用，和set指令和pass_proxy指令使用方法一样，每个指令都有使用的context。      

        Nginx API：用于在Lua脚本中访问Nginx变量，调用Nginx提供的函数。

        下面举例说明常见的指令和API。

7. 配置指令

        a. set_by_lua和set_by_lua_file

        和set指令一样用于设置Nginx变量并且在rewrite阶段执行，只不过这个变量是由lua脚本计算并返回的。

        语法：set_by_lua$res <lua-script-str> [$arg1 $arg2 ...]

        配置：

        输出：

        set_by_lua_file执行Nginx外部的lua脚本，可以避免在配置文件中使用大量的转义。

        配置：

        adder.lua:

        输出：

        b. access_by_lua和access_by_lua_file

        运行在access阶段，用于访问控制。Nginx原生的allow和deny是基于ip的，通过access_by_lua能完成复杂的访问控制，比如，访问数据库进行用户名、密码验证等。

        配置：

        输出：

        c. rewrite_by_lua和rewrite_by_lua_file

        实现url重写，在rewrite阶段执行。

        配置：

        输出：

        d. content_by_lua和content_by_lua_file

        Contenthandler在content阶段执行，生成http响应。由于content阶段只能有一个handler，所以在与echo模块使用时，不能同时生效，我测试的结果是content_by_lua会覆盖echo。这和之前的hello world的例子是类似的。

        配置（直接响应）：

        输出：

        配置（在Lua中访问Nginx变量）：

        输出：

8. Nginx API

        在Lua代码中的网络IO操作只能通过Nginx Lua API完成，如果通过标准Lua API会导致Nginx的事件循环被阻塞，这样性能会急剧下降。

        在进行数据量相当小的磁盘IO时可以采用标准Lua io库，但是当读写大文件时这样是不行的，因为会阻塞整个NginxWorker进程。为了获得更大的性能，强烈建议将所有的网络IO和磁盘IO委托给Nginx子请求完成（通过ngx.location.capture）。

        下面通过访问/html/index.html这个文件，来测试将磁盘IO委托给Nginx和通过Lua io直接访问的效率。

        通过ngx.location.capture委托磁盘IO：

        配置：

        通过标准lua io访问磁盘文件：

        配置：

        这里通过ab去压，在各种并发条件下，分别返回151bytes、151000bytes的数据，取10次平均，得到两种方式的rps。

        静态文件：151bytes

        静态文件：151000bytes，在10000并发下内存占用情况太严重，测不出结果        这种情况下，文件较小，通过Nginx访问静态文件需要额外的系统调用，性能略逊于ngx_lua。 

        在大文件的情况，capture就要略好于ngx_lua。

        这里没有对Nginx读取静态文件进行优化配置，只是采用了sendfile。如果优化一下，可能nginx读取静态文件的性能会更好一些，这个目前还不熟悉。所以，在Lua中进行各种IO时，都要通过ngx.location.capture发送子请求委托给Nginx事件模型，这样可以保证IO是非阻塞的。

四. 小结

        注： 关于子请求的描述摘自agentzh的博客： http://blog.sina.com.cn/s/blog_6d579ff40100wqn7.html

                 进程模型的图摘自Joshua Zhu的ppt： http://www.slideshare.net/joshzhu/nginx-internals