自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

從底層原理分析Nginx為什么這么快

開發(fā) 架構(gòu) 服務(wù)器
請求是連接到 Nginx,Master 進(jìn)程負(fù)責(zé)處理和轉(zhuǎn)發(fā)?如何選定哪個 Worker 進(jìn)程處理請求?請求的處理結(jié)果,是否還要經(jīng)過 Master 進(jìn)程?

[[323938]]

 Nginx 的進(jìn)程模型

 

從底層原理分析Nginx為什么這么快

 

Nginx 服務(wù)器,正常運行過程中:

  1. 多進(jìn)程:一個 Master 進(jìn)程、多個 Worker 進(jìn)程
  2. Master 進(jìn)程:管理 Worker 進(jìn)程
  3. 對外接口:接收外部的操作(信號)
  4. 對內(nèi)轉(zhuǎn)發(fā):根據(jù)外部的操作的不同,通過信號管理 Worker
  5. 監(jiān)控:監(jiān)控 worker 進(jìn)程的運行狀態(tài),worker 進(jìn)程異常終止后,自動重啟 worker 進(jìn)程
  6. Worker 進(jìn)程:所有 Worker 進(jìn)程都是平等的
  7. 實際處理:網(wǎng)絡(luò)請求,由 Worker 進(jìn)程處理;
  8. Worker 進(jìn)程數(shù)量:在 nginx.conf 中配置,一般設(shè)置為核心數(shù),充分利用 CPU 資源,同時,避免進(jìn)程數(shù)量過多,避免進(jìn)程競爭 CPU 資源,增加上下文切換的損耗。

思考:

請求是連接到 Nginx,Master 進(jìn)程負(fù)責(zé)處理和轉(zhuǎn)發(fā)?

如何選定哪個 Worker 進(jìn)程處理請求?請求的處理結(jié)果,是否還要經(jīng)過 Master 進(jìn)程?

 

從底層原理分析Nginx為什么這么快

 

HTTP 連接建立和請求處理過程:

  1. Nginx 啟動時,Master 進(jìn)程,加載配置文件
  2. Master 進(jìn)程,初始化監(jiān)聽的 socket
  3. Master 進(jìn)程,fork 出多個 Worker 進(jìn)程
  4. Worker 進(jìn)程,競爭新的連接,獲勝方通過三次握手,建立 Socket 連接,并處理請求

Nginx 高性能、高并發(fā):

  1. Nginx 采用:多進(jìn)程 + 異步非阻塞方式(IO 多路復(fù)用 epoll)
  2. 請求的完整過程:
  3. 建立連接
  4. 讀取請求:解析請求
  5. 處理請求
  6. 響應(yīng)請求
  7. 請求的完整過程,對應(yīng)到底層,就是:讀寫 socket 事件

Nginx 的事件處理模型

request:Nginx 中 http 請求。

基本的 HTTP Web Server 工作模式:

  • 接收請求:逐行讀取請求行和請求頭,判斷段有請求體后,讀取請求體
  • 處理請求
  • 返回響應(yīng):根據(jù)處理結(jié)果,生成相應(yīng)的 HTTP 請求(響應(yīng)行、響應(yīng)頭、響應(yīng)體)

Nginx 也是這個套路,整體流程一致。

 

從底層原理分析Nginx為什么這么快

 

模塊化體系結(jié)構(gòu)

 

從底層原理分析Nginx為什么這么快

 

nginx的模塊根據(jù)其功能基本上可以分為以下幾種類型:

  • event module: 搭建了獨立于操作系統(tǒng)的事件處理機制的框架,及提供了各具體事件的處理。包括ngx_events_module, ngx_event_core_module和ngx_epoll_module等。nginx具體使用何種事件處理模塊,這依賴于具體的操作系統(tǒng)和編譯選項。
  • phase handler: 此類型的模塊也被直接稱為handler模塊。主要負(fù)責(zé)處理客戶端請求并產(chǎn)生待響應(yīng)內(nèi)容,比如ngx_http_static_module模塊,負(fù)責(zé)客戶端的靜態(tài)頁面請求處理并將對應(yīng)的磁盤文件準(zhǔn)備為響應(yīng)內(nèi)容輸出。
  • output filter: 也稱為filter模塊,主要是負(fù)責(zé)對輸出的內(nèi)容進(jìn)行處理,可以對輸出進(jìn)行修改。例如,可以實現(xiàn)對輸出的所有html頁面增加預(yù)定義的footbar一類的工作,或者對輸出的圖片的URL進(jìn)行替換之類的工作。
  • upstream: upstream模塊實現(xiàn)反向代理的功能,將真正的請求轉(zhuǎn)發(fā)到后端服務(wù)器上,并從后端服務(wù)器上讀取響應(yīng),發(fā)回客戶端。upstream模塊是一種特殊的handler,只不過響應(yīng)內(nèi)容不是真正由自己產(chǎn)生的,而是從后端服務(wù)器上讀取的。
  • load-balancer: 負(fù)載均衡模塊,實現(xiàn)特定的算法,在眾多的后端服務(wù)器中,選擇一個服務(wù)器出來作為某個請求的轉(zhuǎn)發(fā)服務(wù)器。

