https：//blog。csdn。net/lyj1101066558/article/details/54346110
最近迷上了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，例如例如http：//localhost：8080/login。jsp登入後儲存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 狀態；此種場景有待證實。
