linux中Nginx與Lua執(zhí)行順序細(xì)解

2024-08-27 23:55:26

字體：大中小

供稿：網(wǎng)友

　　文章從多篇文章中總結(jié)整理出來的關(guān)于linux中Nginx與Lua執(zhí)行順序例子,這些例子對各位同學(xué)都有很好的幫助,有需要的同學(xué)進(jìn)入看看吧.

　　1.1.介紹

　　ngx_lua – 把lua語言嵌入nginx中,使其支持lua來快速開發(fā)基于nginx下的業(yè)務(wù)邏輯,該模塊不在nginx源碼包中，需自行下載編譯安裝。使用lua 5.1（目前不支持lua 5.2）或 luajit 2.0 。

　　添加lua支持后，開發(fā)復(fù)雜的模塊，周期快，依然是100%異步非阻塞。

　　ngx_lua 哪些人在用:淘寶、騰訊財經(jīng)、網(wǎng)易財經(jīng)、360、去哪兒網(wǎng)等

　　CloudFlare, CNN, Wingify, Reblaze, Turner, Broadcasting System

　　該項目主要開發(fā)者:

　　chaoslawful Taobao, Alibaba Grp.

　　agentzh CloudFlare

　　https://github.com/chaoslawful/lua-nginx-module

　　1.2. 安裝

　　1.2.1. 安裝JIT平臺

　　JIT,通常，程序有兩種運(yùn)行方式：靜態(tài)編譯與動態(tài)直譯。

　　靜態(tài)編譯的程序在執(zhí)行前全部被翻譯為機(jī)器碼，而動態(tài)直譯執(zhí)行的則是一句一句邊運(yùn)行邊翻譯。

　　即時編譯(Just-In-Time Compiler)則混合了這二者，一句一句編譯源代碼，但是會將翻譯過的代碼緩存起來以降低性能損耗。

　　JAVA、.NET 實(shí)現(xiàn)都使用即時編譯以提供高速的代碼執(zhí)行。

　　注意:在nginx.conf中添加”lua_code_cache on/off”，來開啟是否將代碼緩存，所以每次變更”*.lua”文件時，必須reload nginx才可生效。僅針對”set_by_lua_file, content_by_lua_file, rewrite_by_lua_file, and access_by_lua_file”有效, 因?yàn)槠渌麨閷懺谂渲梦募校拇a也必須reload nginx。在生產(chǎn)環(huán)境下，不能禁用cache。同時在lua代碼中使用”dofile” 或 “loadfie” 來加載外部lua腳本將不會對它進(jìn)行緩存，應(yīng)該使用”require”來代替。禁用cache，當(dāng)且僅當(dāng)在調(diào)式代碼下。

　　LuaJIT:是一個利用JIT編譯技術(shù)把Lua腳本直接編譯成機(jī)器碼由CPU運(yùn)行.

　　版本:2.0 與 2.1

　　當(dāng)前穩(wěn)定版本為 2.0。

　　2.1為版本與ngx_lua將有較大性能提升,主要是CloudFlare公司對luajit的捐贈.

　　FFI庫,是LuaJIT中最重要的一個擴(kuò)展庫.

　　1. 它允許從純Lua代碼調(diào)用外部C函數(shù)，使用C數(shù)據(jù)結(jié)構(gòu);

　　2. 就不用再像Lua標(biāo)準(zhǔn)math庫一樣，編寫Lua擴(kuò)展庫;

　　3. 把開發(fā)者從開發(fā)Lua擴(kuò)展C庫（語言/功能綁定庫）的繁重工作中釋放出來;

　　1.3. Nginx與Lua執(zhí)行順序

　　1.3.1. Nginx順序

　　Nginx 處理每一個用戶請求時，都是按照若干個不同階段（phase）依次處理的，而不是根據(jù)配置文件上的順序。

　　Nginx 處理請求的過程一共劃分為 11 個階段，按照執(zhí)行順序依次是

　　post-read、server-rewrite、find-config、rewrite、post-rewrite、 preaccess、access、post-access、try-files、content、log.

　　post-read:讀取請求內(nèi)容階段

　　Nginx讀取并解析完請求頭之后就立即開始運(yùn)行,例如模塊 ngx_realip 就在 post-read 階段注冊了處理程序，它的功能是迫使 Nginx 認(rèn)為當(dāng)前請求的來源地址是指定的某一個請求頭的值。

　　server-rewrite

　　Server請求地址重寫階段,當(dāng) ngx_rewrite 模塊的set配置指令直接書寫在 server 配置塊中時，基本上都是運(yùn)行在 server-rewrite 階段

　　find-config:配置查找階段.

　　這個階段并不支持 Nginx 模塊注冊處理程序,而是由 Nginx 核心來完成當(dāng)前請求與 location 配置塊之間的配對工作。

　　rewrite:Location請求地址重寫階段.

　　當(dāng) ngx_rewrite 模塊的指令用于 location 塊中時,便是運(yùn)行在這個 rewrite 階段,另外，ngx_set_misc(設(shè)置md5、encode_base64等) 模塊的指令，還有 ngx_lua 模塊的 set_by_lua 指令和 rewrite_by_lua 指令也在此階段。