常見問題剖析

Nginx vs. Apache

網(wǎng)絡(luò) IO 模型:

  • nginx:IO 多路復(fù)用,epoll(freebsd 上是 kqueue )
  • 高性能
  • 高并發(fā)
  • 占用系統(tǒng)資源少
  • apache:阻塞 + 多進(jìn)程/多線程
  • 更穩(wěn)定,bug 少
  • 模塊更豐富

場景:

處理多個請求時,可以采用:IO 多路復(fù)用 或者 阻塞 IO +多線程

  • IO 多路服用:一個 線程,跟蹤多個 socket 狀態(tài),哪個就緒,就讀寫哪個;
  • 阻塞 IO + 多線程:每一個請求,新建一個服務(wù)線程

思考:IO 多路復(fù)用 和 多線程 的適用場景?

  • IO 多路復(fù)用:單個連接的請求處理速度沒有優(yōu)勢,適合 IO 密集型 場景,事件驅(qū)動
  • 大并發(fā)量:只使用一個線程,處理大量的并發(fā)請求,降低上下文環(huán)境切換損耗,也不需要考慮并發(fā)問題,相對可以處理更多的請求;
  • 消耗更少的系統(tǒng)資源(不需要線程調(diào)度開銷)
  • 適用于長連接的情況(多線程模式長連接容易造成線程過多,造成頻繁調(diào)度)
  • 阻塞IO + 多線程:實現(xiàn)簡單,可以不依賴系統(tǒng)調(diào)用,適合 CPU 密集型 場景
  • 每個線程,都需要時間和空間;
  • 線程數(shù)量增長時,線程調(diào)度開銷指數(shù)增長

Nginx 最大連接數(shù)

基礎(chǔ)背景:

  • Nginx 是多進(jìn)程模型,Worker 進(jìn)程用于處理請求;
  • 單個進(jìn)程的連接數(shù)(文件描述符 fd),有上限(nofile):ulimit -n
  • Nginx 上配置單個 worker 進(jìn)程的最大連接數(shù):worker_connections 上限為 nofile
  • Nginx 上配置 worker 進(jìn)程的數(shù)量:worker_processes

因此,Nginx 的最大連接數(shù):

  1. Nginx 的最大連接數(shù):Worker 進(jìn)程數(shù)量 x 單個 Worker 進(jìn)程的最大連接數(shù)
  2. 上面是 Nginx 作為通用服務(wù)器時,最大的連接數(shù)
  3. Nginx 作為反向代理服務(wù)器時,能夠服務(wù)的最大連接數(shù):(Worker 進(jìn)程數(shù)量 x 單個 Worker 進(jìn)程的最大連接數(shù))/ 2。
  4. Nginx 反向代理時,會建立 Client 的連接和后端 Web Server 的連接,占用 2 個連接

思考:

  • 每打開一個 socket 占用一個 fd
  • 為什么,一個進(jìn)程能夠打開的 fd 數(shù)量有限制?

IO 模型

場景:

處理多個請求時,可以采用:IO 多路復(fù)用 或者 阻塞 IO +多線程

  • IO 多路服用:一個 線程,跟蹤多個 socket 狀態(tài),哪個就緒,就讀寫哪個;
  • 阻塞 IO + 多線程:每一個請求,新建一個服務(wù)線程

思考:IO 多路復(fù)用 和 多線程 的適用場景?

  • IO 多路復(fù)用:單個連接的請求處理速度沒有優(yōu)勢
  • 大并發(fā)量:只使用一個線程,處理大量的并發(fā)請求,降低上下文環(huán)境切換損耗,也不需要考慮并發(fā)問題,相對可以處理更多的請求;
  • 消耗更少的系統(tǒng)資源(不需要線程調(diào)度開銷)
  • 適用于長連接的情況(多線程模式長連接容易造成線程過多,造成頻繁調(diào)度)
  • 阻塞IO + 多線程:實現(xiàn)簡單,可以不依賴系統(tǒng)調(diào)用。
  • 每個線程,都需要時間和空間;
  • 線程數(shù)量增長時,線程調(diào)度開銷指數(shù)增長

