用lua扩展你的Nginx(写的非常好)

Lua 2020-08-24

一. 概述

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的相关特性。


Nginx进程模型

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

Nginx处理Http请求的过程

表面上看，当Nginx处理一个来自客户端的请求时，先根据请求头的host、ip和port来确定由哪个server处理，确定了server之后，再根据请求的uri找到对应的location，这个请求就由这个location处理。实际Nginx将一个请求的处理划分为若干个不同阶段（phase），这些阶段按照前后顺序依次执行，也就是说NGX_HTTP_POST_READ_PHASE在第一个，NGX_HTTP_LOG_PHASE在最后一个。
[plain]  view plain  copy
  1. <span style="font-size:10px;">NGX_HTTP_POST_READ_PHASE,     //0读取请求phaseNGX_HTTP_SERVER_REWRITE_PHASE,//1这个阶段主要是处理全局的(server block)的rewriteNGX_HTTP_FIND_CONfig_PHASE,   //2这个阶段主要是通过uri来查找对应的location，然后根据loc_conf设置r的相应变量NGX_HTTP_REWRITE_PHASE,       //3这个主要处理location的rewriteNGX_HTTP_POST_REWRITE_PHASE,  //4postrewrite，这个主要是进行一些校验以及收尾工作，以便于交给后面的模块。NGX_HTTP_PREACCESS_PHASE,     //5比如流控这种类型的access就放在这个phase，也就是说它主要是进行一些比较粗粒度的access。NGX_HTTP_ACCESS_PHASE,        //6这个比如存取控制，权限验证就放在这个phase，一般来说处理动作是交给下面的模块做的.这个主要是做一些细粒度的accessNGX_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阶段。


子请求（subrequest）
 其实在Nginx 世界里有两种类型的“请求”，一种叫做“主请求”（main request），而另一种则叫做“子请求”（subrequest）。 所谓“主请求”，就是由 HTTP 客户端从 Nginx 外部发起的请求。比如，从浏览器访问Nginx就是一个“主请求”。 而“子请求”则是由 Nginx 正在处理的请求在 Nginx 内部发起的一种级联请求。“子请求”在外观上很像 HTTP 请求，但实现上却和 HTTP 协议乃至网络通信一点儿关系都没有。它是 Nginx 内部的一种抽象调用，目的是为了方便用户把“主请求”的任务分解为多个较小粒度的“内部请求”，并发或串行地访问多个 location 接口，然后由这些 location 接口通力协作，共同完成整个“主请求”。当然，“子请求”的概念是相对的，任何一个“子请求”也可以再发起更多的“子子请求”，甚至可以玩递归调用（即自己调用自己）。

当一个请求发起一个“子请求”的时候，按照 Nginx 的术语，习惯把前者称为后者的“父请求”（parent request）。

官网上列出： 

· 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,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.
Hello Lua！
输出：
$ curl 'localhost/lua'
Hello，Lua！

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

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没那么高。
 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。
ngx_lua的用法
ngx_lua模块提供了配置指令和Nginx API。 配置指令：在Nginx中使用，和set指令和pass_proxy指令使用方法一样，每个指令都有使用的context。        Nginx API：用于在Lua脚本中访问Nginx变量，调用Nginx提供的函数。 下面举例说明常见的指令和API。

配置指令

set_by_lua和set_by_lua_file

和set指令一样用于设置Nginx变量并且在rewrite阶段执行，只不过这个变量是由lua脚本计算并返回的。
语法：set_by_lua$res <lua-script-str> [$arg1 $arg2 ...]
 配置：

$ 100

set_by_lua_file执行Nginx外部的lua脚本，可以避免在配置文件中使用大量的转义。
copy
    location =/fib {        set_by_lua_file $res "conf/adder.lua" $arg_n;        echo $res;}</span>  


adder.lua:

$ 100

access_by_lua和access_by_lua_file

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

输出：
$ curl 'localhost/auth?user=sohu'
$ Welcome ntes

$ curl 'localhost/auth?user=ntes'
$ <html>
<head><title>403 Forbidden</title></heda>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>ngx_openresty/1.0.10.48</center>
</body>
</html>

 rewrite_by_lua和rewrite_by_lua_file

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

配置：
输出：
$ curl 'localhost/lua'
$ Hello,Lua!

content_by_lua和content_by_lua_file

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


配置（直接响应）：

输出：
$ curl 'localhost/lua'
$ Hello,Lua!

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

输出：
$ curl 'localhost/hello?who=world
$ Hello,world!

Nginx API
Nginx API被封装ngx和ndk两个package中。比如ngx.var.NGX_VAR_NAME可以访问Nginx变量。这里着重介绍一下ngx.location.capture和ngx.location.capture_multi。

ngx.location.capture
语法：res= ngx.location.capture(uri,options?)     用于发出一个同步的，非阻塞的Nginxsubrequest（子请求）。可以通过Nginx subrequest向其它location发出非阻塞的内部请求，这些location可以是配置用于读取文件夹的，也可以是其它的C模块，比如ngx_proxy,ngx_fastcgi,ngx_memc,ngx_postgres,ngx_drizzle甚至是ngx_lua自己。     Subrequest只是模拟Http接口，并没有额外的Http或者Tcp传输开销，它在C层次上运行，非常高效。Subrequest不同于Http 301/302重定向，以及内部重定向（通过ngx.redirection）。

配置：

输出：
$ curl  'http://localhost/lua'
$ Hello,world!

实际上，location可以被外部的Http请求调用，也可以被内部的子请求调用。每个location相当于一个函数，而发送子请求就类似于函数调用，而且这种调用是非阻塞的，这就构造了一个非常强大的变成模型，后面我们会看到如何通过location和后端的memcached、redis进行非阻塞通信。
ngx.location.capture_multi

