最近迷上了Nginx,真實麻雀雖小,五髒俱全..功能實在強大..
nginx不單可以作為強大的web伺服器，也可以作為一個反向代理伺服器，而且nginx還可以按照排程規則實作動态、靜态頁面的分離，可以按照輪詢、ip哈希、URL哈希、權重等多種方式對後端伺服器做負載均衡，同時還支援後端伺服器的健康檢查。
如果隻有一台伺服器時,這個伺服器挂了,那麼對于網站來說是個災難.是以，這時候的負載均衡就會大顯身手了,它會自動剔除挂掉的伺服器.
下面簡單的介紹下我使用Nginx做負載的體會
下載下傳---安裝Nginx這些不介紹了,前篇有介紹.
windows和Linux下配置Nginx負載的寫法一樣,故不分開介紹.
Nginx負載均衡一些基礎知識:
nginx 的 upstream目前支援 4 種方式的配置設定
1)、輪詢（預設）
每個請求按時間順序逐一配置設定到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。
2)、weight
指定輪詢幾率，weight和通路比率成正比，用于後端伺服器性能不均的情況。
2)、ip_hash
每個請求按通路ip的hash結果配置設定，這樣每個訪客固定通路一個後端伺服器，可以解決session的問題。
3)、fair（第三方）
按後端伺服器的響應時間來配置設定請求，響應時間短的優先配置設定。
4)、url_hash（第三方）
配置：
在http節點裡添加:
定義負載均衡裝置的 Ip及裝置狀态
upstream myServer {
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
}
在需要使用負載的Server節點下添加
proxy_pass
http://myServer;upstream 每個裝置的狀态:
down 表示單前的server暫時不參與負載
weight 預設為1.weight越大，負載的權重就越大。
max_fails ：允許請求失敗的次數預設為1.當超過最大次數時，傳回proxy_next_upstream 子產品定義的錯誤
fail_timeout:max_fails 次失敗後，暫停的時間。
backup： 其它所有的非backup機器down或者忙的時候，請求backup機器。是以這台機器壓力會最輕。
Nginx還支援多組的負載均衡,可以配置多個upstream 來服務于不同的Server.
配置負載均衡比較簡單,但是最關鍵的一個問題是怎麼實作多台伺服器之間session的共享
下面有幾種方法(以下内容來源于網絡,第四種方法沒有實踐.)
1) 不使用session，換作cookie
能把session改成cookie，就能避開session的一些弊端，在從前看的一本J2EE的書上，也指明在叢集系統中不能用session，否則惹出禍端來就不好辦。如果系統不複雜，就優先考慮能否将session去掉，改動起來非常麻煩的話，再用下面的辦法。
2) 應用伺服器自行實作共享
asp.net可以用資料庫或memcached來儲存session，進而在asp.net本身建立了一個session叢集，用這樣的方式可以令 session保證穩定，即使某個節點有故障，session也不會丢失，适用于較為嚴格但請求量不高的場合。但是它的效率是不會很高的，不适用于對效率 要求高的場合。
以上兩個辦法都跟nginx沒什麼關系，下面來說說用nginx該如何處理：
3) ip_hash
nginx中的ip_hash技術能夠将某個ip的請求定向到同一台後端，這樣一來這個ip下的某個用戶端和某個後端就能建立起穩固的session，ip_hash是在upstream配置中定義的：
upstream backend {
server 127.0.0.1:8080 ;
server 127.0.0.1:9090 ;
ip_hash;
ip_hash是容易了解的，但是因為僅僅能用ip這個因子來配置設定後端，是以ip_hash是有缺陷的，不能在一些情況下使用：
1/ nginx不是最前端的伺服器。ip_hash要求nginx一定是最前端的伺服器，否則nginx得不到正确ip，就不能根據ip作hash。譬如使用的是squid為最前端，那麼nginx取ip時隻能得到squid的伺服器ip位址，用這個位址來作分流是肯定錯亂的。
2/ nginx的後端還有其它方式的負載均衡。假如nginx後端又有其它負載均衡，将請求又通過另外的方式分流了，那麼某個用戶端的請求肯定不能定位到同一台session應用伺服器上。這麼算起來，nginx後端隻能直接指向應用伺服器，或者再搭一個squid，然後指向應用伺服器。最好的辦法是用location作一次分流，将需要session的部分請求通過ip_hash分流，剩下的走其它後端去。
4) upstream_hash
為了解決ip_hash的一些問題，可以使用upstream_hash這個第三方子產品，這個子產品多數情況下是用作url_hash的，但是并不妨礙将它用來做session共享：
假如前端是squid，他會将ip加入x_forwarded_for這個http_header裡，用upstream_hash可以用這個頭做因子，将請求定向到指定的後端：
可見這篇文檔：
http://www.sudone.com/nginx/nginx_url_hash.html在文檔中是使用$request_uri做因子，稍微改一下：
hash $http_x_forwarded_for;
這樣就改成了利用x_forwarded_for這個頭作因子，在nginx新版本中可支援讀取cookie值，是以也可以改成：
hash $cookie_jsessionid;
假如在php中配置的session為無cookie方式，配合nginx自己的一個userid_module子產品就可以用nginx自發一個cookie，可參見userid子產品的英文文檔：
http://wiki.nginx.org/NginxHttpUserIdModule 另可用姚偉斌編寫的子產品upstream_jvm_route： http://code.google.com/p/nginx-upstream-jvm-route/
===============================================
https://blog.csdn.net/chao_1990/article/details/54405759共享session應用場景，基于分布式，session的原理大緻如下(以tomcat為例)，
tomcat有一套自己的session管理機制，每次建立連接配接的時候都會通過用戶端傳過來的jsessionid從session連接配接池中獲得sessionId對應的session，如果存在，那麼直接從池中獲得session連接配接資訊，如果沒有通過程式中設定判斷是否建立一個新的session資訊儲存到池中。
nginx貢獻session的方式，大體上有ip_hash(nginx自帶)，redis共享session，基于cookie，基于db(各種關系型資料庫和非關系型資料庫)。
1、基于cookie
簡單、友善，每次通過判斷cookie中的使用者狀态資訊判斷使用者的登入狀态；但是使用者資訊要存在用戶端，存在安全隐患，除非有相當安全的加密措施，如果加密碼負載，也會 增加運算的成本。
2、基于db(各種關系型資料庫和非關系型資料庫)
登入資訊存儲到db中，雖然安全，但每次需要驗證使用者的登入狀态是都需要從db中進行IO操作，并發量高是勢必會增加資料庫的負載。
3、基于redis+cookie共享session
此種方式将将使用者的登入資訊存儲到redis中，因為是基于記憶體的讀取，是以效率不會是響應效率的瓶頸，cookie中存儲着jsessionid，不需要加密或處理，隻需要存儲redis中的key儲存統一客戶通過cookie中的key可以準确的登入資訊或是其他有效的資訊，此種方式，cookie的存儲不需要加密計算成本，其次redis将資訊存儲到緩存中，存取效率高，後面會詳細介紹此種方式實作過程。
4、基于ip_hash
此種方式配置最為簡單，但是有一定的局限性，其原理就是同一個ip的所有請求都會被nginx進行ip_hash進行計算，通過結果定位到指定的背景伺服器即一個使用者如果ip不變，那麼每次請求其實請求的都是同一背景伺服器；首先最外層的代理要保證源ip在請求 的過程不會被修改，如果你的架構裡在最外層方式不單單是nginx服務，而是類似于請求分發的服務伺服器，那麼意味着一個人的請求可能被定位到不同的伺服器上，那麼ip_hash就沒有意義了。
5、基于tomcat容器session
此種方式在根本上實作共享session，他的實際情況是通過tomcat管理配置将一個tomct下的session複制到其他的tomcat的session池中，實作真實上的session共享；此種方式需要相容tomcat配置及需要對其進行擴充，依賴性太強。
已實作的共享方式：
首先配置3個web容器，tomcat1(3301)，tomcat2(3302)、tomcat3(3303)
1、ip_hash
nginx的配置這裡不再說明，主要說明ip_hash的配置，簡直是簡單到節點
-
upstream backend {
-
ip_hash;
-
server localhost:3301 max_fails=2 fail_timeout=30s ;
-
server localhost:3302 max_fails=2 fail_timeout=30s ;
-
server localhost:3303 max_fails=2 fail_timeout=30s ;
-
}
nginx的配置檔案nginx.conf引入upstram資料,啟動即可。
驗證：
過通路web應用，例如
http://localhost:8080/login.jsp登入後存儲session資訊，每次通路這個頁面都需要驗證session的狀态，頁面實作的是tomcat1表示，此ip的請求被轉發到了tomcat1的伺服器上，無論怎麼重新整理頁面，頁面顯示的都是tomcat1，此時停掉tomcat1，再次重新整理頁面，頁面顯示的是tomcat2或是tomcat3的登入頁面，此時表示nginx負載目的已經達到，但是session沒有共享；局限性顯而易見。
2、redis+cookie共享session
原理實作：
1）、登入成功時，将還有redis的key儲存到cookie中，将登入使用者的資訊儲存到redis中；
2）、配置攔截器，攔截需要驗證登入狀态的請求，從cookie中獲得redis的key，從redis中獲得目前cookie對應的使用者資訊，對其登入狀态進行驗證。
取消nginx的ip_hash配置，登入web，例如例如
登入後存儲session資訊，首頁顯示tomcat1，此時不需要關閉任何tomcat，直接不停的重新整理首頁就會發現首頁的再tomcat1、tocmat2、tomcat3之間來回切換，表示session已正常共享。個人認為此種方式是比較推薦的。
觀點：
從功能的核心來看，其目的就是共享session，究其原因就是用戶端和服務之間需要一個唯一的值來建立關聯關系，此值就是sessionId，無論請求哪個網站通過工具檢視cookie都會有發現，有jsessionid的值，此值在于伺服器建立連接配接以後是基本不會變的(背景主動建立新的session)。及時上面的描述的共享方式5，基于session連接配接池的session管理，也是要依賴sessionid的，通過檢視tomcatsession管理的源碼，不難發現其也是通過cookie獲得的sessionid，那麼如果用戶端請強制禁用了cookie，該如何獲得jsessionId? 之前查閱過資源(未親自證明)，當浏覽器禁用cookie後，請求的位址會被重定向，重定向後會在請求的url中拼接上jsessionid，這個容器就能獲得sessionid，也就可以驗證session 狀态；此種場景有待證明。
![資料遷移方法資料遷移原則資料遷移之雙寫方案資料遷移之級聯同步方案[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)