一.Nginx是什么，常用于哪些場景及其優(yōu)點是什么江滨？铛纬？

高性能web服務器，常用于 靜態(tài)web服務器（動靜分離）唬滑、反向代理和負載均衡服務器告唆、OpenAPI網(wǎng)關；優(yōu)點有5個：高并發(fā)和高性能晶密、高穩(wěn)定性擒悬、高可擴展性、熱部署和熱升級稻艰、開源免費懂牧。

基于異步非阻塞的事件驅(qū)動模型（master-worker模式）

嚴格的來說，Nginx 應該叫做 HTTP Server尊勿； Tomcat 則是一個Application Server僧凤。

Nginx 整體采用模塊化設計畜侦，有豐富的模塊庫和第三方模塊庫，配置靈活;Nginx在處理每一個用戶請求時躯保，都是按照若干個不同的階段依次處理的旋膳，與配置文件上的順序沒有關系，詳細內(nèi)容可以閱讀《深入理解nginx:模塊開發(fā)與架構(gòu)解析》這本書吻氧。

Nginx把所有功能都統(tǒng)一抽象成模塊溺忧，即“萬物皆模塊”。每個模塊僅僅完成一個獨立盯孙、簡單的功能（說白點鲁森，就是一個功能模塊不能占用cpu時間太長）。

對于一個HTTP請求來說振惰，需要我們考慮的內(nèi)容很多歌溉，因此Nginx將HTTP請求劃分成以下11個階段，每個階段只處理很簡單的功能.

NGX_HTTP_POST_READ_PHASE: 接收完請求頭之后的第一個階段骑晶，它位于uri重寫之前痛垛，實際上很少有模塊會注冊在該階段，默認的情況下桶蛔，該階段被跳過匙头。

NGX_HTTP_SERVER_REWRITE_PHASE: server級別的uri重寫階段，也就是該階段執(zhí)行處于server塊內(nèi)仔雷，location塊外的重寫指令蹂析，在讀取請求頭的過程中nginx會根據(jù)host及端口找到對應的虛擬主機配置

NGX_HTTP_FIND_CONFIG_PHASE: 尋找location配置階段，該階段使用重寫之后的uri來查找對應的location碟婆，值得注意的是該階段可能會被執(zhí)行多次电抚，因為也可能有l(wèi)ocation級別的重寫指令

NGX_HTTP_REWRITE_PHASE: location級別的uri重寫階段，該階段執(zhí)行l(wèi)ocation基本的重寫指令竖共，也可能會被執(zhí)行多次

NGX_HTTP_POST_REWRITE_PHASE: location級別重寫的后一階段蝙叛，用來檢查上階段是否有uri重寫，并根據(jù)結(jié)果跳轉(zhuǎn)到合適的階段

NGX_HTTP_PREACCESS_PHASE: 訪問權(quán)限控制的前一階段公给，該階段在權(quán)限控制階段之前借帘，一般也用于訪問控制，比如限制訪問頻率淌铐，鏈接數(shù)等

NGX_HTTP_ACCESS_PHASE: 訪問權(quán)限控制階段肺然，比如基于ip黑白名單的權(quán)限控制，基于用戶名密碼的權(quán)限控制等

NGX_HTTP_POST_ACCESS_PHASE: 問權(quán)限控制的后一階段匣沼，該階段根據(jù)權(quán)限控制階段的執(zhí)行結(jié)果進行相應處理

NGX_HTTP_TRY_FILES_PHASE: try_files指令的處理階段，如果沒有配置try_files指令捂龄，則該階段被跳過 NGX_HTTP_CONTENT_PHASE: 內(nèi)容生成階段释涛，該階段產(chǎn)生響應加叁，并發(fā)送到客戶端

NGX_HTTP_LOG_PHASE: 日志記錄階段，該階段記錄訪問日志

二.反向代理和負載均衡

反向代理：代理上游服務器（正向代理：代理客戶端）（proxy_pass）

負載均衡：客戶端的請求量即為負載唇撬，將負載分配到集群中的服務器即為負載均衡

Nginx支持的負載均衡調(diào)度算法方式如下：

