用lua扩展你的Nginx（整理）

首先得声明，这不是我的原创，是在网上搜索到的一篇文章，原著是谁也搞不清楚了，按风格应该是属于章亦春的文章。

整理花了不少时间，所以就暂写成原创吧。

一. 概述

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

<span style="font-size:10px;">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阶段。

子请求（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   03.  bar

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

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

协程（Coroutine）

协程类似一种多线程，与多线程的区别有： 1. 协程并非os线程，所以创建、切换开销比线程相对要小。 2. 协程与线程一样有自己的栈、局部变量等，但是协程的栈是在用户进程空间模拟的，所以创建、切换开销很小。 3. 多线程程序是多个线程并发执行，也就是说在一瞬间有多个控制流在执行。而协程强调的是一种多个协程间协作的关系，只有当一个协程主动放弃执行权，另一个协程才能获得执行权，所以在某一瞬间，多个协程间只有一个在运行。 4. 由于多个协程时只有一个在运行，所以对于临界区的访问不需要加锁，而多线程的情况则必须加锁。
5. 多线程程序由于有多个控制流，所以程序的行为不可控，而多个协程的执行是由开发者定义的所以是可控的。 Nginx的每个Worker进程都是在epoll或kqueue这样的事件模型之上，封装成协程，每个请求都有一个协程进行处理。这正好与Lua内建协程的模型是一致的，所以即使ngx_lua需要执行Lua，相对C有一定的开销，但依然能保证高并发能力。

三. ngx_lua

原理

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非常适合用于实现可扩展的、高并发的服务。

典型应用

官网上列出：

· 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.

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!")
            ';
        }
    }
}

输出：

$ 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 ...]

配置：

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;
}</span>

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

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‘

$ <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阶段执行。

配置：

location =/foo {
        rewrite_by_lua 'ngx.exec("/bar")';
    echo'in foo';
}

location =/bar {
        echo'in bar';
}

输出：

$ curl ‘localhost/lua‘

$ Hello, Lua!

content_by_lua和content_by_lua_file

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

配置（直接响应）：

location =/lua {
        content_by_lua 'ngx.say("Hello, Lua!")';
}

输出：

$ curl ‘localhost/lua‘

$ Hello, Lua!

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

location =/hello {
        content_by_lua '
            local who = ngx.var.arg_who
            ngx.say("Hello, ", who, "!")
        ';
}

输出：

$ 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）。

配置：

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!

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

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是非阻塞的。

四. 小结

这篇文章简单介绍了一下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。

配置：

#使用HttpMemcModule
location =/memc {
    set$memc_cmd$arg_cmd;
    set$memc_key$arg_key;
    set$memc_value$arg_val;
    set$memc_exptime$arg_exptime;

    memc_pass '127.0.0.1:11211';
}

输出：

$ curl  ‘http://localhost/memc?cmd=set&key=foo&val=Hello‘

$ STORED

$ curl  ‘http://localhost/memc?cmd=get&key=foo‘

$ Hello

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

配置：

#在Lua中访问Memcached
location =/memc {
    internal;   #只能内部访问
    set$memc_cmdget;
    set$memc_key$arg_key;
    memc_pass '127.0.0.1:11211';
}
location =/lua_memc {
    content_by_lua '
        local res = ngx.location.capture("/memc", {
            args = { key = ngx.var.arg_key }
        })
        if res.status == 200 then
            ngx.say(res.body)
        end
    ';
}

输出：

$ 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的原生响应。

配置：

#在Lua中访问Redis
location =/redis {
    internal;   #只能内部访问
    redis2_query get $arg_key;
    redis2_pass '127.0.0.1:6379';
}
location =/lua_redis {#需要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的原生请求查询。

配置：

#在Lua中访问Redis
location =/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

-- conf/pipeline.lua file
local parser=require(‘redis.parser’)
local reqs={
    {‘get’, ‘one’}, {‘get’, ‘two’}
}
-- 构造原生的redis查询，get one\r\nget two\r\n
local raw_reqs={}
for i, req in ipairs(reqs)do
      table.insert(raw_reqs, parser.build_query(req))
end
local 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])
       end
