首先得声明,这不是我的原创,是在网上搜索到的一篇文章,原著是谁也搞不清楚了,按风格应该是属于章亦春的文章。
整理花了不少时间,所以就暂写成原创吧。
一. 概述
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的响应能力。
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
4、协程(Coroutine)
协程类似一种多线程,与多线程的区别有:
1. 协程并非os线程,所以创建、切换开销比线程相对要小。
2. 协程与线程一样有自己的栈、局部变量等,但是协程的栈是在用户进程空间模拟的,所以创建、切换开销很小。
3. 多线程程序是多个线程并发执行,也就是说在一瞬间有多个控制流在执行。而协程强调的是一种多个协程间协作的关系,只有当一个协程主动放弃执行权,另一个协程才能获得执行权,所以在某一瞬间,多个协程间只有一个在运行。
4. 由于多个协程时只有一个在运行,所以对于临界区的访问不需要加锁,而多线程的情况则必须加锁。
5. 多线程程序由于有多个控制流,所以程序的行为不可控,而多个协程的执行是由开发者定义的所以是可控的。
Nginx的每个Worker进程都是在epoll或kqueue这样的事件模型之上,封装成协程,每个请求都有一个协程进行处理。这正好与Lua内建协程的模型是一致的,所以即使ngx_lua需要执行Lua,相对C有一定的开销,但依然能保证高并发能力。
三. ngx_lua
1、原理
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!
# nginx.conf
worker_processes 4;
events {
worker_connections 1024;
}
http {
server {
listen 80;
server_name localhost;
location=/lua {
content_by_lua ‘
ngx.say("Hello, Lua!")
';
}
}
}
这样就实现了一个很简单的ngx_lua应用,如果这么简单的模块要是用C来开发的话,代码量估计得有100行左右,从这就可以看出ngx_lua的开发效率。
4. Benchmark
1000 | 3000 | 5000 | 7000 | 10000 | |
nginx 静态文件 | 11351 | 9653 | 8929 | 8997 | 9722 |
nodejs | 10846 | 9510 | 8898 | 8387 | 7820 |
ngx_lua | 13839 | 10174 | 9523 | 10309 | 10711 |
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模块提供了配置指令和Nginx API。
配置指令:在Nginx中使用,和set指令和pass_proxy指令使用方法一样,每个指令都有使用的context。
Nginx API:用于在Lua脚本中访问Nginx变量,调用Nginx提供的函数。
下面举例说明常见的指令和API。
a. set_by_lua和set_by_lua_file
和set指令一样用于设置Nginx变量并且在rewrite阶段执行,只不过这个变量是由lua脚本计算并返回的。
语法:set_by_lua$res
配置:
location = /adder {
set_by_lua $res "
local a = tonumber(ngx.arg[1])
local b = tonumber(ngx.arg[2])
return a + b" $arg_a $arg_b;
echo $res;
}
$ curl 'localhost/adder?a=25&b=75'
$ 100
set_by_lua_file执行Nginx外部的lua脚本,可以避免在配置文件中使用大量的转义。
配置:
location = /fib {
set_by_lua_file $res "conf/adder.lua" $arg_n;
echo $res;
}
adder.lua:
local a = tonumber(ngx.arg[1])
local b = tonumber(ngx.arg[2])
return a + b
输出:
$ curl 'localhost/adder?a=25&b=75
$ 100
b. access_by_lua和access_by_lua_file
运行在access阶段,用于访问控制。Nginx原生的allow和deny是基于ip的,通过access_by_lua能完成复杂的访问控制,比如,访问数据库进行用户名、密码验证等。
配置:
location /auth {
access_by_lua '
if ngx.var.arg_user == "ntes" then
return
else
Ngx.exit(ngx.HTTP_FORBIDDEN)
end
';
echo 'welcome ntes';
}
输出:
$ curl 'localhost/auth?user=sohu'
$ Welcome ntes
$ curl 'localhost/auth?user=ntes'
$
403 Forbidden
403 Forbidden
ngx_openresty/1.0.10.48
c. rewrite_by_lua和rewrite_by_lua_file
实现url重写,在rewrite阶段执行。
配置:
输出:
Contenthandler在content阶段执行,生成http响应。由于content阶段只能有一个handler,所以在与echo模块使用时,不能同时生效,我测试的结果是content_by_lua会覆盖echo。这和之前的hello world的例子是类似的。
配置(直接响应):
Nginx API被封装ngx和ndk两个package中。比如ngx.var.NGX_VAR_NAME可以访问Nginx变量。这里着重介绍一下ngx.location.capture和ngx.location.capture_multi。
a. 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)。
配置:
location = /other {
ehco 'Hello, world!';
}
# Lua非阻塞IO
location = /lua {
content_by_lua '
local res = ngx.location.capture("/other")
if res.status == 200 then
ngx.print(res.body)
end
';
}
$ curl 'http://localhost/lua'
$ Hello, world!
b. ngx.location.capture_multi
语法:res1,res2, ... = ngx.location.capture_multi({ {uri, options?}, {uri, options?}, ...})
与ngx.location.capture功能一样,可以并行的、非阻塞的发出多个子请求。这个方法在所有子请求处理完成后返回,并且整个方法的运行时间取决于运行时间最长的子请求,并不是所有子请求的运行时间之和。
配置:
# 同时发送多个子请求(subrequest)
location = /moon {
ehco 'moon';
}
location = /earth {
ehco 'earth';
}
location = /lua {
content_by_lua '
local res1,res2 = ngx.location.capture_multi({ {"/moon"}, {"earth"} })
if res1.status == 200 then
ngx.print(res1.body)
end
ngx.print(",")
if res2.status == 200 then
ngx.print(res2.body)
end
';
}
输出:
$ 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:
配置:
location / {
internal;
root html;
}
location /capture {
content_by_lua '
res = ngx.location.capture("/")
echo res.body
';
}
通过标准lua io访问磁盘文件:
配置:
location /luaio{
content_by_lua '
local io = require("io")
local chunk_SIZE = 4096
local f = assert(io.open("html/index.html","r"))
while true do
local chunk = f:read(chunk)
if not chunk then
break
end
ngx.print(chunk)
ngx.flush(true)
end
f:close()
';
}
这里通过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是非阻塞的。