weight輪詢(默認)：

接收到的請求按照順序逐一分配到不同的后端服務器它匕，即使在使用過程中，某一臺后端服務器宕機窖认，Nginx會自動將該服務器剔除出隊列豫柬，請求受理情況不會受到任何影響。 這種方式下扑浸，可以給不同的后端服務器設置一個權(quán)重值(weight)烧给，用于調(diào)整不同的服務器上請求的分配率；權(quán)重數(shù)據(jù)越大喝噪，被分配到請求的幾率越大础嫡；該權(quán)重值，主要是針對實際工作環(huán)境中不同的后端服務器硬件配置進行調(diào)整的酝惧。

ip_hash：

每個請求按照發(fā)起客戶端的ip的hash結(jié)果進行匹配榴鼎，這樣的算法下一個固定ip地址的客戶端總會訪問到同一個后端服務器，這也在一定程度上解決了集群部署環(huán)境下session共享的問題晚唇。

fair：智能調(diào)整調(diào)度算法

動態(tài)的根據(jù)后端服務器的請求處理到響應的時間進行均衡分配巫财，響應時間短處理效率高的服務器分配到請求的概率高，響應時間長處理效率低的服務器分配到的請求少哩陕；結(jié)合了前兩者的優(yōu)點的一種調(diào)度算法平项。但是需要注意的是Nginx默認不支持fair算法，如果要使用這種調(diào)度算法萌踱，請安裝upstream_fair模塊葵礼。

url_hash：

按照訪問的url的hash結(jié)果分配請求，每個請求的url會指向后端固定的某個服務器并鸵，可以在Nginx作為靜態(tài)服務器的情況下提高緩存效率鸳粉。同樣要注意Nginx默認不支持這種調(diào)度算法，要使用的話需要安裝Nginx的hash軟件包园担。

配置方式：upstream 配置上游服務器

upstream test{

ip_hash; --ip_hash

或者 --url_hash

hash $request_url;

hash_method crc32

或者 --默認weight輪詢

默認

server localhost:8080;

server localhost:8081;

}

三.Nginx(Openresty)安裝配置及使用配置

1.下載nginx-upsync到openresty-1.13.6.2 的bundle目錄（bundle存放第三方模塊）

git clone https://github.com/weibocom/nginx-upsync-module.git # 建議使用git clone代碼編譯届谈，剛開始我使用release的tar.gz 編譯nginx失敗了

2.cd openresty-1.13.6.2

./configure --prefix=/home/zhangshilei/openresty_sync

--with-luajit

--with-http_iconv_module

--add-module=./bundle/nginx-upsync-module/

-j2

3.make &&make install

四：目錄結(jié)構(gòu)及常用Nginx指令

nginx.conf文件中的相對目錄是prefix或者-p指定的目錄

Nginx worker進程數(shù)一般設置與CPU核心數(shù)一致

在執(zhí)行configure命令是已經(jīng)將很多模塊編譯進nginx,但是是否啟用這些模塊，取決于配置文件nginx.conf中對應的配置項

常用指令：

1.另行指定配置文件的啟動方式

./nginx -c tempnginx.conf

2. 另行指定安裝目錄的啟動方式

./nginx -p xxx/xx/

3.另行指定全局配置項

./nginx -g "pid xx/xx/test.pid;" eg ./nginx -g "pid xx/xx/test.pid;" -s stop

4.測試配置文件是否有誤

./nginx -t -c tempnginx.conf

5.顯示Nginx版本信息

./nginx -v

6.顯示編譯階段的參數(shù)

./nginx -V

7.向master進程發(fā)信號

./nginx -s stop ./nginx -s quit ./nginx -s reload ./nginx -s reopen

8.ps命令來查看nginx master的進程ID：

ps -ef| grep nginx

netstat -ntlp sudo netstat -anp | grep nginx 查看虛擬主機端口號

9.根據(jù)master進程進程號關閉nginx

kill -s SIGTERM pid

五：nginx.conf配置

虛擬主機：

常用配置分類：

