11.1 master-worker 機制

11.1.1 master-worker 工作原理圖

1. 一個 master (進程) 管理多個 worker (進程)

11.1.2 一說 master-worker 機制

• 爭搶機制示意圖

1. 一個 master Process 管理多個 worker process ，也就是說 Nginx 采用的是 多進程結(jié)構(gòu)，而不是多線程結(jié)構(gòu)
2. 當(dāng) client 發(fā)出請求 (任務(wù)) 時，master Process 會通知管理的 worker process
3. worker process 開始爭搶任務(wù)，爭搶到的 worker process 會開啟連接，完成任務(wù)
4. 每個 worker 都是一個獨立的進程，每個進程里只有一個主線程
5. Nginx 采用了 IO 多路復(fù)用機制 (需要在 Linux 環(huán)境) ，使用 IO 多路復(fù)用機制，是 Nginx 在使用為數(shù)不多的 worker process 就可以實現(xiàn)高并發(fā)的關(guān)鍵

11.1.3 二說 master-worker 機制

• Master-Worker 模式

1、Nginx 在啟動后，會有一個 master 進程和多個相互獨立的 worker 進程
2、Master 進程 接收來自外界的信號，向各 worker 進程發(fā)送信號，每個進程都有可能來處理這個連接
3、Master 進程能監(jiān)控 Worker 進程的運行狀態(tài)，當(dāng) worker 進程退出后(異常情況下)，會自動啟動新的 worker 進程

• accept_mutex 解決 “驚群現(xiàn)象”

1、所有子進程都繼承了父進程的 sockfd，當(dāng)連接進來時，所有子進程都將收到通知并 “爭著” 與它建立連接，這就叫 “驚群現(xiàn)象”
2、大量的進程被激活又掛起，只有一個進程可以 accept() 到這個連接，會消耗系統(tǒng)資源
3、Nginx 提供了一個 accept_mutex ，這是一個加在 accept 上的一把共享鎖。即每個 worker 進程在執(zhí)行 accept 之前都需要先獲取鎖，獲取不到就放棄執(zhí)行 accept() 有了這把鎖之后，同一時刻，就只會有一個進程去 accpet()，就不會有驚群問題了
4、當(dāng)一個 worker 進程在 accept() 這個連接之后，就開始讀取請求，解析請求，處理請求，產(chǎn)生數(shù)據(jù)后，再返回給客戶端，最后才斷開連接，完成一個完整的請求
5、一個請求，完全由 worker 進程來處理，而且只能在一個 worker 進程中處理

• 用多進程結(jié)構(gòu)而不用多線程結(jié)構(gòu)的好處

1、節(jié)省鎖帶來的開銷，每個 worker 進程都是獨立的進程，不共享資源，不需要加鎖。在編程以及問題查找上，也會方便很多
2、獨立進程，減少風(fēng)險。采用獨立的進程，可以讓互相之間不會影響，一個進程退出后，其它進程還在工作，服務(wù)不會中斷，master 進程則很快重新啟動新的 worker 進程

• 實現(xiàn)高并發(fā)的秘密 - IO 多路復(fù)用

1、對于 Nginx 來講，一個進程只有一個主線程，那么它是怎么實現(xiàn)高并發(fā)的呢？
2、采用了 IO 多路復(fù)用的原理，通過異步非阻塞的事件處理機制，epoll 模型，實現(xiàn)了輕量級和高并發(fā)
3、nginx 是如何具體實現(xiàn)的呢？

• 舉例來說：每進來一個 request，會有一個 worker 進程去處理。但不是全程的處理，處理到什么程度呢？
• 處理到可能發(fā)生阻塞的地方，比如向上游 (后端) 服務(wù)器轉(zhuǎn)發(fā) request，并等待請求返回
• 那么，這個處理的 worker 不會這么傻等著，他會在發(fā)送完請求后，注冊一個事件：“如果 upstream 返回了，告訴我一聲，我再接著干”。于是他就休息去了
• 此時，如果再有 request 進來，他就可以很快再按這種方式處理
• 而一旦上游服務(wù)器返回了，就會觸發(fā)這個事件，worker 才會來接手，這個 request 才會接著往下走
• 由于 web server 的工作性質(zhì)決定了每個 request 的大部份生命都是在網(wǎng)絡(luò)傳輸中，實際上花費在 server 機器上的時間片不多，這就是幾個進程就能解決高并發(fā)的秘密所在

• 小結(jié)：Nginx 的 master-worker 工作機制的優(yōu)勢

1、支持 nginx -s reload 熱部署，這個特征在前面我們使用過
2、對于每個 worker 進程來說，獨立的進程，不需要加鎖，所以省掉了鎖帶來的開銷，同時在編程以及問題查找時，也會方便很多
3、每個 worker 都是一個獨立的進程，但每個進程里只有一個主線程，通過異步非阻塞的方式 / IO 多路復(fù)用 來處理請求， 即使是高并發(fā)請求也能應(yīng)對
4、采用獨立的進程，互相之間不會影響，一個 worker 進程退出后，其它 worker 進程還在工作，服務(wù)不會中斷，master 進程則很快啟動新的 worker 進程
5、一個 worker 分配一個 CPU ， 那么 worker 的線程可以把一個 cpu 的性能發(fā)揮到極致

