原來寫過一篇，為了加深理解，再寫一篇
session分為
session replication 策略是複製會話，即乙個使用者訪問了一次就把session複製到所有的伺服器或這一部分伺服器。
這樣的好處是如果正訪問的伺服器down了使用者可以自動被轉到別的伺服器session不丟失。缺點當然是效率低。
session sticky策略則是不複製，乙個使用者訪問了一次後，同乙個session週期內，所有的請求都定向到這個伺服器，down了session就丟了。
問題解決
1)ip_hash
upstream backend
1/ nginx不是最前端的伺服器。
ip_hash要求nginx一定是最前端的伺服器，否則nginx得不到正確ip，就不能根據ip作hash。譬如使用的是squid為最前端，那麼nginx取ip時只能得到squid的伺服器ip位址，用這個位址來作分流是肯定錯亂的。
2/ nginx的後端還有其它方式的負載均衡。
假如nginx後端又有其它負載均衡，將請求又通過另外的方式分流了，那麼某個客戶端的請求肯定不能定位到同一臺session應用伺服器上。
3/ 多個外網出口。
很多公司上網有多個出口，多個ip位址，使用者訪問網際網路時候自動切換ip。而且這種情況不在少數。使用 ip_hash 的話對這種情況的使用者無效，無法將某個使用者繫結在固定的tomcat上 。
使用：2)nginx_upstream_jvm_route(nginx擴充套件，推薦使用)
nginx_upstream_jvm_route 是乙個nginx的擴充套件模組，用來實現基於 cookie 的 session sticky 的功能。
簡單來說，它是基於cookie中的jsessionid來決定將請求傳送給後端的哪個server，nginx_upstream_jvm_route會在使用者第一次請求後端server時，將響應的server標識繫結到cookie中的jsessionid中，從而當使用者發起下一次請求時，nginx會根據jsessionid來決定由哪個後端server來處理。
1/ nginx_upstream_jvm_route安裝
(1)進入nginx原始碼路徑
修改tomcat配置server.xml
將修改為：
具體配置參考
[url]
[/url]
session 集群方案
背景 假設某個 是由多台伺服器提供服務，nginx採用輪詢機制做負載均衡，那麼同乙個ip訪問該 時，請求就可能會被分配到不同的伺服器上，如果session沒有實現共享，就會出現重複登陸授權的情況。session 集群主要有兩個方案 session 複製和session共享 session 複製 是指...
nginx tomcat集群session共享
1.常見的 tomcat 集群解決方案 1 採用 nginx 中的 ip hash policy 來保持某個 ip 始終連線在某個機器上 優點 可以不改變現有的技術架構，直接實現橫向擴充套件，省事。但是缺點也很明顯，實際生產中，極少使用這種方式 缺點 a 單個伺服器請求 負載 不均衡，這是完全依賴 ...
tomcat集群session共享
才疏學淺且語無倫次，如有誤人子弟，深表歉意 一台tomcat不夠用時，要麼換更好的機器，要麼加機器做集群。做集群就會涉及到負載均衡，比如nginx，會把到來的每個請求按一定的規則 給後端tomcat，這就有乙個逃避不了的問題需要解決，使用者的session需要在不同的tomcat之間共享。比較偷懶的...