nginx簡介

Nginx ("engine x") 是一個高性能的網站用戶有:淘寶、百度、新浪、網易、騰訊等。

nginx應用場景

1、結構圖：

nginx的主要特點

高并發連接: 官方稱單節點支持5萬并發連接數，實際生產環境能夠承受2-3萬并發。內存消耗少: 在3萬并發連接下，開啟10個nginx進程僅消耗150M內存 (15M*10=150M)配置簡單成本低廉: 開源免費支持rewrite重寫規則: 能夠根據域名、url的不同，將模型簡介)

阻塞(blocking)非阻塞(nonblocking )同步(synchronous )阻塞I/O(blocking I/O)I/O多路復用非阻塞I/O(nonblocking I/O)信號驅動異步(asynchronous )異步I/O基本概念

I/O涉及的對象：應用程序進程(簡稱進程)操作系統內核(簡稱內核)I/O經歷的過程(以讀操作為例)：等待數據準備(簡稱準備過程)將數據從內核拷貝到進程(簡稱拷貝過程)阻塞：進程在準備過程中阻塞地等待非阻塞：進程在準備過程中不會阻塞同步：進程在拷貝過程中需要阻塞等待異步：進程在拷貝過程中不需要阻塞等待

同步阻塞I/O阻塞I/O

最常見也是默認情況下我們會使用的，進程發起read操作后，進程阻塞等待數據準備就緒，進程阻塞等待內核將數據拷貝到進程中。

I/O多路復用

所謂的select、epoll，又叫事件驅動I/O。在java中叫nio，進程發起一個或多個socket的read請求后：用select/epoll方法阻塞等待數據就緒，一旦有至少一個就緒，進程阻塞等待內核拷貝數據到進程中。處理單個連接并不比阻塞I/O快。好處在于可以提高并發性，一個線程可同時處理多個連接。

同步非阻塞I/O非阻塞I/O

進程發起read操作后

進程無需阻塞等待數據準備就緒，若未就緒立即返回err進程過一段時間后再次發起read操作，詢問是否準備就緒若已經準備就緒，則進程阻塞等待內核將數據拷貝到進程中信號驅動I/O

進程發起read操作時，注冊信號handler

進程無需阻塞等待數據準備就緒數據就緒后內核通過信號通知進程，并調用進程注冊的信號handler進程阻塞等待數據拷貝異步非阻塞I/O

進程發起read操作，將socket和接收數據的buffer傳遞給內核后：

無需阻塞等待數據準備就緒數據就緒后也無需阻塞等待內核拷貝數據內核拷貝數據完成后發送信號通知進程數據已經可用nginx 如何保證強大的并發能力

nginx使用epoll(linux2.6內核)和kqueue(freebsd)網絡模型，而apache使用傳統的select模型epoll 與 select都是 I/O 多路復用epoll是當前在Linux下開發大規模并發網絡程序的熱門選擇。

select模型與epoll模型的對比

select模型的缺點

最大并發數限制，因為一個進程所打開的FD（文件描述符）是有限制的，由FD_SETSIZE設置，默認值是1024/2048，因此Select模型的最大并發數就被相應限制了。自己改改這個FD_SETSIZE？想法雖好，可是先看看下面吧…效率問題，select每次調用都會線性掃描全部的FD集合，這樣效率就會呈現線性下降，把FD_SETSIZE改大的后果就是，大家都慢慢來，什么？都超時了。內核/用戶空間 內存拷貝問題，如何讓內核把FD消息通知給用戶空間呢？在這個問題上select采取了內存拷貝方法。注：從上面看，select和epoll都需要在返回后，通過遍歷文件描述符來獲取就緒的socket。事實上，同時連接的大量客戶端在同一時刻只有很少處于就緒狀態，因此隨著監視的文件數量增長，其效率也會呈現線性下降。

epoll 模型的優點：

相對于select和poll來說，epoll更加靈活，沒有描述符限制(它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大于2048,舉個例子,在1GB內存的機器上大約是10萬左右，具體數目可以cat/proc/sys/fs/file-max察看)。epoll使用一個文件描述符管理多個描述符，將用戶關系的文件描述符的事件存放到內核的一個事件表中，這樣在用戶空間和內核空間的copy只需一次。IO的效率不會隨著監視fd的數量的增長而下降。epoll不同于select和poll輪詢的方式，而是通過每個fd定義的回調函數來實現的。只有就緒的fd才會執行回調函數。內存拷貝，Epoll在這點上使用了“共享內存”，這個內存拷貝也省略了。注：Epoll不僅會告訴應用程序有I/O事件到來，還會告訴應用程序相關的信息，根據這些信息應用程序就能直接定位到事件，而不必遍歷整個FD集合nginx配置實例

反向代理緩存靜態化文件

Tomcat的整體結構介紹

Tomcat的整體架構圖下:

相關組件的大致介紹如下:

Server組件:Server組件是最頂級的組件,它代表Tomcat的運行實例,在一個JVM中只會包含一個Server。在Server的整個生命周期中,Server組件中的Listener組件實現事件的監聽并完成相應的任務,此外Server中包含的GlobalNamingResources組件是為了方便在Tomcat中集成JNDI。除了這兩個組件,Server的核心組件就是Service組件Service組件:Service是服務的抽象,它代表請求從接收到處理的所有組件的集合,一個Server組件可以包含多個Service組件,每一個Service組件都包含了若干的用于接受客戶端消息的Connector組件和處理請求的Engine組件以及一些Executor組件。其中不同的Connector組件使用不同的通信協議,如組件的關系圖如下:

,此外,Connector組件中還包含有Mapper組件和CoyoteAdapter組件。 Mapper組件:客戶端請求的路由導航組件,通過它能夠對一個完整的請求地址進行路由,從而根據請求地址找到對應的Servlet。 CoyoteAdapter組件:一個將Connector和Container適配起來的適配器。容器組件Tomcat內部有4個級別的容器,分別是Engine、Host、Context和Wrapper。

Engine組件:

Engine代表全局的Servlet引擎,每一個Service組件只能包含一個Engine容器組件,但是一個Engine組件可以包含多個Host組件,除了Host組件之外,還包含以下的組件。

Host組件:

Tomcat中Host組件代表的是虛擬主機,其中存放著若干的抽象的Web應用。Host組件除了包含Context組件之外還包含以下的組件

Context組件:

Context組件是Web應用的抽象,其包含了各種靜態資源、若干Servlet(Wrapper容器)以及各種其他動態資源。其除了包含主要的Wrapper組件之外還包括以下的組件:

Wrapper組件:

一個Wrapper組件對應著一個Servlet,其主要包含以下的組件

小結總之,Tomcat從功能上可以抽象的看做是由連接器組件(Connector)和容器組件(Container)組成。Connector組件負責在服務器端處理客戶端的連接,包括接受客戶端的連接、接受客戶端的消息,對消息報文進行解析。Container組件負責對客戶端的請求進行邏輯處理然后把結果返回給客戶端

作者：FuyunWang鏈接：來源：掘金著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。