虛擬主機和請求的分發(fā)弯汰、文件路徑的定義艰山、內(nèi)存及磁盤資源的分配、網(wǎng)絡連接的設置咏闪、MIME類型的設置曙搬、對客戶端請求的限制、文件操作的優(yōu)化、對客戶端請求的特殊處理等

nginx.conf:

定義Nginx運行的用戶和用戶組

user www www;

啟動進程,通常設置成和cpu的數(shù)量相等

worker_processes 8;

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

為每個進程分配cpu纵装，上例中將8個進程分配到8個cpu征讲，當然可以寫多個，或者將一個進程分配到多個cpu橡娄。

指定Nginx worker進程可以打開的最大句柄描述符個數(shù)

worker_rlimit_nofile 102400;

全局錯誤日志及PID文件

error_log /usr/local/nginx/logs/error.log;

錯誤日志定義等級诗箍，[ debug | info | notice | warn | error | crit ]

pid /usr/local/nginx/nginx.pid;

工作模式及連接數(shù)上限

events {

use epoll; #epoll是多路復用IO(I/O Multiplexing)中的一種方式,但是僅用于linux2.6以上內(nèi)核,可以大大提高nginx的性能

worker_connections 102400;

單個后臺worker process進程的最大并發(fā)鏈接數(shù) （最大連接數(shù)=連接數(shù)*進程數(shù)）

multi_accept on;

盡可能多的接受請求

}

設定http服務器，利用它的反向代理功能提供負載均衡支持

