（66）Nginx+lua+Redis開發

時間  2019-11-20
標籤 nginx+lua+redis nginx lua redis 開發 欄目 Nginx 简体版
原文   原文鏈接

一. 概述php

Nginx是一個高性能，支持高併發的，輕量級的web服務器。目前，Apache依然web服務器中的老大，可是在全球前1000大的web服務器中，Nginx的份額爲22.4%。Nginx採用模塊化的架構，官方版本的Nginx中大部分功能都是經過模塊方式提供的，好比Http模塊、Mail模塊等。經過開發模塊擴展Nginx，能夠將Nginx打形成一個全能的應用服務器，這樣能夠將一些功能在前端Nginx反向代理層解決，好比登陸校驗、js合併、甚至數據庫訪問等等。     可是，Nginx模塊須要用C開發，並且必須符合一系列複雜的規則，最重要的用C開發模塊必需要熟悉Nginx的源代碼，使得開發者對其望而生畏。淘寶的agentzh和chaoslawful開發的ngx_lua模塊經過將lua解釋器集成進Nginx，能夠採用lua腳本實現業務邏輯，因爲lua的緊湊、快速以及內建協程，因此在保證高併發服務能力的同時極大地下降了業務邏輯實現成本。     本文向你們介紹ngx_lua，以及我在使用它開發項目的過程當中遇到的一些問題。

html

二. 準備前端

首先，介紹一下Nginx的一些特性，便於後文介紹ngx_lua的相關特性。node

 

Nginx進程模型mysql

Nginx採用多進程模型，單Master—多Worker，由Master處理外部信號、配置文件的讀取及Worker的初始化，Worker進程採用單線程、非阻塞的事件模型（Event Loop，事件循環）來實現端口的監聽及客戶端請求的處理和響應，同時Worker還要處理來自Master的信號。因爲Worker使用單線程處理各類事件，因此必定要保證主循環是非阻塞的，不然會大大下降Worker的響應能力。nginx

Nginx處理Http請求的過程web

表面上看，當Nginx處理一個來自客戶端的請求時，先根據請求頭的host、ip和port來肯定由哪一個server處理，肯定了server以後，再根據請求的uri找到對應的location，這個請求就由這個location處理。實際Nginx將一個請求的處理劃分爲若干個不一樣階段（phase），這些階段按照先後順序依次執行，也就是說NGX_HTTP_POST_READ_PHASE在第一個，NGX_HTTP_LOG_PHASE在最後一個。redis

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. <span style="font-size:10px;">NGX_HTTP_POST_READ_PHASE,     //0讀取請求phase  
  2. NGX_HTTP_SERVER_REWRITE_PHASE,//1這個階段主要是處理全局的(server block)的rewrite  
  3. NGX_HTTP_FIND_CONFIG_PHASE,   //2這個階段主要是經過uri來查找對應的location，而後根據loc_conf設置r的相應變量  
  4. NGX_HTTP_REWRITE_PHASE,       //3這個主要處理location的rewrite  
  5. NGX_HTTP_POST_REWRITE_PHASE,  //4postrewrite，這個主要是進行一些校驗以及收尾工做，以便於交給後面的模塊。  
  6. NGX_HTTP_PREACCESS_PHASE,     //5好比流控這種類型的access就放在這個phase，也就是說它主要是進行一些比較粗粒度的access。  
  7. NGX_HTTP_ACCESS_PHASE,        //6這個好比存取控制，權限驗證就放在這個phase，通常來講處理動做是交給下面的模塊作的.這個主要是作一些細粒度的access  
  8. NGX_HTTP_POST_ACCESS_PHASE,   //7通常來講當上面的access模塊獲得access_code以後就會由這個模塊根據access_code來進行操做  
  9. NGX_HTTP_TRY_FILES_PHASE,     //8try_file模塊，就是對應配置文件中的try_files指令，可接收多個路徑做爲參數，當前一個路徑的資源沒法找到，則自動查找下一個路徑     
  10. NGX_HTTP_CONTENT_PHASE,       //9內容處理模塊     
  11. NGX_HTTP_LOG_PHASE            //10log模塊  

