Nginx學(xué)習(xí)：事件模塊Event

基礎(chǔ)的核心模塊中，事件模塊是非常重要的一個部分，但是，它的配置項其實并不多，常見的或者說需要我們?nèi)ヅ渲玫母?。不過本著基礎(chǔ)學(xué)習(xí)和了解的態(tài)度，咱們還是要一個個的學(xué)習(xí)一下。

首先來看一下什么是事件模塊。在 Nginx 中，模塊相關(guān)的配置都是在一對大花括號中的，比如 http{} 、server{} 這些，事件模塊也是類似的。

events {……………………}

事件模塊主要是提供配置文件上下文，指定一些影響連接處理的指令，它包含 Nginx 中所有處理連接的設(shè)置。為啥事件模塊處理的是連接？

其實，這牽涉到 Nginx 的內(nèi)核運行機制，一般情況下，我們現(xiàn)在使用的 Linux 都支持包括 select、epoll、kqueue 這一類的 IO 模型。而這些模型現(xiàn)在基本都可以看成是事件機制的處理形式，只是內(nèi)部略有不同。所以在命名上使用了 events ，但實際上管理的是 IO 連接。

具體的這些內(nèi)容，我也只是了解個大概，比如現(xiàn)在最主流的就是 epoll ，它是完全的事件機制，可以實現(xiàn)多路 IO 復(fù)用。當(dāng)一個 IO 阻塞后，讓其它的 IO 繼續(xù)處理，然后這個 IO 處理完成后觸發(fā)事件回調(diào)回來繼續(xù)處理。很像我們在日常開發(fā)中的回調(diào)函數(shù)之類的處理流程。Redis 現(xiàn)在主要也是依托于這種 IO 機制實現(xiàn)強大的處理性能。

更詳細的內(nèi)容大家可以再深入的查找相關(guān)的學(xué)習(xí)資料，將來如果咱們要深入學(xué)習(xí)操作系統(tǒng)時，也可能會接觸到，到時候再說吧，現(xiàn)在我的水平也只能解釋到這里了。

好了，接下來我們就看看在具體的 events 模塊中，我們可以進行哪些配置。

指定 IO 模塊

使用的是 use ，注意，和 user 只差一個 r 哦，而且它是寫在 events 的花括號里面的。

use method;

指定要使用的連接處理方法，可用指定為 select、poll、kqueue、epoll 等等，注意，不同的操作系統(tǒng)使用的也不一樣?，F(xiàn)在 Linux 下，基本都是 epoll ，F(xiàn)reeBSD 之類的會使用 kqueue ，其它的還有 eventport 等在一些我們不太常見的操作系統(tǒng)上可以配置。這個選項通常不需要顯式指定，因為 Nginx 會默認使用當(dāng)前系統(tǒng)中最有效的模式。

換句話說，如果像我一樣，對 IO 模型不太了解的，別設(shè)置這玩意了，讓他走默認的就好。

worker_aio_requests number;

這個命令是將 aio 與 epoll 連接處理方法一起使用時，設(shè)置單個工作進程未完成的異步 IO 操作的最大數(shù)量。這個配置指令出現(xiàn)在版本1.1.4和1.0.7中?，F(xiàn)在有沒有用我也不清楚，反正直接配置是不會報錯的。使用上也沒見到有什么異常。

連接數(shù)

上回我們講過一個 worker_rlimit_nofile ，它是 Nginx 整體的連接數(shù)，和系統(tǒng)的 ulimit 有點關(guān)系，或者說直接就是可以替換 ulimit 的功能，不過僅限于在 Nginx 環(huán)境中哈。今天再來學(xué)習(xí)的是事件模塊中設(shè)置工作進程可以打開的最大連接數(shù)。

worker_connections number;

它設(shè)置的是工作進程可以打開的最大同時連接數(shù)。這個數(shù)字包括所有連接（例如與代理服務(wù)器的連接等），而不僅僅是與客戶端的連接。另一個考慮因素是，同時連接的實際數(shù)量不能超過當(dāng)前打開文件的最大數(shù)量限制，也就是說，它不應(yīng)該超過 worker_rlimit_nofile 設(shè)置的數(shù)量。如果 Nginx 配置文件中沒有配置的話，要看下操作系統(tǒng)的 ulimit 大小。

另外，我們通過 worker_connections 和上篇文章中學(xué)習(xí)過的 worker_processes 可以計算出 maxclients （最大連接數(shù)）：

max_clients = worker_processes * worker_connections

如果作為反向代理，max_clients為（除4并不一定準(zhǔn)，是個經(jīng)驗值）：

max_clients = worker_processes * worker_connections/4

worker_processes 是工作進程數(shù)，worker_connections 是工作連接數(shù)。假如設(shè)置當(dāng)前 CPU 是 4 核，worker_processes 設(shè)置為 4 ；worker_connections 也設(shè)置到 10000，那么總體的最大連接數(shù)就是 4 * 10000= 40000 。