http {

設定mime類型,類型由mime.type文件定義

include mime.types; #相對nginx.conf的相對路徑下

default_type application/octet-stream;

設定日志格式

access_log /usr/local/nginx/log/nginx/access.log;

sendfile on;

sendfile 指令指定 nginx 是否調(diào)用 sendfile 函數(shù)（zero copy 方式）來輸出文件挽唉，對于普通應用必須設為 on

如果用來進行下載等應用磁盤IO重負載應用滤祖，可設置為 off，以平衡磁盤與網(wǎng)絡I/O處理速度瓶籽，降低系統(tǒng)的 uptime.

autoindex on; #開啟目錄列表訪問匠童，合適下載服務器，默認關閉棘劣。

tcp_nopush on; #防止網(wǎng)絡阻塞

keepalive_timeout 60; #keepalive超時時間俏让，客戶端到服務器端的連接持續(xù)有效時間,當出現(xiàn)對服務器的后,繼請求時,keepalive-timeout功能可避免建立或重新建立連接。

tcp_nodelay on; #提高數(shù)據(jù)的實時響應性

開啟gzip壓縮

gzip on;

gzip_min_length 1k;

gzip_buffers 4 16k;

gzip_http_version 1.1;

gzip_comp_level 2;

壓縮級別大小茬暇，最大為9首昔，值越小，壓縮后比例越小糙俗，CPU處理更快勒奇。

值越大，消耗CPU比較高巧骚。

gzip_types text/plain application/x-javascript text/css application/xml;

gzip_vary on;

client_max_body_size 10m; #允許客戶端請求的最大單文件字節(jié)數(shù)

client_body_buffer_size 128k; #緩沖區(qū)代理緩沖用戶端請求的最大字節(jié)數(shù)

proxy_connect_timeout 90; #nginx跟后端服務器連接超時時間(代理連接超時)

proxy_send_timeout 90; #后端服務器數(shù)據(jù)回傳時間(代理發(fā)送超時)

proxy_read_timeout 90; #連接成功后赊颠，后端服務器響應時間(代理接收超時)

proxy_buffer_size 4k; #設置代理服務器（nginx）保存用戶頭信息的緩沖區(qū)大小

proxy_buffers 4 32k; #proxy_buffers緩沖區(qū)，網(wǎng)頁平均在32k以下的話劈彪，這樣設置

proxy_busy_buffers_size 64k; #高負荷下緩沖大锌⒈摹（proxy_buffers*2）

設定請求緩沖

large_client_header_buffers 4 4k;

client_header_buffer_size 4k;

客戶端請求頭部的緩沖區(qū)大小，這個可以根據(jù)你的系統(tǒng)分頁大小來設置沧奴，一般一個請求的頭部大小不會超過1k #不過由于一般系統(tǒng)分頁都要大于1k痘括，所以這里設置為分頁大小。分頁大小可以用命令getconf PAGESIZE取得滔吠。

open_file_cache max=102400 inactive=20s;

這個將為打開文件指定緩存纲菌，默認是沒有啟用的，max指定緩存數(shù)量疮绷，建議和打開文件數(shù)一致翰舌，inactive是指經(jīng)過多長時間文件沒被請求后刪除緩存。

open_file_cache_valid 30s; #這個是指多長時間檢查一次緩存的有效信息冬骚。

open_file_cache_min_uses 1; #open_file_cache指令中的inactive參數(shù)時間內(nèi)文件的最少使用次數(shù)椅贱，如果超過這個數(shù)字懂算，文件描述符一直是在緩存中打開的，如上例庇麦，如果有一個文件在inactive

包含其它配置文件犯犁，如自定義的虛擬主機

include vhosts.conf;

這里為后端服務器wugk應用集群配置，根據(jù)后端實際情況修改即可女器，tdt_wugk為負載均衡名稱，可以任意指定 #但必須跟vhosts.conf虛擬主機的pass段一致住诸，否則不能轉(zhuǎn)發(fā)后端的請求驾胆。weight配置權(quán)重，在fail_timeout 內(nèi)檢查max_fails次數(shù)贱呐，失敗則剔除均衡丧诺。

upstream tdt_wugk {

server 127.0.0.1:8080 weight=1 max_fails=2 fail_timeout=30s;

server 127.0.0.1:8081 weight=1 max_fails=2 fail_timeout=30s;

}

虛擬主機配置

server {

偵聽80端口

listen 80;

定義使用www.wuguangke.cn訪問

server_name www.wuguangke.cn;

設定本虛擬主機的訪問日志

access_log logs/access.log main;

root /data/webapps/wugk; #定義服務器的默認網(wǎng)站根目錄位置

index index.php index.html index.htm; #定義首頁索引文件的名稱 #默認請求

location ~ /{

root /data/www/wugk;

定義服務器的默認網(wǎng)站根目錄位置

index index.php index.html index.htm;

定義首頁索引文件的名稱 #以下是一些反向代理的配置.

proxy_next_upstream http_502 http_504 error timeout invalid_header;

如果后端的服務器返回502、504奄薇、執(zhí)行超時等錯誤驳阎，自動將請求轉(zhuǎn)發(fā)到upstream負載均衡池中的另一臺服務器，實現(xiàn)故障轉(zhuǎn)移馁蒂。

proxy_redirect off; #后端的Web服務器可以通過X-Forwarded-For獲取用戶真實IP proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_pass http://tdt_wugk; #請求轉(zhuǎn)向后端定義的均衡模塊

}

定義錯誤提示頁面

error_page 500 502 503 504 /50x.html;

location = /50x.html {

root html;

}

配置Nginx動靜分離呵晚，定義的靜態(tài)頁面直接從Nginx發(fā)布目錄讀取。

location ~ .*.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)$ {

root /data/www/wugk;

expires定義用戶瀏覽器緩存的時間為3天沫屡，如果靜態(tài)頁面不常更新饵隙，可以設置更長，這樣可以節(jié)省帶寬和緩解服務器的壓力沮脖。

expires 3d;

}

PHP腳本請求全部轉(zhuǎn)發(fā)到 FastCGI處理. 使用FastCGI默認配置.

location ~ .php$ {

root /root;

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

fastcgi_param SCRIPT_FILENAME /data/www/wugk$fastcgi_script_name;

include fastcgi_params;

}

設定查看Nginx狀態(tài)的地址

location /NginxStatus {

stub_status on;

}

}

}

一些模塊處理請求時可以產(chǎn)生豐富的變量金矛，當然，這些變量還可以用于其他Http模塊

Nginx會拿到完整的用戶請求存到nginx服務器硬盤或內(nèi)存后勺届，再向上游服務器發(fā)起連接驶俊，把緩存的客戶端其你去轉(zhuǎn)發(fā)到上游服務器

