linux中Nginx與Lua執行順序詳解

2024-08-27 23:55:36

字體：大中小

來源：轉載

供稿：網友

　　文章從多篇文章中總結整理出來的關于linux中Nginx與Lua執行順序例子,這些例子對各位同學都有很好的幫助,有需要的同學進入看看吧.

　　1.1.介紹

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

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

　　ngx_lua 哪些人在用:淘寶、騰訊財經、網易財經、360、去哪兒網等

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

　　該項目主要開發者:

　　chaoslawful Taobao, Alibaba Grp.

　　agentzh CloudFlare

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

　　1.2. 安裝

　　1.2.1. 安裝JIT平臺

　　JIT,通常，程序有兩種運行方式：靜態編譯與動態直譯。

　　靜態編譯的程序在執行前全部被翻譯為機器碼，而動態直譯執行的則是一句一句邊運行邊翻譯。

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

　　JAVA、.NET 實現都使用即時編譯以提供高速的代碼執行。

　　注意:在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”有效, 因為其他為寫在配置文件中，更改代碼也必須reload nginx。在生產環境下，不能禁用cache。同時在lua代碼中使用”dofile” 或 “loadfie” 來加載外部lua腳本將不會對它進行緩存，應該使用”require”來代替。禁用cache，當且僅當在調式代碼下。

　　LuaJIT:是一個利用JIT編譯技術把Lua腳本直接編譯成機器碼由CPU運行.

　　版本:2.0 與 2.1

　　當前穩定版本為 2.0。

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

　　FFI庫,是LuaJIT中最重要的一個擴展庫.

　　1. 它允許從純Lua代碼調用外部C函數，使用C數據結構;

　　2. 就不用再像Lua標準math庫一樣，編寫Lua擴展庫;

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

　　1.3. Nginx與Lua執行順序

　　1.3.1. Nginx順序

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

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

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

　　post-read:讀取請求內容階段

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

　　server-rewrite

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

　　find-config:配置查找階段.

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

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

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

　　post-rewrite

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

　　preaccess

　　訪問權限檢查準備階段,標準模塊 ngx_limit_req 和 ngx_limit_zone 就運行在此階段，前者可以控制請求的訪問頻度，而后者可以限制訪問的并發度。

　　access

　　訪問權限檢查階段,標準模塊 ngx_access、第三方模塊 ngx_auth_request 以及第三方模塊 ngx_lua 的 access_by_lua 指令就運行在這個階段。

　　配置指令多是執行訪問控制性質的任務，比如檢查用戶的訪問權限，檢查用戶的來源 IP 地址是否合法.

　　post-access

　　訪問權限檢查提交階段,主要用于配合 access 階段實現標準 ngx_http_core 模塊提供的配置指令 satisfy 的功能。

　　satisfy all(與關系)

　　satisfy any(或關系)

　　try-files

　　配置項try_files處理階段,專門用于實現標準配置指令 try_files 的功能,如果前 N-1 個參數所對應的文件系統對象都不存在，try-files 階段就會立即發起“內部跳轉”到最后一個參數（即第 N 個參數）所指定的 URI.

　　content

　　內容產生階段,Nginx 的 content 階段是所有請求處理階段中最為重要的一個，因為運行在這個階段的配置指令一般都肩負著生成“內容”并輸出 HTTP 響應的使命。

　　log

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

　　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重新加載配置文件時，運行里面lua腳本，常用于全局變量的申請,例如lua_shared_dict共享內存的申請，只有當nginx重起后，共享內存數據才清空，這常用于統計。

　　set_by_lua:

　　設置一個變量，常用與計算一個邏輯，然后返回結果,該階段不能運行Output API、Control API、Subrequest API、Cosocket API

　　rewrite_by_lua:

　　在access階段前運行,主要用于rewrite

　　access_by_lua:

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

　　content_by_lua:

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

　　header_filter_by_lua:

　　一般只用于設置Cookie和Headers等,該階段不能運行Output API、Control API、Subrequest API、Cosocket API.

　　body_filter_by_lua:

　　一般會在一次請求中被調用多次, 因為這是實現基于 HTTP 1.1 chunked 編碼的所謂“流式輸出”的。

　　該階段不能運行Output API、Control API、Subrequest API、Cosocket API

　　log_by_lua:

　　該階段總是運行在請求結束的時候,用于請求的后續操作,如在共享內存中進行統計數據,如果要高精確的數據統計,應該使用body_filter_by_lua。

　　該階段不能運行Output API、Control API、Subrequest API、Cosocket API。

（編輯：武林網）

上一篇：Linux中安裝GBKGB2312程序亂碼解決方法

下一篇：linux中vagrant創建配置開發環境