隨著網站的功能和用戶越來越多， 單機器服務部署的Web應用已經不能再支援了。 這時候就需要優化或調整目前的架構， 具體怎麼優化， 或先優化哪部分， 這取決於網站的具體情況， 並非總是一個套路。
如根據使用情況得知， 資料庫壓力大， 則就可以先設施讀寫分離， 分庫分表， 是垂直劃分(可以簡單的理解為按業務功能劃分)， 還是水準劃分(如使用者表資料量很多， 就可以按一定的規則分表設計,表結構仍然是相同的)。 如Web應用伺服器壓力大,可以增加一台服務部署應用， 即從單台服務變為集群。 變為集群後，
具體的問題
當一個帶有會話表示的Http請求到Web伺服器後， 需求在請求中的處理過程中找到session資料。 而問題就在於， session是保存在單機上的。 假設我們有應用A和應用B， 現在一位用戶第一次訪問網站， session資料保存在應用A中。 如果我們不做處理， 怎麼保障接下來的請求每次都請求到應用A呢? 如請求到了應用B中， 就會發現沒有這位元使用者的session資料， 這絕對是不能容忍的。
解決方案
解決方案有Session Stick， Session複製， Session集中管理， 基於Cookie管理， 下面一一說明。
Session Stick
在單機情況， session保存在單機上， 請求也是到這台單機上，
如果某一台伺服器宕機或重啟， 那麼這台伺服器上的session資料就丟失了。 如果session資料中還有登錄狀態資訊， 那麼使用者需要重現登錄。
負載均衡要處理具體的session到伺服器的映射。
Session複製
Session複製顧名思義， 就是每台應用服務， 都保存會話session資料， 一般的應用容器都支援。 與Session Stick相比， sessioon複製對負載均衡 沒有太多的要求。 不過這個方案還是有缺點：
同步session資料帶來都網路開銷。 只要session資料變化， 就需要同步到所有機器上， 機器越多， 網路開銷越大。
由於每台伺服器都保存session資料， 如果集群的session資料很多，
這就是Session複製， 這個方案是靠應用容器來完成， 並不依賴應用， 如果應用服務數量並不是很多， 可以考慮。
Session集中管理
這個也很好理解， 再加一台服務， 專門來管理session資料， 每台應用服務都從專門的session管理服務中取會話session資料。 可以使用資料庫， NOSQL資料庫等。 和Session複製相比， 減少了每台應用服務的記憶體使用， 同步session帶來的網路開銷問題。 但還是有缺點：
讀寫session引入了網路操作， 相對於本機讀寫session， 帶來了延時和不穩定性。
如Session集中服務有問題， 會影響應用。
基於Cookie管理
最後一個是基於Cookie管理， 我們把session資料存放在cookie中， 然後請求過來後， 從cookie中獲取session資料。 與集中管理相比， 這個方案並不依賴外部 的存儲系統，
Cookie有長度限制， 這會影響session資料的長度。
安全性。 session資料本來存儲在服務端的， 而這個方案是讓session資料轉到外部網路或用戶端中， 所以會有安全性問題。 不過可以對寫入Cookie的session 資料做加密。
頻寬消耗。 由於加了session資料， 頻寬當然也會增加一點。
性能消耗。 每次Http請求和回應都帶有Session資料， 對於Web伺服器來說， 在同樣的處理情況下， 回應的結果輸出越少， 支持的併發請求越多。
總結
這4種方案都是可用的方案， 我比較傾向于使用Session集中管理， 不過這4種方案都各有優劣， 需要根據具體的實際場景做出合適的選擇。
1、具有1-5工作經驗的， 面對目前流行的技術不知從何下手，
2、在公司待久了， 過得很安逸， 但跳槽時面試碰壁。 需要在短時間內進修、跳槽拿高薪的可以加群。
3、如果沒有工作經驗， 但基礎非常扎實， 對java工作機制， 常用設計思想， 常用java開發框架掌握熟練的， 可以加群。
4、覺得自己很牛B， 一般需求都能搞定。 但是所學的知識點沒有系統化， 很難在技術領域繼續突破的可以加群。
5. 群號：高級架構群 283943715 備註好資訊！
6.阿裡Java高級大牛直播講解知識點， 分享知識， 多年工作經驗的梳理和總結， 帶著大家全面、科學地建立自己的技術體系和技術認知！