前言
Nginx是一款輕量級的Web服務器、反向代理服務器，由於它的內存佔用少（一個worker進程只佔用10-12M內存），啟動極快，高併發能力強，在互聯網項目中廣泛應用。
上圖基本上說明了當下流行的技術架構，其中Nginx有點入口網關的味道。
反向代理服務器
經常聽人說到一些術語，如反向代理，那麼什麼是反向代理，什麼又是正向代理呢？下面是一個簡單的總結，更為詳細的說明請閱讀前面文章正向代理和反向代理（請戳我）。
正向代理
由於防火牆的原因，我們並不能直接訪問谷歌，那麼我們可以藉助VPN來實現，這就是一個簡單的正向代理的例子。這裡你能夠發現，正向代理“代理”的是客戶端，而且客戶端是知道目標的，而目標是不知道客戶端是通過VPN訪問的。
正向代理示意圖
反向代理
當我們在外網訪問百度的時候，其實會進行一個轉發，代理到內網去，這就是所謂的反向代理，即反向代理“代理”的是服務器端，而且這一個過程對於客戶端而言是透明的。
反向代理示意圖
Nginx的Master-Worker模式
要啟動nginx，只需要輸入命nginx，其中xxx是你nginx的安裝目錄。
nginx進程
啟動Nginx後，其實就是在80端口啟動了Socket服務進行監聽，如圖所示，Nginx涉及Master進程和Worker進程。
Master-Worker模式
Master進程的作用：讀取並驗證配置文件nginx.conf；管理worker進程；
Worker進程的作用：每一個Worker進程都維護一個線程（避免線程切換），處理連接和請求；注意Worker進程的個數由配置文件決定，一般和CPU個數相關（有利於進程切換），配置幾個就有幾個Worker進程，上面的例子只有1個Worker進程。
思考1：Nginx如何做到熱部署？
所謂熱部署，就是配置文件nginx.conf修改後，不需要stop Nginx，不需要中斷請求，就能讓配置文件生效！（nginx -s reload 重新加載/nginx -t檢查配置/nginx -s stop）
通過上文我們已經知道worker進程負責處理具體的請求，那麼如果想達到熱部署的效果，可以想象：
方案一：修改配置文件nginx.conf後，主進程master負責推送給worker進程更新配置信息，worker進程收到信息後，更新進程內部的線程信息。
方案二：修改配置文件nginx.conf後，重新生成新的worker進程，當然會以新的配置進行處理，而且新的請求都必須交給新的worker進程，至於老worker進程，等把那些以前的請求處理完畢，kill掉即可。
Nginx採用的就是方案二來達到熱部署的！
思考2：Nginx如何做到高併發下的高效處理？
上文已經提及Nginx的worker進程個數與CPU綁定、worker進程內部包含一個線程高效迴環處理請求，這的確有助於效率，但這是不夠的。
作為專業的程序員，我們可以開一下腦洞：BIO/NIO/AIO、異步/同步、阻塞/非阻塞...
要同時處理那麼多的請求，要知道，有的請求需要發生IO，可能需要很長時間，如果等著它，就會拖慢worker的處理速度。
Nginx採用了Linux的epoll模型，epoll模型基於事件驅動機制，它可以監控多個事件是否準備完畢，如果OK，那麼放入epoll隊列中，這個過程是異步的。worker只需要從epoll隊列循環處理即可。
思考3：Nginx掛了怎麼辦？
Nginx既然作為入口網關，很重要，如果出現單點問題，顯然是不可接受的。答案是：
Keepalived+Nginx實現高可用。Keepalived是一個高可用解決方案，主要是用來防止服務器單點發生故障，可以通過和Nginx配合來實現Web服務的高可用。（其實，Keepalived不僅僅可以和Nginx配合，還可以和很多其他服務配合）
Keepalived+Nginx實現高可用的思路：
第一：請求不要直接打到Nginx上，應該先通過Keepalived（這就是所謂虛擬IP，VIP）
第二：Keepalived應該能監控Nginx的生命狀態（提供一個用戶自定義的腳本，定期檢查Nginx進程狀態，進行權重變化,，從而實現Nginx故障切換）
Keepalived+Nginx
我們的主戰場：nginx.conf
很多時候，在開發、測試環境下，我們都得自己去配置Nginx，就是去配置nginx.conf。nginx.conf是典型的分段配置文件，下面我們來分析下。在 Nginx 內部，你可以指定多個虛擬服務器，每個虛擬服務器用 server{} 上下文描述。
虛擬主機
nginx的配置文件主要由指令構成，指令主要包括名稱和參數，以分號;結束。如下是一個虛擬服務器的配置：listen 指令來指定該虛擬主機在監聽給定的 IP 端口組合；server_name指令檢測 Host 頭以決定請求到底匹配到哪個虛擬主機...nginx的配置項很多，具體可以查閱網上資料。
http的server段
訪問結果
其實這是把Nginx作為web server來處理靜態資源，
1：location可以進行正則匹配，應該注意正則的幾種形式以及優先級。（這裡不展開）
2：Nginx能夠提高速度的其中一個特性就是：動靜分離，就是把靜態資源放到Nginx上，由Nginx管理，動態請求轉發給後端。
3：我們可以在Nginx下把靜態資源、日誌文件歸屬到不同域名下（也即是目錄），這樣方便管理維護。
4：Nginx可以進行IP訪問控制，有些電商平臺，就可以在Nginx這一層，做一下處理，內置一個黑名單模塊，那麼就不必等請求通過Nginx達到後端在進行攔截，而是直接在Nginx這一層就處理掉。
反向代理---proxy_pass
所謂反向代理，很簡單，其實就是在location這一段配置中的root替換成proxy_pass即可。root說明是靜態資源，可以由Nginx進行返回;而proxy_pass說明是動態請求，需要進行轉發，比如代理到Tomcat上。
反向代理，上面已經說了，過程是透明的，比如說request -> Nginx -> Tomcat，那麼對於Tomcat而言，請求的IP地址就是Nginx的地址，而非真實的request地址，這一點需要注意。不過好在Nginx不僅僅可以反向代理請求，還可以由用戶自定義設置HTTP HEADER。
負載均衡---upstream
上面的反向代理中，我們通過proxy_pass來指定Tomcat的地址，很顯然我們只能指定一臺Tomcat地址，那麼我們如果想指定多臺來達到負載均衡呢？
1：通過upstream來定義一組Tomcat，並指定負載策略（IPHASH、加權論調、最少連接），健康檢查策略（Nginx可以監控這一組Tomcat的狀態）等。
2：將proxy_pass替換成upstream指定的值即可。
負載均衡需要注意的問題：選擇不同的負載均衡算法，可能會帶來不同的問題，如果選擇輪詢方式，那麼一個請求，可以到A server，也可以到B server，我們得注意用戶狀態的保存問題，如Session會話信息，不能在保存到服務器上。如果選擇散列，沒有了上面的問題，但是又得考慮，什麼樣的散列算法儘可能均勻打到後端的服務器上，總之實際應用中需要根據場景權衡選擇。
閱讀更多 Java從算法到架構 的文章