　　post-rewrite

　　請求地址重寫提交階段,由 Nginx 核心完成 rewrite 階段所要求的“內(nèi)部跳轉(zhuǎn)”操作,如果 rewrite 階段有此要求的話。

　　preaccess

　　訪問權(quán)限檢查準(zhǔn)備階段,標(biāo)準(zhǔn)模塊 ngx_limit_req 和 ngx_limit_zone 就運(yùn)行在此階段，前者可以控制請求的訪問頻度，而后者可以限制訪問的并發(fā)度。

　　access

　　訪問權(quán)限檢查階段,標(biāo)準(zhǔn)模塊 ngx_access、第三方模塊 ngx_auth_request 以及第三方模塊 ngx_lua 的 access_by_lua 指令就運(yùn)行在這個階段。

　　配置指令多是執(zhí)行訪問控制性質(zhì)的任務(wù)，比如檢查用戶的訪問權(quán)限，檢查用戶的來源 IP 地址是否合法.

　　post-access

　　訪問權(quán)限檢查提交階段,主要用于配合 access 階段實(shí)現(xiàn)標(biāo)準(zhǔn) ngx_http_core 模塊提供的配置指令 satisfy 的功能。

　　satisfy all(與關(guān)系)

　　satisfy any(或關(guān)系)

　　try-files

　　配置項try_files處理階段,專門用于實(shí)現(xiàn)標(biāo)準(zhǔn)配置指令 try_files 的功能,如果前 N-1 個參數(shù)所對應(yīng)的文件系統(tǒng)對象都不存在，try-files 階段就會立即發(fā)起“內(nèi)部跳轉(zhuǎn)”到最后一個參數(shù)（即第 N 個參數(shù)）所指定的 URI.

　　content

　　內(nèi)容產(chǎn)生階段,Nginx 的 content 階段是所有請求處理階段中最為重要的一個，因?yàn)檫\(yùn)行在這個階段的配置指令一般都肩負(fù)著生成“內(nèi)容”并輸出 HTTP 響應(yīng)的使命。

　　log

　　日志模塊處理階段,記錄日志,淘寶有開放一個nginx開發(fā)手冊,里面包含很多有用的資料

　　http://tengine.taobao.org/book/

　　作者的google論壇:https://groups.google.com/forum/#!forum/openresty

　　1.3.2. Lua順序

　　Nginx下Lua處理階段與使用范圍:

　　init_by_lua http
　　set_by_lua server, server if, location, location if
　　rewrite_by_lua http, server, location, location if
　　access_by_lua http, server, location, location if
　　content_by_lua location, location if --phpfensi.com
　　header_filter_by_lua http, server, location, location if
　　body_filter_by_lua http, server, location, location if
　　log_by_lua http, server, location, location if
　　init_by_lua:

　　在nginx重新加載配置文件時，運(yùn)行里面lua腳本，常用于全局變量的申請,例如lua_shared_dict共享內(nèi)存的申請，只有當(dāng)nginx重起后，共享內(nèi)存數(shù)據(jù)才清空，這常用于統(tǒng)計。

　　set_by_lua:

　　設(shè)置一個變量，常用與計算一個邏輯，然后返回結(jié)果,該階段不能運(yùn)行Output API、Control API、Subrequest API、Cosocket API

　　rewrite_by_lua:

　　在access階段前運(yùn)行,主要用于rewrite

　　access_by_lua:

　　主要用于訪問控制,能收集到大部分變量，類似status需要在log階段才有,這條指令運(yùn)行于nginx access階段的末尾,因此總是在 allow 和 deny 這樣的指令之后運(yùn)行，雖然它們同屬 access 階段.

　　content_by_lua:

　　階段是所有請求處理階段中最為重要的一個，運(yùn)行在這個階段的配置指令一般都肩負(fù)著生成內(nèi)容（content）并輸出HTTP響應(yīng)。

　　header_filter_by_lua:

　　一般只用于設(shè)置Cookie和Headers等,該階段不能運(yùn)行Output API、Control API、Subrequest API、Cosocket API.

　　body_filter_by_lua:

　　一般會在一次請求中被調(diào)用多次, 因?yàn)檫@是實(shí)現(xiàn)基于 HTTP 1.1 chunked 編碼的所謂“流式輸出”的。

　　該階段不能運(yùn)行Output API、Control API、Subrequest API、Cosocket API

　　log_by_lua:

　　該階段總是運(yùn)行在請求結(jié)束的時候,用于請求的后續(xù)操作,如在共享內(nèi)存中進(jìn)行統(tǒng)計數(shù)據(jù),如果要高精確的數(shù)據(jù)統(tǒng)計,應(yīng)該使用body_filter_by_lua。

　　該階段不能運(yùn)行Output API、Control API、Subrequest API、Cosocket API。

（編輯：武林網(wǎng)）

上一篇：Linux中安裝GBKGB2312程序亂碼處理方法

下一篇：linux中vagrant創(chuàng)建配置研發(fā)環(huán)境