每一個階段上能夠註冊handler，處理請求就是運行每一個階段上註冊的handler。Nginx模塊提供的配置指令只會通常只會註冊並運行在其中的某一個處理階段。sql

好比，set指令屬於rewrite模塊的，運行在rewrite階段，deny和allow運行在access階段。數據庫


子請求（subrequest）

其實在Nginx 世界裏有兩種類型的「請求」，一種叫作「主請求」（main request），而另外一種則叫作「子請求」（subrequest）。 所謂「主請求」，就是由 HTTP 客戶端從 Nginx 外部發起的請求。好比，從瀏覽器訪問Nginx就是一個「主請求」。 而「子請求」則是由 Nginx 正在處理的請求在 Nginx 內部發起的一種級聯請求。「子請求」在外觀上很像 HTTP 請求，但實現上卻和 HTTP 協議乃至網絡通訊一點兒關係都沒有。它是 Nginx 內部的一種抽象調用，目的是爲了方便用戶把「主請求」的任務分解爲多個較小粒度的「內部請求」，併發或串行地訪問多個 location 接口，而後由這些 location 接口通力協做，共同完成整個「主請求」。固然，「子請求」的概念是相對的，任何一個「子請求」也能夠再發起更多的「子子請求」，甚至能夠玩遞歸調用（即本身調用本身）。

當一個請求發起一個「子請求」的時候，按照 Nginx 的術語，習慣把前者稱爲後者的「父請求」（parent request）。

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. location /main {  
  2.     echo_location /foo;     # echo_location發送子請求到指定的location  
  3.     echo_location /bar;  
  4. }  
  5. location /foo {  
  6.     echo foo;  
  7. }  
  8. location /bar {  
  9.     echo bar;  
  10. }  

輸出：

$ 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！

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. # nginx.conf  
  2. worker_processes 4;  
  3.   
  4. events {  
  5.      worker_connections 1024;  
  6. }  
  7. http {  
  8.   
  9.     server {  
  10.         listen 80;  
  11.         server_name localhost;  
  12.   
  13.         location=/lua {  
  14.             content_by_lua ‘  
  15.                 ngx.say("Hello, Lua!")  
  16.             ';  
  17.         }  
  18.     }  
  19. }  

輸出：
$ curl 'localhost/lua'
Hello，Lua！

這樣就實現了一個很簡單的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 ...]

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. location =/adder {  
  2.     set_by_lua $res"  
  3.             local a = tonumber(ngx.arg[1])  
  4.                 local b = tonumber(ngx.arg[2])  
  5.                 return a + b"$arg_a$arg_b;  
  6.   
  7.         echo$res;  
  8. }  

輸出：
$ curl 'localhost/adder?a=25&b=75'
$ 100

set_by_lua_file執行Nginx外部的lua腳本，能夠避免在配置文件中使用大量的轉義。

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. location =/fib {  
  2.         set_by_lua_file $res "conf/adder.lua" $arg_n;  
  3.   
  4.         echo $res;  
  5. }</span>  

 

adder.lua:

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. local a=tonumber(ngx.arg[1])  
  2. local b=tonumber(ngx.arg[2])  
  3. 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能完成複雜的訪問控制，好比，訪問數據庫進行用戶名、密碼驗證等。

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. location /auth {  
  2.     access_by_lua '  
  3.         if ngx.var.arg_user == "ntes" then  
  4.             return  
  5.         else  
  6.             Ngx.exit(ngx.HTTP_FORBIDDEN)  
  7.         end  
  8.     ';  
  9.     echo'welcome ntes';  
  10. }  

輸出：
$ 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階段執行。

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. location =/foo {  
  2.         rewrite_by_lua 'ngx.exec("/bar")';  
  3.     echo'in foo';  
  4. }  
  5.   
  6. location =/bar {  
  7.         echo'in bar';  
  8. }  

輸出：
$ curl 'localhost/lua'
$ Hello, Lua!

content_by_lua和content_by_lua_file