缺點:延長一個請求的處理時間，增大磁盤和內(nèi)存壓力

優(yōu)點：降低上游服務器負載免姿，把壓力放在nginx服務器上

Nginx不會將請求和響應的頭部發(fā)給對方饼酿，可配置加入

自定義模塊

一個模塊是一個或多個.c文件，將這些文件放到一個文件夾养泡，并在該文件夾下建一個conf文件

在該conf文件中加入下面變量

ngx_addon_name=ngx_http_mytest_module ##指定模塊名

HTTP_MODULES="$HTTP_MODULES ngx_http_mytest_module" ##在http模塊中加入本模塊(也可以是其他模塊)

NGX_ADDON_SRCS="ngx_addon_dir/ngx_http_mytest_module.c" ##加入本模塊源碼

$ngx_addon_dir等價于—add-module=path中的path

編寫.c文件

內(nèi)涵：

ngx_command_t/ngx_http_module_t/ngx_module_t/nginx_http_Xxx_handler/ngx_http_xxx(注冊handler)

Server匹配規(guī)則： 請求找到對應server處理（找到處理請求的組件）

1.Nginx取出請求頭中的Host嗜湃，與server_name進行匹配

規(guī)則:完全匹配>匹配通配符在前>匹配通配符在后>正則表達式

另外 server_name 默認為”” 表示匹配沒有host的請求

host形式： 域名； 域名：port; ip:port

2.如果上一步?jīng)]有匹配到則進行端口匹配

規(guī)則：端口中配置default|default_server>匹配listen端口的第一個server

端口：listen 8000;表示監(jiān)聽*:80000

listen 127.0.0.1 表示監(jiān)聽 127.0.0.1:80

listen 127.0.0.1:8000 表示監(jiān)聽 127.0.0.1:8000
先server_name匹配澜掩，匹配不到看listen有沒有配置默認server,最后進行端口匹配**

我的理解：請求首先根據(jù)請求端口進入端口购披，服務器中端口上保存對應的server信息，開始匹配server_name肩榕，當host與其中的server_name匹配刚陡，對應server處理惩妇，如果不匹配找尋該port下是否存在listen配置了default|default_server ,若有則由該server處理，沒有則匹配該port下的找到的第一個server處理

Location匹配規(guī)則：請求URI匹配location（找到組件中具體處理方法）

location [=|_|*|^~|@] /uri/ { … }

[] 內(nèi)為可選項

location匹配分兩種：普通匹配筐乳、正則匹配

一般以[=,^~歌殃。@]或者不加任何前綴表示普通匹配，普通匹配沒有書寫順序蝙云，匹配規(guī)則是”最大前綴“氓皱，

以[_,*]開頭表示正則匹配，正則匹配有書寫順序勃刨，一旦匹配就進入到該location塊執(zhí)行

_{:區(qū)分大小寫的正則匹配波材；}*：不區(qū)分大小寫的正則匹配

前綴含義：不加任何前綴：表示普通匹配，后續(xù)仍會進行正則匹配身隐，可以被正則匹配覆蓋

= 表示嚴格精準匹配 ^~表示部分匹配最大長度匹配后不需要再進行正則匹配

（如果不加前綴達到完全匹配廷区，則也是不需要正則匹配的）

正則location 匹配讓步普通 location 的精確匹配結(jié)果；但覆蓋普通 location的最大前綴匹配結(jié)果

究極總結(jié)：location = >location完全匹配>location ^~ >location _| >location部分匹配

https://www.cnblogs.com/lidabo/p/4169396.html

請求轉(zhuǎn)發(fā)與重定向

在****nginx****的****rewrite****階段

包含

匹配進入對應location的處理

1.root 和alias規(guī)則

2.proxy_pass規(guī)則

六：goaccess使用

服務器訪問監(jiān)控的UI:goaccess

安裝：

wget https://tar.goaccess.io/goaccess-1.3.tar.gz

tar -xzvf goaccess-1.3.tar.gz

cd goaccess-1.3/

./configure --enable-utf8 --enable-geoip=legacy

make

make install

使用：

1.配置

