做web開發(fā)的同學應該對session再熟悉不過，它是服務器分配給客戶端的會話標識，瀏覽器每次請求會帶上這個標識來告訴服務器我是誰，服務器會在內(nèi)存中存儲這些不同的會話信息，由此來分辨請求來自哪個會話。
做web開發(fā)的同學應該對session再熟悉不過，它是服務器分配給客戶端的會話標識，瀏覽器每次請求會帶上這個標識來告訴服務器我是誰，服務器會在內(nèi)存中存儲這些不同的會話信息，由此來分辨請求來自哪個會話。在單機部署的環(huán)境總，因為web服務器和session都是在同一臺機器上，所以必然能找到對應的會話數(shù)據(jù)。但如果有2臺web服務器(A和B)提供服務，假如第一次請求落到A上并創(chuàng)建了session，那么如何保證下次落到B的請求能讀到session數(shù)據(jù)?
有以下4中常見的解決方案。
1、Session Sticky
這是最簡單粗暴的 方法，核心思路就是讓同一會話的請求都落地到同一臺服務器上，這樣處理起來就和單機一樣了，我們可以在
負載均衡上做一些身份識別并控制轉(zhuǎn)發(fā)來達到這個目的。這樣做的優(yōu)勢是能像單機一樣簡化對session處理，也方便做本地緩存，但缺點也是很明顯的：
如果這臺服務器宕機或重啟了，那么所以的會話數(shù)據(jù)都會丟失，失去了分布式集群帶來的高可用特性。
增加了負載均衡器的負擔，使它變得有狀態(tài)了，而且資源消耗會更大，容易成為性能瓶頸。
2、Session Replication
顧名思義，這是一種session復制的方案，核心思路就是通過在服務器之間增加session同步機制來保證數(shù)據(jù)一致。
看起來比第一種簡單了很多，也沒有第一種帶來的缺陷，但在某些應用場景下還是會有比較嚴重的問題：
服務器之間的數(shù)據(jù)同步帶來了額外的網(wǎng)絡消耗，隨著機器數(shù)量和數(shù)據(jù)量的上升，網(wǎng)絡帶寬將會有很大的壓力，也必然會帶來延時問題。
每臺服務器上都要存儲所有的會話數(shù)據(jù)，如果會話數(shù)量很大會占用服務器大部分內(nèi)存
空間。
目前很多應用
容器都支持這種同步方式，所以在集群規(guī)模和數(shù)據(jù)量比較小的時候還是一種很好的解決方案。
3、Session集中存儲
這種方式的思路就是把所有的會話數(shù)據(jù)統(tǒng)一存儲和管理，所有應用服務器需要對session進行讀寫都要通過session服務器來操作：
這種方案的好處是獨立了session的管理，職責單一化，session服務器采用什么方式存儲(內(nèi)存、數(shù)據(jù)庫、文檔、NoSql等等)，什么方式對外提供服務都是透明的。不會給應用系統(tǒng)和負載均衡帶來額外的開銷，不需要進行數(shù)據(jù)同步就能保證一致性，看起來應該是非常完美了，不過也有自己的一些小缺陷：
對session讀寫需要網(wǎng)絡操作，相比較session直接存儲在web服務器的時候增加了時延和不穩(wěn)定性，好在session服務器和web服務器一般是部署在局域網(wǎng)中，可以最大化減少這個問題。
session服務器出現(xiàn)問題將影響所有web服務，如果采用多機部署同時也會帶來數(shù)據(jù)一致性問題。
每種方案帶有它獨特的優(yōu)勢，同時也會帶來相應的新問題，正所謂沒有十全十美，只有適合才是最好的?？傮w來說，這種方案在應用服務器和會話數(shù)據(jù)量都很大的時候還是非常有優(yōu)勢的。
4、Cookie Base
這種方案是基于cookie的傳輸來實現(xiàn)的，核心思想很簡單，就是把完整的會話數(shù)據(jù)經(jīng)過處理后寫入到客戶端cookie，以后客戶端每次請求都帶上這個cookie，然后服務端通過解析cookie數(shù)據(jù)來獲取會話信息。
這種方案簡單明了，也沒有前面幾種方案帶來的問題，但劣勢也非常明顯：
首先通過cookie來傳遞關鍵數(shù)據(jù)肯定是不安全的，即便是采用了特殊的加密手段。
如果客戶端禁用了cookie，將直接導致服務不可用。
cookie的數(shù)據(jù)是有大小限制的，如果傳遞的數(shù)據(jù)超出限制大小，將會導致數(shù)據(jù)異常。
在http請求中攜帶大量的數(shù)據(jù)進行傳輸會增加網(wǎng)絡負擔，同樣，服務端響應大量數(shù)據(jù)會導致請求變慢，并發(fā)量大的時候會非?？膳隆?/div>
商品已成功加入購物車