语法：res1,res2,... = ngx.location.capture_multi({ {uri,options?},{uri,...})     与ngx.location.capture功能一样，可以并行的、非阻塞的发出多个子请求。这个方法在所有子请求处理完成后返回，并且整个方法的运行时间取决于运行时间最长的子请求，并不是所有子请求的运行时间之和。

配置：


输出：
$ curl  'http://localhost/lua'
$ moon,earth

注意
在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：

 copy
    location / {    internal;    root html;}location /capture {    content_by_lua '        res = ngx.location.capture("/")        echo res.body    ';}  
通过标准lua io访问磁盘文件：

配置：

这里通过ab去压，在各种并发条件下，分别返回151bytes、151000bytes的数据，取10次平均，得到两种方式的rps。     静态文件：151bytes
1000 3000 5000 7000 10000  capture  11067 8880 8873 8952 9023  Lua io     11379 9724 8938 9705 9561

静态文件：151000bytes，在10000并发下内存占用情况太严重，测不出结果        这种情况下，文件较小，通过Nginx访问静态文件需要额外的系统调用，性能略逊于ngx_lua。
1000 3000 5000 7000    10000  capture    3338 3435 3178 3043         /  Lua io      3174 3094 3081 2916         /

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

 四. 小结

这篇文章简单介绍了一下ngx_lua的基本用法，后一篇会对ngx_lua访问redis、memcached已经连接池进行详细介绍。

 五. 进阶

在之前的文章中，已经介绍了ngx_lua的一些基本介绍，这篇文章主要着重讨论一下如何通过ngx_lua同后端的memcached、redis进行非阻塞通信。
 Memcached

在Nginx中访问Memcached需要模块的支持，这里选用HttpMemcModule，这个模块可以与后端的Memcached进行非阻塞的通信。我们知道官方提供了Memcached，这个模块只支持get操作，而Memc支持大部分Memcached的命令。 Memc模块采用入口变量作为参数进行传递，所有以$memc_为前缀的变量都是Memc的入口变量。memc_pass指向后端的Memcached Server。

配置：
输出：
$ curl  'http://localhost/memc?cmd=set&key=foo&val=Hello'
$ STORED
$ curl  'http://localhost/memc?cmd=get&key=foo'
$ Hello

这就实现了memcached的访问，下面看一下如何在lua中访问memcached。

配置：

输出：
$ curl  'http://localhost/lua_memc?key=foo'
$ Hello

通过lua访问memcached，主要是通过子请求采用一种类似函数调用的方式实现。首先，定义了一个memc location用于通过后端memcached通信，就相当于memcached storage。由于整个Memc模块时非阻塞的，ngx.location.capture也是非阻塞的，所以整个操作非阻塞。
 Redis

访问redis需要HttpRedis2Module的支持，它也可以同redis进行非阻塞通行。不过，redis2的响应是redis的原生响应，所以在lua中使用时，需要解析这个响应。可以采用LuaRedismodule，这个模块可以构建redis的原生请求，并解析redis的原生响应。

配置：
dis {#需要LuaRedisParser    content_by_lua '        local parser = require("redis.parser")        local res = ngx.location.capture("/redis", {            args = { key = ngx.var.arg_key }        })        if res.status == 200 then            reply = parser.parse_reply(res.body)            ngx.say(reply)        end    ';}  

输出：
$ curl  'http://localhost/lua_redis?key=foo'
$ Hello

和访问memcached类似，需要提供一个redis storage专门用于查询redis，然后通过子请求去调用redis。

Redis Pipeline
在实际访问redis时，有可能需要同时查询多个key的情况。我们可以采用ngx.location.capture_multi通过发送多个子请求给redis storage，然后在解析响应内容。但是，这会有个限制，Nginx内核规定一次可以发起的子请求的个数不能超过50个，所以在key个数多于50时，这种方案不再适用。
幸好redis提供pipeline机制，可以在一次连接中执行多个命令，这样可以减少多次执行命令的往返时延。客户端在通过pipeline发送多个命令后，redis顺序接收这些命令并执行，然后按照顺序把命令的结果输出出去。在lua中使用pipeline需要用到redis2模块的redis2_raw_queries进行redis的原生请求查询。

 copy
    #在Lua中访问Redislocation =/redis {    internal;   #只能内部访问    redis2_raw_queries $args$echo_request_body;    redis2_pass '127.0.0.1:6379';}location =/pipeline {    content_by_lua 'conf/pipeline.lua';}  

pipeline.lua

copy
    -- conf/pipeline.lua filelocal parser=require(‘redis.parser’)local reqs={    {‘get’, ‘one’}, {‘get’, ‘two’}}-- 构造原生的redis查询，get one\r\nget two\r\nlocal raw_reqs={}for i, req in ipairs(reqs)do      table.insert(raw_reqs, parser.build_query(req))endlocal res=ngx.location.capture(‘/redis?’..#reqs, {body=table.concat(raw_reqs, ‘’)})if res.status and res.body then       -- 解析redis的原生响应       local replies=parser.parse_replies(res.body, #reqs)       for i, reply in ipairs(replies)do          ngx.say(reply[1])       endend  

输出：
$ curl  'http://localhost/pipeline'
$ first
  second

 Connection Pool

前面访问redis和memcached的例子中，在每次处理一个请求时，都会和后端的server建立连接，然后在请求处理完之后这个连接就会被释放。这个过程中，会有3次握手、timewait等一些开销，这对于高并发的应用是不可容忍的。这里引入connection pool来消除这个开销。 连接池需要HttpUpstreamKeepaliveModule模块的支持。

配置：