openResty框架整理

openResty框架整理

相关网址

nginx wiki
git仓库位置

HttpLuaModule

This module embeds Lua, via the standard Lua 5.1 interpreter or LuaJIT 2.0/2.1, into Nginx and by leveraging Nginx's subrequests, allows the integration of the powerful Lua threads (Lua coroutines) into the Nginx event model.

Unlike Apache's mod_lua and Lighttpd's mod_magnet, Lua code executed using this module can be 100% non-blocking on network traffic as long as the Nginx API for Lua provided by this module is used to handle requests to upstream services such as MySQL, PostgreSQL, Memcached, Redis, or upstream HTTP web services.

Almost all the Nginx modules can be used with this ngx_lua module by means of ngx.location.capture or ngx.location.capture_multi but it is recommended to use those lua-resty-* libraries instead of creating subrequests to access the Nginx upstream modules because the former is usually much more flexible and memory-efficient.

The Lua interpreter or LuaJIT instance is shared across all the requests in a single nginx worker process but request contexts are segregated using lightweight Lua coroutines.

Loaded Lua modules persist in the nginx worker process level resulting in a small memory footprint in Lua even when under heavy loads.

典型应用：
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 Lua before requests actually reach the upstream backends,
manipulating response headers in an arbitrary way (by Lua)
fetching backend information from external storage backends (like redis, memcached, mysql, postgresql) and use that information to choose which upstream backend to access on-the-fly,
coding up arbitrarily complex web applications in a content handler using synchronous but still non-blocking access to the database backends and other storage,
doing very complex URL dispatch in Lua at rewrite phase,
using Lua to implement advanced caching mechanism for Nginx's subrequests and arbitrary locations

HTTP 1.0 support

The HTTP 1.0 protocol does not support chunked output and requires an explicit Content-Length header when the response body is not empty in order to support the HTTP 1.0 keep-alive. So when a HTTP 1.0 request is made and the lua_http10_buffering directive is turned on, ngx_lua will buffer the output of ngx.say and ngx.print calls and also postpone sending response headers until all the response body output is received. At that time ngx_lua can calculate the total length of the body and construct a proper Content-Length header to return to the HTTP 1.0 client. If the Content-Length response header is set in the running Lua code, however, this buffering will be disabled even if the lua_http10_buffering directive is turned on.

For large streaming output responses, it is important to disable the lua_http10_buffering directive to minimise memory usage.

Note that common HTTP benchmark tools such as ab and http_load issue HTTP 1.0 requests by default. To force curl to send HTTP 1.0 requests, use the -0 option.

Data Sharing within an Nginx Worker

-- mydata.lua
local _M = {}

local data = {
    dog = 3,
    cat = 4,
    pig = 5,
}

function _M.get_age(name)
    return data[name]
end

return _M

此数据在进程间独享。