在多臺后臺服務器的環境下，我們為了確保一個客戶只和一臺服務器通信，我們勢必使用長連接。使用什么方式來實現這種連接呢，常見的有使用nginx自帶的ip_hash來做，我想這絕對不是一個好的辦法，如果前端是CDN，或者說一個局域網的客戶同時訪問服務器，導致出現服務器分配不均衡，以及不能保證每次訪問都粘滯在同一臺服務器。如果基于cookie會是一種什么情形，想想看, 每臺電腦都會有不同的cookie，在保持長連接的同時還保證了服務器的壓力均衡。

問題分析：

1. 一開始請求過來，沒有帶session信息，jvm_route就根據round robin的方法，發到一臺tomcat上面。

2. tomcat添加上session 信息，并返回給客戶。

3. 用戶再此請求，jvm_route看到session中有后端服務器的名稱，它就把請求轉到對應的服務器上。

暫時jvm_route模塊還不支持默認fair的模式。jvm_route的工作模式和fair是沖突的。對于某個特定用戶，當一直為他服務的 tomcat宕機后，默認情況下它會重試max_fails的次數，如果還是失敗，就重新啟用round robin的方式，而這種情況下就會導致用戶的session丟失。

總的說來，jvm_route是通過session_cookie這種方式來實現session粘性，將特定會話附屬到特定tomcat上,從而解決session不同步問題，但無法解決宕機后會話轉移問題。
假如沒有這個jvm_route,用戶再請求的時候，由于沒有session信息，nignx就會再次隨機的發送請求到后端的tomcat服務器，這種情況，對于普通的頁面訪問是沒有問題的。對于帶有登錄驗證信息的請求，其結果就是永遠登錄不了應用服務器。

這個模塊通過session cookie的方式來獲取session粘性。如果在cookie和url中并沒有session，則這只是個簡單的round-robin 負載均衡。

要解決以上類似的問題，從網上查了下，大致有如下幾種方式：

1）ip_hash（不推薦使用）

 nginx中的ip_hash技術能夠將某個ip的請求定向到同一臺后端，這樣一來這個ip下的某個客戶端和某個后端就能建立起穩固的session，ip_hash是在upstream配置中定義的： 

 upstream backend {    server 192.168.12.10:8080 ;    server 192.168.12.11:9090 ;    ip_hash;    } 

不推薦使用的原因如下：

  1/ nginx不是最前端的服務器。

   ip_hash要求nginx一定是最前端的服務器，否則nginx得不到正確ip，就不能根據ip作hash。譬如使用的是squid為最前端，那么nginx取ip時只能得到squid的服務器ip地址，用這個地址來作分流是肯定錯亂的。

       2/ nginx的后端還有其它方式的負載均衡。

   假如nginx后端又有其它負載均衡，將請求又通過另外的方式分流了，那么某個客戶端的請求肯定不能定位到同一臺session應用服務器上。