11.2 參數(shù)設(shè)置

11.2.1 worker_processes

• 需要設(shè)置多少個 worker ？每個 worker 的線程可以把一個 cpu 的性能發(fā)揮到極致。所以 worker 數(shù)和服務(wù)器的 cpu 數(shù)相等是最為適宜的。設(shè)少了會浪費 cpu，設(shè)多了會造成 cpu 頻繁切換上下文帶來的損耗
• 設(shè)置 worker 數(shù)量，Nginx 默認沒有開啟利用多核 cpu，可以通過增加 worker_cpu_affinity 配置參數(shù)來充分利用多核 cpu 的性能

#2 核 cpu，開啟 2 個進程
worker_processes 2;
worker_cpu_affinity 01 10;

#2 核 cpu，開啟 4 個進程，
worker_processes 4;
worker_cpu_affinity 01 10 01 10;

#4 核 cpu，開啟 2 個進程，0101 表示開啟第一個和第三個內(nèi)核，1010 表示開啟第二個和第四個內(nèi)核；
worker_processes 2;
worker_cpu_affinity 0101 1010;

#4 個 cpu，開啟 4 個進程
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

#8 核 cpu，開啟 8 個進程
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

• worker_cpu_affinity 理解

11.2.1 worker_processes 配置實例

1. vim /usr/local/nginx/nginx.conf ，修改配置文件

2. 重新加載 nginx ，/usr/local/nginx/sbin/nginx -s reload

3. 查看 nginx 的 worker process 情況 ps -ef | grep nginx

11.2.3 worker_connection

1. worker_connection 表示每個 worker 進程所能建立連接的最大值，所以，一個 nginx 能建立的最大連接數(shù)，應(yīng)該是 worker_connections * worker_processes

   ① 默認：worker_connections: 1024
   ② 調(diào)大：worker_connections: 60000（調(diào)大到 6 萬連接）
   ③ 同時要根據(jù)系統(tǒng)的最大打開文件數(shù)來調(diào)整

• 系統(tǒng)的最大打開文件數(shù)>= worker_connections*worker_process
• 根據(jù)系統(tǒng)的最大打開文件數(shù)來調(diào)整，worker_connections 進程連接數(shù)量要小于等于系統(tǒng)的最大打開文件數(shù)
• worker_connections 進程連接數(shù)量真實數(shù)量= worker_connections * worker_process
• 查看系統(tǒng)的最大打開文件數(shù)： ulimit -a | grep "open files"

2. 根據(jù)最大連接數(shù)計算最大并發(fā)數(shù)：

   • 如果是支持 http1.1 的瀏覽器每次訪問要占兩個連接，所以普通的靜態(tài)訪問最大并發(fā)數(shù)是： worker_connections * worker_processes /2
   • 而如果是 HTTP 作為反向代理來說，最大并發(fā)數(shù)量應(yīng)該是 worker_connections * worker_processes/4
   • 因為作為反向代理服務(wù)器，每個并發(fā)會建立與客戶端的連接和與后端服務(wù)的連接，會各占用兩個連接
   • 看一個示意圖

11.2.4 配置 Linux 最大打開文件數(shù)

1. 使用 ulimit -a 可以查看當(dāng)前系統(tǒng)的所有限制值，使用 ulimit -n 可以查看當(dāng)前的最大打開文件數(shù)

2. 新裝的 linux 默認只有 1024，當(dāng)作負載較大的服務(wù)器時，很容易遇到 error: too many open files 因此，需要將其改大

3. 使用 ulimit -n 65535 可即時修改，但重啟后就無效了 (注 ulimit -SHn 65535 等效 ulimit -n 65535，-S 指 soft，-H 指 hard)

4. 有如下三種修改方式：

   ① 在 /etc/rc.local 中增加一行 ulimit -SHn 65535
   ② 在 /etc/profile 中增加一行 ulimit -SHn 65535
   ③ 在 /etc/security/limits.conf 最后增加如下兩行記錄，然后重啟系統(tǒng)

* soft nofile 65535
* hard nofile 65535

• 注意：在 CentOS 中使用第 ① 種方式無效果，使用第 ③ 種方式有效果，而在 Debian 中使用第 ② 種有效果

5. 如果重啟系統(tǒng)，報內(nèi)核錯誤，需要編輯 /etc/pam.d/login 配置文件，在最后添加以下一條內(nèi)容：

 vim /etc/pam.d/login 

session    required     pam_limits.so

• 編輯完成，重啟系統(tǒng)，就會發(fā)現(xiàn)最大文件數(shù)已經(jīng)配置成功

文章來源地址http://www.zghlxwxcb.cn/news/detail-410333.html

到了這里，關(guān)于11. Nginx 工作機制&參數(shù)設(shè)置的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！