goaccess-1.3目錄下運行：實時的將nginx的access.log 轉(zhuǎn)存為report.html

[root@localhost goaccess-1.3]#./goaccess /home/zhangshilei/openresty_lua/logs/access.log -o /home/zhangshilei/openresty_lua/html/report.html --real-time-html --time-format='%H:%M:%S' --date-format='%d/%b/%Y' --log-format=COMBINED

＜致痢Ｏ肚帷！垢揩！需要執(zhí)行上述命令玖绿，才能實時監(jiān)控

2.修改nginx.conf

location report.html{

alias html/report.html;

}

3.訪問

10.10.38.195:8002/report.html 該頁面監(jiān)控對服務器的的訪問

七：ngx_lua API （Lua<-->C相互調(diào)用API）

（https://github.com/openresty/lua-nginx-module#ngxshareddictcapacity）

nginx lua 的8個階段

init_by_lua

set_by_lua

rewrite_by_lua

access_by_lua

content_by_lua

header_filter_by_lua

body_filter_by_lua

log_by_lua

上述網(wǎng)址中有相關的nginx_lua的指令和api 在nginx中使用lua 在lua代碼中使用nginx的參數(shù)

項目結(jié)構(gòu)：

將lua代碼寫到一個文件中。在nginx.conf 的http模塊中加入lua_package_path 指定?.lua的搜索路徑叁巨，并寫一個lua.conf 在nginx.conf中 include lua.conf;在lua.conf中引用對應的lua文件镰矿。在lua代碼中使用 require("a.b.c")的方式引入對應的lua代碼（c為文件名，a/b為包名）

八：nginx 高可用（keepAlive使用）

#九：Lua腳本學習

Nginx 變量的創(chuàng)建和賦值操作發(fā)生在全然不同的時間階段俘种。Nginx 變量的創(chuàng)建只能發(fā)生在 Nginx 配置加載的時候秤标，或者說 Nginx 啟動的時候（rewrite階段）；而賦值操作則只會發(fā)生在請求實際處理的時候（content階段）宙刘。這意味著不創(chuàng)建而直接使用變量會導致啟動失敗苍姜，同時也意味著我們無法在請求處理時動態(tài)地創(chuàng)建新的 Nginx 變量。(變量在一個請求處理過程被賦值悬包，不同請求有不同的值衙猪，所以變量作用域是一個請求處理過程)

Nginx 變量一旦創(chuàng)建，其變量名的可見范圍就是整個 Nginx 配置布近，甚至可以跨越不同虛擬主機的server配置塊

Nginx 內(nèi)建變量最常見的用途就是獲取關于請求或響應的各種信息

在Nginx 配置中垫释，變量只能存放一種類型的值，因為也只存在一種類型的值撑瞧，那就是字符串 ,在Nginx中棵譬，除非特殊說明，大部分地方字符串的不需要引號括住预伺，字符串和變量的拼接也不需要引號

一個請求處理過程中維護一個變量副本订咸，不同的請求變量副本不同

“主請求”以及各個“子請求”都擁有不同的變量$var的值容器副本

并非所有的內(nèi)建變量都作用于當前請求曼尊。少數(shù)內(nèi)建變量只作用于“主請求”

ngx_lua API： 從nginx中獲取到請求通過lua處理后返回給nginx，最終返回給客戶的整個過程

ngx.arg是一個表脏嚷，可以把nginx的變量放到這個表中骆撇，供給Lua使用

context:set_by_lua, body_filter_by_lua

set_by_lua a $b;

ngx.var.VARNAME： 相當于直接操作nginx變量

context:set_by_lua, rewrite_by_lua, access_by_lua, content_by_lua, header_filter_by_lua, body_filter_by_lua, log_by_lua

ngx.var :table保存了Nginx中的變量ngx.var[1] ngx.var.varname

Nginx中已經(jīng)定義的變量可以被直接使用；

在lua中將變量設置為nil父叙，則Nginx中該變量也會消失. 注意：最好在lua中定義一個變量接收該變量神郊，避免修改導致無法使用
ngx.ctx是一個當前請求對應的lua上下文表（一個請求對應的存儲域）

