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

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

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

events {……………………}

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

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

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

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

好了，接下來(lái)我們就看看在具體的 events 模塊中，我們可以進(jìn)行哪些配置。

指定 IO 模塊

使用的是 use ，注意，和 user 只差一個(gè) r 哦，而且它是寫(xiě)在 events 的花括號(hào)里面的。

use method;

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

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

worker_aio_requests number;

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

連接數(shù)

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

worker_connections number;

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

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

max_clients = worker_processes * worker_connections

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

max_clients = worker_processes * worker_connections/4

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

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

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

其它

在事件模塊中，還有一些平常見(jiàn)得不多的配置，咱們最后一起來(lái)了解下。

互斥鎖相關(guān)

accept_mutex on | off;

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

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

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

accept_mutex_delay time;

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

debug_connection

debug_connection address | CIDR | unix:;

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

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

multi_accept

multi_accept on | off;

如果禁用 multi_accept ，工作進(jìn)程將一次接受一個(gè)新連接。否則，工作進(jìn)程將一次接受所有新連接。如果使用 kqueue 連接處理方式，則忽略該指令，因?yàn)?kqueue 可以報(bào)告有多少新連接等待接入。

在很多面板應(yīng)用中，這個(gè)配置會(huì)打開(kāi)。

總結(jié)

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

events {
 worker_connections  1024;
}

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

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

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

參考文檔：

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

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