Contenthandler在content階段執行，生成http響應。因爲content階段只能有一個handler，因此在與echo模塊使用時，不能同時生效，我測試的結果是content_by_lua會覆蓋echo。這和以前的hello world的例子是相似的。

 

配置（直接響應）：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. location =/lua {  
  2.         content_by_lua 'ngx.say("Hello, Lua!")';  
  3. }  


輸出：
$ curl 'localhost/lua'
$ Hello, Lua!

配置（在Lua中訪問Nginx變量）：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. location =/hello {  
  2.         content_by_lua '  
  3.             local who = ngx.var.arg_who  
  4.             ngx.say("Hello, ", who, "!")  
  5.         ';  
  6. }  


輸出：
$ 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）。

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. location =/other {  
  2.     ehco 'Hello, world!';  
  3. }  
  4.   
  5. # Lua非阻塞IO  
  6. location =/lua {  
  7.     content_by_lua '  
  8.         local res = ngx.location.capture("/other")  
  9.         if res.status == 200 then  
  10.             ngx.print(res.body)  
  11.         end  
  12.     ';  
  13. }  


輸出：
$ 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功能同樣，能夠並行的、非阻塞的發出多個子請求。這個方法在全部子請求處理完成後返回，而且整個方法的運行時間取決於運行時間最長的子請求，並非全部子請求的運行時間之和。

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. # 同時發送多個子請求（subrequest）  
  2. location =/moon {  
  3.     ehco 'moon';  
  4. }  
  5. location =/earth {  
  6.     ehco 'earth';  
  7. }  
  8.   
  9. location =/lua {  
  10.     content_by_lua '  
  11.         local res1,res2 = ngx.location.capture_multi({ {"/moon"}, {"earth"} })  
  12.         if res1.status == 200 then  
  13.             ngx.print(res1.body)  
  14.         end  
  15.         ngx.print(",")  
  16.         if res2.status == 200 then  
  17.             ngx.print(res2.body)  
  18.         end  
  19.     ';  
  20. }  



輸出：
$ 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：

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. location / {  
  2.     internal;  
  3.     root html;  
  4. }  
  5.   
  6. location /capture {  
  7.     content_by_lua '  
  8.         res = ngx.location.capture("/")  
  9.         echo res.body  
  10.     ';  
  11. }  

 

經過標準lua io訪問磁盤文件：

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. location /luaio{  
  2.     content_by_lua '  
  3.         local io = require("io")  
  4.         local chunk_SIZE = 4096  
  5.         local f = assert(io.open("html/index.html","r"))  
  6.         while true do  
  7.             local chunk = f:read(chunk)  
  8.             if not chunk then  
  9.                 break  
  10.             end  
  11.             ngx.print(chunk)  
  12.             ngx.flush(true)  
  13.         end  
  14.         f:close()  
  15.     ';  
  16. }  


這裏經過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。

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. #使用HttpMemcModule  
  2. location =/memc {  
  3.     set $memc_cmd $arg_cmd;  
  4.     set $memc_key $arg_key;  
  5.     set $memc_value $arg_val;  
  6.     set $memc_exptime $arg_exptime;  
  7.   
  8.     memc_pass '127.0.0.1:11211';  
  9. }  

輸出：
$ curl  'http://localhost/memc?cmd=set&key=foo&val=Hello'
$ STORED
$ curl  'http://localhost/memc?cmd=get&key=foo'
$ Hello

這就實現了memcached的訪問，下面看一下如何在lua中訪問memcached。

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. #在Lua中訪問Memcached  
  2. location =/memc {  
  3.     internal;   #只能內部訪問  
  4.     set $memc_cmd get;  
  5.     set $memc_key $arg_key;  
  6.     memc_pass '127.0.0.1:11211';  
  7. }  
  8. location =/lua_memc {  
  9.     content_by_lua '  
  10.         local res = ngx.location.capture("/memc", {  
  11.             args = { key = ngx.var.arg_key }  
  12.         })  
  13.         if res.status == 200 then  
  14.             ngx.say(res.body)  
  15.         end  
  16.     ';  
  17. }  