context:init_worker_by_lua, set_by_lua, rewrite_by_lua, access_by_lua, content_by_lua, header_filter_by_lua, body_filter_by_lua, log_by_lua, ngx.timer., balancer_by_lua

ngx.shared.DICT共享內(nèi)存多worker共用

在http模塊中定義如下

lua_shared_dict dog 10m;

在其他地方通過ngx.shared.dog：XX()方法使用該內(nèi)存* ngx_shared_DICT API

print(...)等價于 ngx.log(ngx.NOTICE, …) 向日志文件中寫入內(nèi)容

ngx.log(log_level, ...)

ok, err = ngx.print(...)：向客戶端發(fā)送內(nèi)容雷滚，需要先發(fā)送響應頭

ngx.say():跟ngx.print()一樣衫嵌，只是尾隨一個換行符

secs = ngx.req.start_time()請求發(fā)起時間

num = ngx.req.http_version()num值：.0, 1.0, 1.1, 0.9禾锤，nil表示為識別

ngx.status 讀寫請求的響應狀態(tài)（發(fā)出響應header之前使用得封，否則也沒大影響只會在error.log中記錄error message）

ok, err = ngx.send_headers()發(fā)出響應頭

value = ngx.headers_sent檢測是否發(fā)出了響應頭

ok, err = ngx.flush(wait?)Flushes response output to the client ：發(fā)出響應

ngx.exit(status)結(jié)束執(zhí)行并向nginx返回狀態(tài)嗎

ok, err = ngx.eof()顯式指定響應輸出流的結(jié)尾

時間相關

ngx.sleep(seconds)

str = ngx.today()

secs = ngx.time()

secs = ngx.now()

ngx.update_time()

str = ngx.localtime()當前位置時間 time stamp format yyyy-mm-dd hh:mm:ss

str = ngx.utctime()* UTC time time stamp format yyyy-mm-dd hh:mm:ss

正則支持

captures, err =ngx.re.match(subject, regex, options?, ctx?, res_table?)正則 subject是否匹配正則表達式regex

from, to, err = ngx.re.find(subject, regex, options?, ctx?, nth?)返回正則匹配的位置

iterator, err = ngx.re.gmatch(subject, regex, options?)正則匹配后返回一個迭代器

newstr, n, err = ngx.re.sub(subject, regex, replace, options?)正則匹配后返回第一個匹配的字符串

Nginx提供獲取請求的uri的變量 所以ngx_lua沒有提供對應的方法

ngx.var.request_uri

$uri指的是請求的文件和路徑，不包括“?”或者“#”之后的東西溺健，

$request_uri則是請求的整個字符串，包含了后面的query_string的

請求轉(zhuǎn)發(fā)與重定向

rewrite regrex replacement option;

請求uri匹配regex表達式后，使用replacement改寫uri,

option:

last： 發(fā)起一次重新匹配location server塊中使用last

break：不發(fā)起重新匹配location location塊中常用break

redirect:客戶端重發(fā)請求

（請求包含）ngx.location.capture:發(fā)送子請求的方式實現(xiàn)location的重新定位（一般在location中的content_by_lua 重新匹配location 且指定了請求參數(shù)）

res = ngx.location.capture(uri, options?)一般在location中發(fā)送子請求得到響應res res.status/ res.body/ res.header/ res.truncated 參數(shù)是請求uri和請求參數(shù) 請求參數(shù)類似一個table带欢，內(nèi)部可配置多參數(shù)method body args ctx

inherit all the request headers of the current request by default ：子請求繼承本請求的headers

When the body option is not specified and the always_forward_body option is false (the default value), the POST and PUT subrequests will inherit the request bodies of the parent request

ngx.location.capture.mutil發(fā)送多個子請求

res1, res2, ... = ngx.location.capture_multi({ {uri, options?}, {uri, options?}, ... })

value = ngx.is_subrequest是否是子請求

（請求轉(zhuǎn)發(fā)）

ngx.exec(uri, args?)：內(nèi)部轉(zhuǎn)發(fā)請求到uri 和args（lua string 或亂table）

等價于rewrite regrex replacement last;

