1、Nginx的基礎介紹

nginx簡介 

一、經常使用來提供靜態Web服務的軟件有以下三種：

Apache: 
這是中小型Web服務的主流，Web服務器中的老大哥。

Nginx：   
大型網站Web服務的主流，曾經Web服務器中的初生牛犢，現已長大。
Nginx的分支Tengine（http://tengine.taobao.org/）目前也在飛速發展。

Lighttpd：
這是一個不溫不火的優秀Web軟件，社區不活躍，靜態解析效率很高。
在Nginx流行前，它是大併發靜態業務的首選，國內百度貼吧、豆瓣等衆多網站都有Lighttpd奮鬥的身影。
    
二、經常使用來提供動態服務的軟件

PHP（FastCGI）：
大中小型網站都會使用，動態網頁語言PHP程序的解析容器。它可配合Apache解析動態程序，不過，這裏的PHP不是FastCGI守護進程模式，而是mod_php5.so（module）。也可配合Nginx解析動態程序，此時的PHP經常使用FastCGI守護進程模式提供服務。

Tomcat：
中小企業動態Web服務主流，互聯網Java容器主流（如jsp、do）。

Resin：
大型動態Web服務主流，互聯網Java容器主流（如jsp、do）。
    
三、 nginx軟件服務介紹

若是你據說或使用過Apache軟件，那麼很快就會熟悉Nginx軟件，與Apache軟件相似，Nginx（「engine x」）是一個開源的，支持高性能、高併發的WWW服務器和代理服務軟件。它是由俄羅斯人lgor Sysoev開發的，最初被應用在俄羅斯的大型網站www.rambler.ru上。後來做者將源代碼以類BSD許可證的形式開源出來供全球使用。
Nginx能夠運行在UNIX、Linux、BSD、Mac OS X、Solaris，以及Microsoft Windows等操做系統中 。   



 
四、nginx軟件特徵介紹

- 1）. 支持高併發：能支持幾萬併發鏈接（特別是靜態小文件業務環境）
- 2）. 資源消耗少：在3萬併發鏈接下，開啓10個Nginx線程消耗的內存不到200MB
- 3）. 支持異步網絡I/O事件模型epoll（Linux 2.6+） apache（select）
     
四、 nginx軟件功能介紹

- 1）做爲Web服務軟件（處理用戶訪問靜態請求）
- 2）反向代理或負載均衡服務
- 3）前端業務數據緩存服務
    
五、nginx軟件模型特色說明

- apache與nginx軟件對比說明
- apache使用select模型
- nginx使用epoll模型
- 舉例說明：宿舍管理員
- select模型版管理員  會一個一個房間查詢人員
- epoll模型版管理員   會進行檢索後，直接找到須要找的人
- 舉例說明：幼兒園阿姨
- select模型版阿姨    會一個一個小朋友進行詢問，確認哪一個小朋友須要上廁所
- epoll模型版阿姨     會告知想上廁所小朋友自覺站到響應位置

- Select特色：select 選擇句柄的時候，是遍歷全部句柄，也就是說句柄有事件響應時，select須要遍歷全部句柄才能獲取到哪些句柄有事件通知，所以效率是很是低。
epoll的特色：epoll對於句柄事件的選擇不是遍歷的，是事件響應的，就是句柄上事件來就立刻選擇出來，不須要
- 遍歷整個句柄鏈表，所以效率很是高。


六、Nginx相對於Apache的優勢

- 1)    高併發響應性能很是好，官方Nginx給出處理靜態文件併發5W/S
- 2)    負載均衡及反向代理性能很是強
- 3)    系統內存和CPU佔用率低
- 4)    可對後端服務經行健康檢查
- 5)    支持PHP CGI和FastCGI
- 6)    能夠做爲緩存服務器、郵件代理服務器
- 7)    配置代碼簡單

2、Nginx的工做進程