select/poll 和 epoll 比較

詳細(xì)內(nèi)容,參考:

  • select poll epoll三者之間的比較

select/poll 系統(tǒng)調(diào)用:

  1. // select 系統(tǒng)調(diào)用 
  2. int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout);  
  3. // poll 系統(tǒng)調(diào)用 
  4. int poll(struct pollfd fds[], nfds_t nfds, int timeout); 

select:

  • 查詢 fd_set 中,是否有就緒的 fd,可以設(shè)定一個超時時間,當(dāng)有 fd (File descripter) 就緒或超時返回;
  • fd_set 是一個位集合,大小是在編譯內(nèi)核時的常量,默認(rèn)大小為 1024

特點:

  • 連接數(shù)限制,fd_set 可表示的 fd 數(shù)量太小了;
  • 線性掃描:判斷 fd 是否就緒,需要遍歷一邊 fd_set;
  • 數(shù)據(jù)復(fù)制:用戶空間和內(nèi)核空間,復(fù)制連接就緒狀態(tài)信息

poll:

  • 解決了連接數(shù)限制:
  • poll 中將 select 中的 fd_set 替換成了一個 pollfd 數(shù)組
  • 解決 fd 數(shù)量過小的問題
  • 數(shù)據(jù)復(fù)制:用戶空間和內(nèi)核空間,復(fù)制連接就緒狀態(tài)信息

epoll: event 事件驅(qū)動

  • 事件機制:避免線性掃描
  • 為每個 fd,注冊一個監(jiān)聽事件
  • fd 變更為就緒時,將 fd 添加到就緒鏈表
  • fd 數(shù)量:無限制(OS 級別的限制,單個進(jìn)程能打開多少個 fd)

select,poll,epoll:

  1. I/O多路復(fù)用的機制;
  2. I/O多路復(fù)用就通過一種機制,可以監(jiān)視多個描述符,一旦某個描述符就緒(一般是讀就緒或者寫就緒),能夠通知程序進(jìn)行相應(yīng)的讀寫操作。
  3. 監(jiān)視多個文件描述符
  4. 但select,poll,epoll本質(zhì)上都是同步I/O:
  5. 用戶進(jìn)程負(fù)責(zé)讀寫(從內(nèi)核空間拷貝到用戶空間),讀寫過程中,用戶進(jìn)程是阻塞的;
  6. 異步 IO,無需用戶進(jìn)程負(fù)責(zé)讀寫,異步IO,會負(fù)責(zé)從內(nèi)核空間拷貝到用戶空間;

Nginx 的并發(fā)處理能力

關(guān)于 Nginx 的并發(fā)處理能力:

并發(fā)連接數(shù),一般優(yōu)化后,峰值能保持在 1~3w 左右。(內(nèi)存和 CPU 核心數(shù)不同,會有進(jìn)一步優(yōu)化空間)

責(zé)任編輯:武曉燕 來源: 今日頭條
相關(guān)推薦

2020-02-27 15:44:41

Nginx服務(wù)器反向代理

2020-02-27 21:03:30

調(diào)度器架構(gòu)效率

2024-02-26 21:15:20

Kafka緩存參數(shù)

2020-02-19 08:08:24

Nginx功能

2020-03-30 15:05:46

Kafka消息數(shù)據(jù)

2020-10-15 09:19:36

Elasticsear查詢速度

2021-05-27 20:56:51

esbuild 工具JavaScript

2023-08-29 07:46:08

Redis數(shù)據(jù)ReHash

2020-09-27 08:12:09

Nginx反向代理負(fù)載均衡

2020-10-27 09:18:16

ClickHouse數(shù)據(jù)庫架構(gòu)

2023-03-21 08:02:36

Redis6.0IO多線程

2019-12-18 09:42:19

技術(shù) Linux網(wǎng)絡(luò)

2021-03-18 14:34:34

達(dá)達(dá)集團京東云電商

2023-11-02 10:22:29

gRPC后端通信

2022-01-04 08:54:32

Redis數(shù)據(jù)庫數(shù)據(jù)類型

2024-07-24 08:38:07

2024-11-26 08:52:34

SQL優(yōu)化Kafka

2020-10-21 09:17:52

Redis面試內(nèi)存

2017-06-06 16:30:55

戴爾交付保障

2013-06-19 10:55:40

Disruptor并發(fā)框架
點贊
收藏

51CTO技術(shù)棧公眾號