請求URI處理

ngx.req.set_uri(uri, jump?)：改寫請求uri，并根據(jù)jump的boolean值決定是否跳轉(zhuǎn)

jump為true烤惊，等價于rewrite...last 改寫uri乔煞，并重新匹配location

jump為false，等價于rewrite...break

三者的區(qū)別：

is_internal =ngx.req.is_internal()判斷當前請求是否是內(nèi)部請求 返回boolean

內(nèi)部請求定義： 從當前nginx服務器內(nèi)部發(fā)出而不是從客戶端啟動的請求柒室。（子請求都是內(nèi)部請求）//并非是請求當前服務器內(nèi)部

（請求重定向）重定向到uri

ngx.redirect(uri, status?)：客戶端以修改的uri重發(fā)一起請求

轉(zhuǎn)發(fā)與重定向的區(qū)別

轉(zhuǎn)發(fā)：瀏覽器URL的地址欄不變渡贾。重定向：瀏覽器URL的地址欄改變

轉(zhuǎn)發(fā)是服務器行為，重定向是客戶端行為

轉(zhuǎn)發(fā)是瀏覽器只做了一次訪問請求雄右。重定向是瀏覽器做了至少兩次的訪問請求空骚；

轉(zhuǎn)發(fā)2次跳轉(zhuǎn)之間傳輸?shù)男畔⒉粫G失，重定向2次跳轉(zhuǎn)之間傳輸?shù)男畔G失

請求和響應頭處理

ngx.header.HEADER = VALUE設置響應頭的參數(shù)

value = ngx.header.HEADER獲得請求頭的參數(shù)

headers, err =ngx.resp.get_headers(max_headers?, raw?)

返回當前請求的響應頭 lua table

headers, err =ngx.req.get_headers(max_headers?, raw?)*

返回當前請求頭 lua table

ngx.req.set_header(header_name, header_value)：設置當前請求的請求頭

ngx.req.clear_header(header_name)：清理header_name的請求頭內(nèi)容（刪除該請求頭的信息）

str = ngx.req.raw_header(no_request_line?)string形式服務器接收到的原始請求頭 （默認包含請求行）

請求方法處理

method_name = ngx.req.get_method()： 返回請求方法 （請求方法常量）

ngx.req.set_method(method_id)：改寫當前請求的請求方法

請求參數(shù)處理（或請求體）：有些格式不對擂仍，需要讀取請求體

ngx.req.set_uri_args(args) :改寫請求參數(shù) 參數(shù)可以使lua string 或者lua table

args, err = ngx.req.get_uri_args(max_args?) :獲取請求參數(shù) lua table存

請求體：某種格式的請求數(shù)據(jù)

nginx核心本身不會主動讀取請求體

請求體的讀取一般發(fā)生在nginx的content handler中

讀取body到內(nèi)存是第一步(對于lua來說兩種方式)

1.ngx.req.read_body()：沒有返回 只是讀取body到內(nèi)存

2.lua_need_request_body：是一個指令 將請求的body讀入$request_body變量中

從Nginx中讀到Lua是第二部

需要配合ngx.req.get_post_args使用

data = ngx.req.get_body_data()返回lua string形式的請求體 vs ngx.req.get_post_args（從內(nèi)存中將body讀取到lua中使用時第二步）

args, err = ngx.req.get_post_args(max_args?)***獲取post請求的參數(shù)table形式存

ngx.req.set_body_data(data) 修改請求體內(nèi)容

file_name = ngx.req.get_body_file() 讀到文件中 利用lua io

ngx.req.set_body_file(file_name, auto_clean?)通過文件形式寫入body*

銷毀body

ngx.req.discard_body()讀取并丟棄請求體 如果請求體已經(jīng)被讀取囤屹，則立即返回不做任何處理

新建body(下述3個共同使用)

ngx.req.init_body(buffer_size?)為當前請求新建一個空的body并初始化大小

寫入：body

ngx.req.append_body(data_chunk)：Append new data chunk specified by the data_chunk *argument onto the existing request body created by thengx.req.init_bodycall.

完成寫入

ngx.req.finish_body()