在工做方式上，Nginx分爲單工做進程和多工做進程兩種模式。在單工做進程模式下，除主進程外，還有一個工做進程，工做進程是單線程的;在多工做進程模式下，每一個工做進程包含多個線程。Nginx默認爲單工做進程模式。

Nginx在啓動後，會有一個master進程和多個worker進程。

master進程：

主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控worker進程的運行狀態，當worker進程退出後(異常狀況下)，會自動從新啓動新的worker進程。
master進程充當整個進程組與用戶的交互接口，同時對進程進行監護。它不須要處理網絡事件，不負責業務的執行，只會經過管理worker進程來實現重啓服務、平滑升級、更換日誌文件、配置文件實時生效等功能。
咱們要控制nginx，只須要經過kill向master進程發送信號就好了。好比kill -HUP pid，則是告訴nginx，從容地重啓nginx，咱們通常用這個信號來重啓nginx，或從新加載配置，由於是從容地重啓，所以服務是不中斷的。master進程在接收到HUP信號後是怎麼作的呢？首先master進程在接到信號後，會先從新加載配置文件，而後再啓動新的worker進程，並向全部老的worker進程發送信號，告訴他們能夠光榮退休了。新的worker在啓動後，就開始接收新的請求，而老的worker在收到來自master的信號後，就再也不接收新的請求，而且在當前進程中的全部未處理完的請求處理完成後，再退出。固然，直接給master進程發送信號，這是比較老的操做方式，nginx在0.8版本以後，引入了一系列命令行參數，來方便咱們管理。好比，./nginx -s reload，就是來重啓nginx，./nginx -s stop，就是來中止nginx的運行。如何作到的呢？咱們仍是拿reload來講，咱們看到，執行命令時，咱們是啓動一個新的nginx進程，而新的nginx進程在解析到reload參數後，就知道咱們的目的是控制nginx來從新加載配置文件了，它會向master進程發送信號，而後接下來的動做，就和咱們直接向master進程發送信號同樣了。

worker進程：

基於的網絡事件，則是放在worker進程中來處理了。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。worker進程的個數是能夠設置的，通常咱們會設置與機器cpu核數一致，這裏面的緣由與nginx的進程模型以及事件處理模型是分不開的。

worker進程之間是平等的，每一個進程，處理請求的機會也是同樣的。當咱們提供80端口的http服務時，一個鏈接請求過來，每一個進程都有可能處理這個鏈接，怎麼作到的呢？首先，每一個worker進程都是從master進程fork過來，在master進程裏面，先創建好須要listen的socket（listenfd）以後，而後再fork出多個worker進程。全部worker進程的listenfd會在新鏈接到來時變得可讀，爲保證只有一個進程處理該鏈接，全部worker進程在註冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進程註冊listenfd讀事件，在讀事件裏調用accept接受該鏈接。當一個worker進程在accept這個鏈接以後，就開始讀取請求，解析請求，處理請求，產生數據後，再返回給客戶端，最後才斷開鏈接，這樣一個完整的請求就是這樣的了。咱們能夠看到，一個請求，徹底由worker進程來處理，並且只在一個worker進程中處理。worker進程之間是平等的，每一個進程，處理請求的機會也是同樣的。當咱們提供80端口的http服務時，一個鏈接請求過來，每一個進程都有可能處理這個鏈接，怎麼作到的呢？首先，每一個worker進程都是從master進程fork過來，在master進程裏面，先創建好須要listen的socket（listenfd）以後，而後再fork出多個worker進程。全部worker進程的listenfd會在新鏈接到來時變得可讀，爲保證只有一個進程處理該鏈接，全部worker進程在註冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進程註冊listenfd讀事件，在讀事件裏調用accept接受該鏈接。當一個worker進程在accept這個鏈接以後，就開始讀取請求，解析請求，處理請求，產生數據後，再返回給客戶端，最後才斷開鏈接，這樣一個完整的請求就是這樣的了。咱們能夠看到，一個請求，徹底由worker進程來處理，並且只在一個worker進程中處理。