默認情況下，worker_connections 都是 512 或 1024 ，這個數(shù)字并不是說越多越好，而是要根據(jù)服務(wù)器的實際情況進行確定，一個是內(nèi)存，一個是 ulimit 數(shù)量。ulimit 數(shù)量一般我們在服務(wù)器上會放到最大，因此主要就是內(nèi)存。通常一個連接對應(yīng)一讀一寫兩個事件，兩個事件大概占用 96 字節(jié)，連接內(nèi)部大概占用 232 字節(jié)，總共 328 字節(jié)，100000 連接大概占用 31M = 100000 * 328 / 1024 / 1024 。不過具體的還是要根據(jù)實際情況來確定，因為上面的計算只是 Nginx 啟動時沒有其它任務(wù)處理的最簡單的連接占用的內(nèi)存。而且處理的連接越多，CPU 負荷也越大。不過大家可以參考一些面板工具設(shè)置的默認值是多少，比如寶塔設(shè)置的 worker_rlimit_nofile 和 worker_connections 都是 51200 。

以上配置說明為網(wǎng)上找的以及結(jié)合一些自己的理解，有實際經(jīng)驗或者研究過這一塊的大佬可以留言哈，說實話，我也沒怎么配過這個東西，但是，如果 worker_connections 給少了，會明顯地出現(xiàn)一個報錯，那就是 Too many open files 這個問題。一旦看到這個錯誤，就應(yīng)該檢查 ulimit、worker_rlimit_nofile、worker_connections 這些配置的情況，看是不是給得太少了。

其它

在事件模塊中，還有一些平常見得不多的配置，咱們最后一起來了解下。

互斥鎖相關(guān)

accept_mutex on | off;

accept_mutex 是 Nginx 中不同連接之間是否使用互斥鎖進行順序 accept() 系統(tǒng)調(diào)用的配置。如果設(shè)置為 on ，則工作進程將依次接受新連接。否則，所有工作進程都會收到有關(guān)新連接的通知，如果新連接的數(shù)量較低，則一些工作進程可能會浪費系統(tǒng)資源。

在支持 EPOLLEXCLUSIVE 標(biāo)志（1.11.3）的系統(tǒng)上或使用 reuseport （HTTP模塊中的配置）時，無需啟用 accept_mutex 。在版本1.11.3之前，默認值為 on ，現(xiàn)在默認是 off 了。

這個配置最主要的作用是可以用來解決常說的“驚群”問題。大致意思是在某一個時刻，客戶端發(fā)來一個請求連接，Nginx后臺是以多進程的工作模式，也就是說有多個 worker 進程會被同時喚醒，但是最終只會有一個進程可以獲取到連接，如果每次喚醒的進程數(shù)目太多，就會影響 Nginx 的整體性能。如果設(shè)置為 on ，將會對多個 Nginx 進程接收連接進行序列化，一個個來喚醒接收，就防止了多個進程對連接的爭搶。

accept_mutex_delay time;

默認值是 500ms ，和 accept_mutex 相關(guān)。如果啟用了 accept_mutex ，可以指定某個工作進程檢測到其它工作進程正在接入新連接時，自身等待直到重新開始嘗試接入新連接的最大時間間隔。

debug_connection

debug_connection address | CIDR | unix:;

開啟針對特定客戶端連接的調(diào)試日志。除開這些連接，其它連接將使用 error_log 指令設(shè)置的日志級別。 被調(diào)試的連接可以使用 IPv4 或 IPv6 (1.3.0, 1.2.1) 網(wǎng)絡(luò)地址來指定， 也可以使用主機名來設(shè)置連接。 對于UNIX域套接字 (1.3.0, 1.2.1)，使用 “unix:” 參數(shù)來啟用調(diào)試日志。

干嘛用得？不知道，有用過的同學(xué)記得留言，我們一起學(xué)習(xí)哈。

multi_accept

multi_accept on | off;

如果禁用 multi_accept ，工作進程將一次接受一個新連接。否則，工作進程將一次接受所有新連接。如果使用 kqueue 連接處理方式，則忽略該指令，因為 kqueue 可以報告有多少新連接等待接入。

在很多面板應(yīng)用中，這個配置會打開。

總結(jié)

學(xué)了一圈，其實我們會發(fā)現(xiàn)一個問題，那就是 events 中的內(nèi)容其實大部分不太需要我們?nèi)ヅ渲?。正常編譯安裝之后的 events 是這樣的。

events {
 worker_connections  1024;
}

而 寶塔面板 在一臺 CentOS 的服務(wù)器默認安裝完之后是這樣的。

events
{
  use epoll;
  worker_connections 51200;
  multi_accept on;
}

就像上面各個配置中說到的，use 其實可以不用配，然后比較重要的就是 worker_connections ，如果是我自己配的話，直接就上 65535 了，另外 multi_accept 可以打開。更具體的配置，大家還是要根據(jù)業(yè)務(wù)情況，或者請教對這一塊有更深入研究的運維大佬們，同樣的，有心得的小伙伴記得留言，咱們大家一起學(xué)習(xí)進步哦！

參考文檔：

http:///en/docs/ngx_core_module.html

http:///en/docs/events.html