輸出：
$ 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的原生響應。

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. #在Lua中訪問Redis  
  2. location =/redis {  
  3.     internal;   #只能內部訪問  
  4.     redis2_query get $arg_key;  
  5.     redis2_pass '127.0.0.1:6379';  
  6. }  
  7. location =/lua_redis {#須要LuaRedisParser  
  8.     content_by_lua '  
  9.         local parser = require("redis.parser")  
  10.         local res = ngx.location.capture("/redis", {  
  11.             args = { key = ngx.var.arg_key }  
  12.         })  
  13.         if res.status == 200 then  
  14.             reply = parser.parse_reply(res.body)  
  15.             ngx.say(reply)  
  16.         end  
  17.     ';  
  18. }  


輸出：
$ 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機制，能夠在一次鏈接中執行多個命令，這樣能夠減小屢次執行命令的往返時延。客戶端在經過pipeline發送多個命令後，redis順序接收這些命令並執行，而後按照順序把命令的結果輸出出去。在lua中使用pipeline須要用到redis2模塊的redis2_raw_queries進行redis的原生請求查詢。

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. #在Lua中訪問Redis  
  2. location =/redis {  
  3.     internal;   #只能內部訪問  
  4.     redis2_raw_queries $args$echo_request_body;  
  5.     redis2_pass '127.0.0.1:6379';  
  6. }  
  7.   
  8. location =/pipeline {  
  9.     content_by_lua 'conf/pipeline.lua';  
  10. }  

pipeline.lua

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. -- conf/pipeline.lua file  
  2. local parser=require(‘redis.parser’)  
  3. local reqs={  
  4.     {‘get’, ‘one’}, {‘get’, ‘two’}  
  5. }  
  6. -- 構造原生的redis查詢，get one\r\nget two\r\n  
  7. local raw_reqs={}  
  8. for i, req in ipairs(reqs)do  
  9.       table.insert(raw_reqs, parser.build_query(req))  
  10. end  
  11. local res=ngx.location.capture(‘/redis?’..#reqs, {body=table.concat(raw_reqs, ‘’)})  
  12.   
  13. if res.status and res.body then  
  14.        -- 解析redis的原生響應  
  15.        local replies=parser.parse_replies(res.body, #reqs)  
  16.        for i, reply in ipairs(replies)do  
  17.           ngx.say(reply[1])  
  18.        end  
  19. end  


輸出：
$ curl  'http://localhost/pipeline'
$ first
  second

Connection Pool

前面訪問redis和memcached的例子中，在每次處理一個請求時，都會和後端的server創建鏈接，而後在請求處理完以後這個鏈接就會被釋放。這個過程當中，會有3次握手、timewait等一些開銷，這對於高併發的應用是不可容忍的。這裏引入connection pool來消除這個開銷。 鏈接池須要HttpUpstreamKeepaliveModule模塊的支持。

配置：

[plain]  view plain  copy
 
 
 
  在CODE上查看代碼片派生到個人代碼片
  1. http {  
  2.     # 須要HttpUpstreamKeepaliveModule  
  3.     upstream redis_pool {  
  4.         server 127.0.0.1:6379;  
  5.         # 能夠容納1024個鏈接的鏈接池  
  6.         keepalive 1024 single;  
  7.     }  
  8.   
  9.     server {  
  10.         location=/redis {  
  11.             …  
  12.             redis2_pass redis_pool;  
  13.         }  
  14.     }  
  15. }  


這個模塊提供keepalive指令，它的context是upstream。咱們知道upstream在使用Nginx作反向代理時使用，實際upstream是指「上游」，這個「上游」能夠是redis、memcached或是mysql等一些server。upstream能夠定義一個虛擬server集羣，而且這些後端的server能夠享受負載均衡。keepalive 1024就是定義鏈接池的大小，當鏈接數超過這個大小後，後續的鏈接自動退化爲短鏈接。鏈接池的使用很簡單，直接替換掉原來的ip和端口號便可。      有人曾經測過，在沒有使用鏈接池的狀況下，訪問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

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程