前言
不講虛頭八腦的東西，我們來看一下Nginx服務器能幹什麼？
- 反向代理
- 負載均衡
- 動靜分離
反向代理
注意看圖的藍色背景部分框起來的。
瞭解反向代理前先理解一下正向代理：
- 簡單的說就是多個客戶機對應一個代理服務器（在本地局域網），對應一個雲端服務器。中間的代理(Proxy)服務器負責轉發到請求轉發到公網（Intenet）。從某種意義上說,“客戶端和正向代理服務器像是位於同一個局域網（LAN）”，就是學校內網機房的那種模式。
- 這樣的好處就是通過代理服務器訪問Intenet，可以起到一個緩存作用以及防火牆的作用。緩存：將一些常使用資源放到代理服務器，客戶端便直接通過ftp傳輸文件了；防火牆：內網不允許訪問小網站，他那裏都看得到設置的訪問權限（你不給你轉到公網對應的網站）。
而反向代理：
- 簡單的說就是多對多的形式，多個客戶機，對應一個代理服務器（在雲端），對應多個服務器。
- 即訪問www.coolboy.com/a.html；和該網站的b.html，兩個文件可以放到不同的tomcat服務器進行分別請求數據。
- 其設置是在nginx設置如果請求a則轉到tomcat1上去請求，b則去tomcat2請求。
- 反向代理服務器位於用戶與目標服務器之間，但是對於用戶而言，反向代理服務器就相當於目標服務器，即用戶直接訪問反向代理服務器就可以獲得目標服務器的資源。同時，用戶不需要知道目標服務器的地址，也無須在用戶端作任何設定。反向代理服務器通常可用來作爲Web加速，即使用反向代理作爲Web服務器的前置機來降低網絡和服務器的負載，提高訪問效率。
負載均衡
在上面的反向代理中我們可以將請求分發給不同的服務器，那麼我們就能控制服務器處理的請求量，從而實現——負載均衡。
動靜分離
有兩種實現形式：
- 一種是將靜態資源單獨分離在一個服務器上，也就是掛CDN（Content Delivery Network，即內容分發網絡），內容服務基於緩存服務器，也稱作代理緩存（Surrogate）。
- 另外一種就是Nginx將動態資源放到tomcat分發請求，靜態資源放到Nginx服務器的服務器上直接給出。
負載均衡的幾種輪詢策略
- 輪詢（服務器輪着處理）【默認】
- weight（權重）：權重越高被分配的客戶請求越多
upstream backserver {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}
- ip_hash（一ip一服務器）
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端服務器，可以解決session的問題。
upstream backserver {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
- fair（誰有空就分給誰）【第三方】
按後端服務器的響應時間來分配請求，響應時間短的優先分配。
upstream backserver {
server server1;
server server2;
fair;
}
5、url_hash（一資源一服務器）【第三方】
按訪問url的hash結果來分配請求，使每個url定向到同一個後端服務器，後端服務器爲緩存時比較有效。
upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
具體配置文件
nginx配置由三塊組成：
- 全局塊：全局配置，影響nginx運行的配置，；
- events塊：主要影響nginx服務器與用戶的網絡鏈接；
- http塊（主要配置塊：代理、日誌、緩存）：也分爲：http全局快和server塊。
PS：location支持正則表達式噢！筆者用的是MarkDown編寫，因爲‘#’註釋的原因就不貼配置代碼了，網上一大堆，隨意附上一個：完整的Nginx配置代碼，或者參考文獻的視頻教學——“nginx的配置文件”，這種東西並不難。
關於分發服務帶來的一些問題（高可用）
也許聰明的你發現了，分發到不同的tomcat服務器，如果是session這種域的信息那豈不是無法共享了？
我們先來了解一下session是怎麼來的，這裏我直接引用了一篇博客的文章，人家寫的挺好的，就不累述了，參考文獻有鏈接。
- 總結一下：session通過HttpServletRequest創建後，後臺存放session信息對象並生成獨一無二的sessionid（相對於其它服務器也是獨一無二的）。用戶通過這個sessionid來獲取服務器裏面的session信息對象。
那麼Session在何時創建呢？當然還是在服務器端程序運行的過程中創建的，不同語言實現的應用程序有不同創建Session的方法，而在Java中是通過調用HttpServletRequest的getSession方法（使用true作爲參數）創建的。在創建了Session的同時，服務器會爲該Session生成唯一的Session id，而這個Session id在隨後的請求中會被用來重新獲得已經創建的Session；在Session被創建之後，就可以調用Session相關的方法往Session中增加內容了，而這些內容只會保存在服務器中，發到客戶端的只有Session id；當客戶端再次發送請求的時候，會將這個Session id帶上，服務器接受到請求之後就會依據Session id找到相應的Session，從而再次使用之。
那麼怎麼解決session共享問題呢？
1、不使用session，換用cookie；
session是存放在服務器端的，cookie是存放在客戶端的，我們可以把用戶訪問頁面產生的session放到cookie裏面，就是以cookie爲中轉站。你訪問web服務器A，產生了session然後把它放到cookie裏面，當你的請求被分配到B服務器時，服務器B先判斷服務器有沒有這個session，如果沒有，再去看看客戶端的cookie裏面有沒有這個session，如果也沒有，說明session真的不存，如果cookie裏面有，就把cookie裏面的sessoin同步到服務器B，這樣就可以實現session的同步了。
說明：這種方法實現起來簡單，方便，也不會加大數據庫的負擔，但是如果客戶端把cookie禁掉了的話，那麼session就無從同步了，這樣會給網站帶來損失；cookie的安全性不高，雖然它已經加了密，但是還是可以僞造的。
2、session存在數據庫（MySQL等）中
可以配置將session保存在數據庫中，這種方法是把存放session的表和其他數據庫表放在一起，如果mysql也做了集羣了話，每個mysql節點都要有這張表，並且這張session表的數據表要實時同步。
說明：用數據庫來同步session，會加大數據庫的IO，增加數據庫的負擔。而且數據庫讀寫速度較慢，不利於session的適時同步。
3、session存在memcache或者redis中
memcache可以做分佈式，php配置文件中設置存儲方式爲memcache，這樣php自己會建立一個session集羣，將session數據存儲在memcache中。
說明：以這種方式來同步session，不會加大數據庫的負擔，並且安全性比用cookie大大的提高，把session放到內存裏面，比從文件中讀取要快很多。但是memcache把內存分成很多種規格的存儲塊，有塊就有大小，這種方式也就決定了，memcache不能完全利用內存，會產生內存碎片，如果存儲塊不足，還會產生內存溢出。
4、nginx中的ip_hash。最簡單也是最好的方法，符合WEB開發的同源性策略。
主備模式
從上面來看，一臺tomcat掛掉後是不影響工作的（其它的tomcat服務器可能壓力變大而已），但是如果nginx掛掉了呢？因此採用主備模式，兩臺nginx來保證項目的運行，備用的nginx一般是不用的。我們採用keepalived來實現。
PS：Redis和Nginx都最好用在Linux系統上，因爲他們都在Linux系統上支持的IO的多路複用噢，windows就不支持了~
參考文獻：
session的來由
解決sesion共享問題
跨域
圖片來源以及整體知識體系：百度以及尚硅谷教學視頻