end

输出：

$ curl  ‘http://localhost/pipeline‘

$ first

second

Connection Pool

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

配置：

http {
    # 需要HttpUpstreamKeepaliveModule
    upstream redis_pool {
        server 127.0.0.1:6379;
        # 可以容纳1024个连接的连接池
        keepalive 1024 single;
    }

    server {
        location=/redis {
            …
            redis2_pass redis_pool;
        }
    }
}

这个模块提供keepalive指令，它的context是upstream。我们知道upstream在使用Nginx做反向代理时使用，实际upstream是指“上游”，这个“上游”可以是redis、memcached或是mysql等一些server。upstream可以定义一个虚拟server集群，并且这些后端的server可以享受负载均衡。keepalive 1024就是定义连接池的大小，当连接数超过这个大小后，后续的连接自动退化为短连接。连接池的使用很简单，直接替换掉原来的ip和端口号即可。      有人曾经测过，在没有使用连接池的情况下，访问memcached（使用之前的Memc模块），rps为20000。在使用连接池之后，rps一路飙到140000。在实际情况下，这么大的提升可能达不到，但是基本上100-200%的提高还是可以的。

小结

这里对memcached、redis的访问做个小结。 1. Nginx提供了强大的编程模型，location相当于函数，子请求相当于函数调用，并且location还可以向自己发送子请求，这样构成一个递归的模型，所以采用这种模型实现复杂的业务逻辑。 2. Nginx的IO操作必须是非阻塞的，如果Nginx在那阻着，则会大大降低Nginx的性能。所以在Lua中必须通过ngx.location.capture发出子请求将这些IO操作委托给Nginx的事件模型。
3. 在需要使用tcp连接时，尽量使用连接池。这样可以消除大量的建立、释放连接的开销。

用lua扩展你的Nginx（整理）

时间： 2024-10-11 03:27:44

用lua扩展你的Nginx（整理）的相关文章

玩转 Nginx 之：使用 Lua 扩展 Nginx 功能

1.Nginx 简介 Nginx 作为一款面向性能设计的HTTP服务器,相较于Apache.lighttpd具有占有内存少,稳定性高等优势.其流行度越来越高,应用也越来越广泛,常见的应用有:网页服务器.反向代理服务器以及电子邮件(IMAP/POP3)代理服务器,高并发大流量站点常用来做接入层的负载均衡,还有非常常见的用法是作为日志采集服务器等. Nginx 整体采用模块化设计,有丰富的模块库和第三方模块库,配置灵活.其中模块化设计是nginx的一大卖点,甚至http服务器核心功能也是一个模块.要

手动使用C/C++编写Lua扩展插件

最近在研究如何在Windows 下嵌入Lua来完成业务模块编写的时候 发现Lua的一些问题,首先Lua作为一门脚本语言,其灵活性和可扩展性是很高的,要不然Cocos2d-x中也不会嵌入他来编写业务逻辑,但是由于国内资料相当的少,很少有人去正八经研究完了之后 写一篇文章 来分享自己的成果,想要去深入理解应用一些东西得时候,显得很无力,很多Lua扩展都是直接写扩展库来完成,如果不理解原理甚至你都不会灵活运用,这就是本文写作的目的. 第一 我需要Lua嵌入我的应用程序,这一点很容易的做到. 第二 我需

cocos2d-x 3.3 导入lua扩展库

cocos2d-x 导入lua扩展库有几个点需要注意: 1.cocos2d-x 中的lua版本为5.1.4,所导入的lua库需要对应相应的版本库. 2.在vs 2012 中编译cocos2d-x ,添加的C文件需要注明用C编译,如一般.h文件需要这样写 #ifndef __LUA_LPEG_H_ #define __LUA_LPEG_H_ #if __cplusplus extern "C" { #endif #include "lua.h" #include &q

