首先得聲明。這不是我的原創，是在網上搜索到的一篇文章，原著是誰也搞不清楚了。按風格應該是屬於章亦春的文章。
整理花了不少時間，所以就暫寫成原創吧。
一. 概述
Nginx是一個高性能。支持高並發的，輕量級的webserver。眼下，Apache依舊webserver中的老大，可是在全球前1000大的webserver中，Nginx的份額為22.4%。Nginx採用模塊化的架構，官方版本號的Nginx中大部分功能都是通過模塊方式提供的，比方Http模塊、Mail模塊等。通過開發模塊擴展Nginx，能夠將Nginx打造成一個全能的應用server，這樣能夠將一些功能在前端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，事件循環）來實現port的監聽及client請求的處理和響應，同一時候Worker還要處理來自Master的信號。
因為Worker使用單線程處理各種事件。所以一定要保證主循環是非堵塞的，否則會大大減少Worker的響應能力。
Nginx處理Http請求的過程
表面上看，當Nginx處理一個來自client的請求時，先依據請求頭的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 client從 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。
這樣就實現了一個非常easy的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能完畢復雜的訪問控制。比方。訪問數據庫進行username、password驗證等。
配置：
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_cmd get;
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機制。能夠在一次連接中運行多個命令，這樣能夠降低多次運行命令的往返時延。
client在通過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就是定義連接池的大小，當連接數超過這個大小后，興許的連接自己主動退化為短連接。連接池的使用非常easy，直接替換掉原來的ip和port號就可以。 有人以前測過，在沒有使用連接池的情況下，訪問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連接時，盡量使用連接池。
這樣能夠消除大量的建立、釋放連接的開銷。
參考：
http://wiki.nginx.org/HttpUpstreamKeepaliveModule
http://wiki.nginx.org/HttpRedis2Module
http://wiki.nginx.org/HttpMemcModule
原文:
http://blog.angryfox.com/?p=2063