在**的演進過程中，當我們的單一應用伺服器無法再負擔眾多請求跟響應的時候，這時候，我們就會考慮，要不要搞個伺服器集群，這時候，我們又加了臺伺服器，為了按照一定權重分發請求跟響應，我們又加上了負載均衡裝置，本來以為，完美！但是，就像改bug那樣，修復掉乙個bug,很有可能就產生了新的 bug。
當引入了新的中間層，我們似乎解決了伺服器因為自身效能問題，無法處理更多請求跟響應。但是，這裡出現了乙個很細節的問題，以上圖為例，每次client開啟乙個會話，就會產生乙個session，代表當前客戶端跟應用伺服器的一次會話，並且生成唯一標示——sessionid。
now imagine when you are surfing with your chrome，you open a tab ,enter a url:這時候你產生乙個request物件，這個物件攜帶著你的sessionid（標識會話），沿著途中的藍線，到了左邊的伺服器上，左邊的伺服器處理完成之後，給你乙個response,之後你的client（your chrome）呈現出乙個結果給你，you say:(⊙o⊙)哦，前兩天收藏的這個mini skirt 降價啦！買買買！！！
接著你提交訂單，你的請求先到了負載均衡裝置上，接下來，它要將你的請求傳送到應用伺服器集群中的乙個伺服器上，now,問題就出現在這裡，上一次我與伺服器進行會話的時候，使用的是第乙個應用伺服器，但是由於我沒規定負載均衡裝置該怎麼分發請求，所以，如果負載均衡裝置將你的請求傳送到第二個應用伺服器上，但是我這次會話的session還在第乙個應用伺服器上，(⊙o⊙)…發現了什麼吧。。。
打了這麼多字，其實就是想說明乙個問題，你引入了負載均衡裝置，還要為負載均衡裝置配置讓我的同乙個會話，落在相同的應用伺服器上。
在沒有負載均衡裝置之前，因為我們只有一台應用伺服器，我們的每次請求都是落在同乙個伺服器上，session也是都在這個伺服器，我們的每一次會話請求都在這乙個伺服器上進行處理。
沿用這個簡單思路，如果我們在負載均衡裝置上，設定這樣的規章：讓每次請求響應均被負載均衡裝置傳送到相同的伺服器進行處理，這樣，我們的session就能得到保證了。
缺點：
1，在應用伺服器集群中，如果有一台web伺服器宕機或者重啟，那麼這台機器上的會話就會丟失，例如：如果會話中有使用者的登入狀態，那麼使用者再次發出請求，就會提示使用者重新登入。
2，會話標識是應用層的資訊，那麼負載均衡裝置要將同乙個會話請求都儲存到同乙個web伺服器上，就要進行應用層的解析，這個開銷比在傳輸層大。
3，此時，負載均衡器變成了乙個有狀態的節點，要將會話儲存到具體web伺服器的對映，和無狀態的節點相比，記憶體更大，容災更麻煩。
如果做過資料庫讀寫分離的都該知道，讀寫分離的時候，其實讀的是從庫，寫的是主庫，但是主庫的資訊會更新到從庫，不考慮讀寫時間，我們可以任務從庫和主庫的資料是一致的，這個一致性主要靠同步來實現的。
在處理session的時候，我們同樣可以採用這樣的策略，在負載均衡裝置上，無需動任何手腳，只進行無狀態分發，反正分發到哪個伺服器上，我之前的session都有，木事。
缺點：
1，同步session造成了網路頻寬的開銷，只要session資料有變化，就需要將資料同步到其他伺服器上，機器越多，同步帶來的網路開銷就越大。
2，每台web伺服器都要儲存所有的session資訊，如果整個集群的session資料很多，每台應用伺服器就會儲存非常多的session資料，嚴重占用記憶體。
既然嫌棄同步麻煩，那就把所有的session資料都拿出來，放到單獨的地方，可以是單獨資料庫，或其他分布式儲存系統，前面負載均衡器還是無狀態**，應用伺服器每次讀寫session,都到相同的地方來取。
最近做的乙個專案就是這個樣子的，負載均衡用的是nginx,每次使用者訪問，都會產生乙個sessionid，之後將session裡面的資訊序列化儲存在redis庫中，應用程式用到就通過我的redis訪問模組來訪問，會話完結之後，delete session。
缺點：
1，讀寫session資料引入了網路操作，這相對於本機的資料讀取來說，問題就在於存在延時跟不穩定性，但是考慮到應用伺服器跟session儲存裝置的通訊均發生在內容，so,take it easy!
2,如果集中進行session儲存，就要考慮到當session伺服器發生問題的時候，會影響我們整個鏈條的使用。
如果不想引入額外節點來處理session,我們可以考慮將session資料，放在cookies中，在每次請求響應的時候都帶著，每次伺服器要讀寫session,只需從cookie中拿去來生成。
缺點：
1，cookies長度限制：因為cookie可以攜帶的資料長度是有限制的，所以，這同時也在一定程度上限制住了session的長度。
2，安全性：session資料本來都是伺服器資料，而這個方案讓session的資料到了外網及客戶端上面，因此存在安全性問題，真實操作起來，需要對session進行加密處理。
3，頻寬消耗
4，效能：每次http的請求跟響應都帶有session資料，對web伺服器來說，在同樣的情況下，響應的結果輸出越少，支援的併發請求越多。
小結：還是那句話，根據具體情況自己分析吧。
Nginx MVC負載均衡實現Session共享
了解了nginx之後,也對nginx實踐了,但是nginx的理論,我只能記得一丟丟 nginx是一款高效能的反向 伺服器,類似的伺服器還有apatch,tomcat,目前我只使用過nginx,自己也實踐了一下 這是使用nginx 的 有興趣的可以了解下 cgrain的 據我了解 nginx 可實現的...
負載均衡的Hash策略引發的session丟失
三 session 保持的其他方案 四 各個方案的適用場景 結語負載均衡後新增機器後，發現資料庫的壓力迅速上公升，越來越多的使用者說剛登陸後沒多久，操作著就退出了，接著登陸，又退出了。這些問題背後都是由於乙個 session 丟失 問題導致的。相信 session 對大部分 coder 來說應該都知...
使用Nginx負載均衡
以下是關於nginx做負載均衡的介紹 nginx負載均衡的那點事 解析nginx負載均衡 配置檔案設定如下 使用者組 使用者 user nobody 工作程序，根據硬體調整 worker processes 1 錯誤日誌 error log logs error.log error log logs...