用Lua扩展谷歌拼音输入法

谷歌拼音输入法最后一次更新是2013年,最近2年毫无动静,这个产品应该已经停了,不过这并不影响对它的使用,我一直喜欢它的简洁和稳定. 说不上来什么原因,忽然想起了摆弄摆弄谷歌拼音输入法的扩展特性(我经常会有这种不明原因地忽然想折腾点什么的状况).于是搜索到官方文档——“谷歌拼音输入法-扩展API开发指南”,粗略阅读了一番.考虑到因为某些不可抗拒的力量,这份文档不会很稳定的存在,所以自己整理一下,权当笔记. 扩展其实很简单,利用API,往谷歌拼音里注册自己写的函数,然后就可以在打字的时候调用了.扩

FFLIB之FFLUA——C++嵌入Lua&amp;扩展Lua利器[转]

摘要: 在使用C++做服务器开发中,经常会使用到脚本技术,Lua是最优秀的嵌入式脚本之一.Lua的轻量.小巧.概念之简单,都使他变得越来越受欢迎.本人也使用过python做嵌入式脚本,二者各有特点,关于python之后会写相关的文章,python对于我而言更喜欢用来编写工具,我前边一些相关的算法也是用python来实现的.今天主要讲Lua相关的开发技术.Lua具有如下特点: Lua 拥有虚拟机的概念,而其全部用标准C实现,不依赖任何库即可编译安装,更令人欣喜的是,整个Lua 的实现代码并不算多,

nginx整理

最近整理了下nginx 关于安全性的一些方法, 隐藏nginx的版本号很简单,nginx的HttpCoreModule提供了一条叫做server_tokens指令,我这要将这条指令设置为"server_tokens off"就可以了. Nginx设置Header头信息 Nginx 使用 ngx_headers_more 模块来增加.删除出站.入站的 Header 信息. ngx_headers_more 项目主页 默认该模块没有加入到 Nginx 的源码中,要想使用相关功能需要在编译

Linux下安装PHP的lua扩展库

一.安装Lua 5.3.4 下载 http://www.lua.org/ftp/lua-5.3.4.tar.gz tar xvf lua-5.3.4.tar.gz cd lua-5.3.4 重要:进入解压缩后的路径 cd .../lua-5.3.4/src 打开Makefile文件 在CFLAG一行 添加选项 -fPIC 像这样: 找到源文件的这行替换掉 CFLAGS= -O2 -Wall -DLUA_COMPAT_ALL $(SYSCFLAGS) -fPIC $(MYCFLAGS) 然后编译.

win7/win8/win10 php5.6 redis扩展(适用于iis/nginx/apache),亲测

win7 php5.6 redis扩展 步骤: 1.下载redis扩展 redis扩展下载地址:http://windows.php.net/downloads/pecl/snaps/redis/ 查看phpinfo下载匹配的版本(一定要选对版本) 2.将下载,解压后的php_redis.dll放入php的ext目录下 3.修改php.ini配置文件,加入extension=php_redis.dll 4.重启服务器(nginx或apache) 5.查看phpinfo看是否扩展成功(下图表示已经

关于lua扩展库lpack的使用指南

最近在研究luasocket,准备用全部用lua的扩展库来实现一套轻量级框架,用来做一些工具.简单的游戏服务器,以及作为网络库用在cocos2dx中. 完善的网络库必然会遇到粘包.半包的问题,luasocket也不例外,由于网络部分在lua,协议的制定和buff的解析都没有合适的方案,又不想在C++中来封装接口,后面在网上查了一些资料,发现lua也有一个二进制打包的扩展库--lpack,了解之后发现还是蛮好用的,就决定使用它来做buff解析,用以解决粘包.半包的问题. 首先需要下载lpack的源