做web開(kāi)發(fā)的同學(xué)應該對session再熟悉不過(guò)，它是服務(wù)器分配給客戶(hù)端的會(huì )話(huà)標識，瀏覽器每次請求會(huì )帶上這個(gè)標識來(lái)告訴服務(wù)器我是誰(shuí)，服務(wù)器會(huì )在內存中存儲這些不同的會(huì )話(huà)信息，由此來(lái)分辨請求來(lái)自哪個(gè)會(huì )話(huà)。在單機部署的環(huán)境總，因為web服務(wù)器和session都是在同一臺機器上，所以必然能找到對應的會(huì )話(huà)數據。但如果有2臺web服務(wù)器（A和B）提供服務(wù)，假如第一次請求落到A上并創(chuàng )建了session，?，幘W(wǎng)站建設公司解讀如何保證下次落到B的請求能讀到session數據？

解決方案

有以下4中常見(jiàn)的解決方案。

1、Session Sticky

這是最簡(jiǎn)單粗暴的 方法，核心思路就是讓同一會(huì )話(huà)的請求都落地到同一臺服務(wù)器上，這樣處理起來(lái)就和單機一樣了，我們可以在負載均衡上做一些身份識別并控制轉發(fā)來(lái)達到這個(gè)目的。這樣做的優(yōu)勢是能像單機一樣簡(jiǎn)化對session處理，也方便做本地緩存，但缺點(diǎn)也是很明顯的：

如果這臺服務(wù)器宕機或重啟了，那么所以的會(huì )話(huà)數據都會(huì )丟失，失去了分布式集群帶來(lái)的高可用特性。

增加了負載均衡器的負擔，使它變得有狀態(tài)了，而且資源消耗會(huì )更大，容易成為性能瓶頸。

2、Session Replication

顧名思義，這是一種session復制的方案，核心思路就是通過(guò)在服務(wù)器之間增加session同步機制來(lái)保證數據一致。

看起來(lái)比第一種簡(jiǎn)單了很多，也沒(méi)有第一種帶來(lái)的缺陷，但在某些應用場(chǎng)景下還是會(huì )有比較嚴重的問(wèn)題：

服務(wù)器之間的數據同步帶來(lái)了額外的網(wǎng)絡(luò )消耗，隨著(zhù)機器數量和數據量的上升，網(wǎng)絡(luò )帶寬將會(huì )有很大的壓力，也必然會(huì )帶來(lái)延時(shí)問(wèn)題。

每臺服務(wù)器上都要存儲所有的會(huì )話(huà)數據，如果會(huì )話(huà)數量很大會(huì )占用服務(wù)器大部分內存空間。

目前很多應用容器都支持這種同步方式，所以在集群規模和數據量比較小的時(shí)候還是一種很好的解決方案。

3、Session集中存儲

這種方式的思路就是把所有的會(huì )話(huà)數據統一存儲和管理，所有應用服務(wù)器需要對session進(jìn)行讀寫(xiě)都要通過(guò)session服務(wù)器來(lái)操作：

這種方案的好處是獨立了session的管理，職責單一化，session服務(wù)器采用什么方式存儲（內存、數據庫、文檔、NoSql等等），什么方式對外提供服務(wù)都是透明的。不會(huì )給應用系統和負載均衡帶來(lái)額外的開(kāi)銷(xiāo)，不需要進(jìn)行數據同步就能保證一致性，看起來(lái)應該是非常完美了，不過(guò)也有自己的一些小缺陷：

對session讀寫(xiě)需要網(wǎng)絡(luò )操作，相比較session直接存儲在web服務(wù)器的時(shí)候增加了時(shí)延和不穩定性，好在session服務(wù)器和web服務(wù)器一般是部署在局域網(wǎng)中，可以最大化減少這個(gè)問(wèn)題。

session服務(wù)器出現問(wèn)題將影響所有web服務(wù)，如果采用多機部署同時(shí)也會(huì )帶來(lái)數據一致性問(wèn)題。

每種方案帶有它獨特的優(yōu)勢，同時(shí)也會(huì )帶來(lái)相應的新問(wèn)題，正所謂沒(méi)有十全十美，只有適合才是最好的?？傮w來(lái)說(shuō)，這種方案在應用服務(wù)器和會(huì )話(huà)數據量都很大的時(shí)候還是非常有優(yōu)勢的。

4、Cookie Base

這種方案是基于cookie的傳輸來(lái)實(shí)現的，核心思想很簡(jiǎn)單，就是把完整的會(huì )話(huà)數據經(jīng)過(guò)處理后寫(xiě)入到客戶(hù)端cookie，以后客戶(hù)端每次請求都帶上這個(gè)cookie，然后服務(wù)端通過(guò)解析cookie數據來(lái)獲取會(huì )話(huà)信息，如下圖所示：

這種方案簡(jiǎn)單明了，也沒(méi)有前面幾種方案帶來(lái)的問(wèn)題，但劣勢也非常明顯：

首先通過(guò)cookie來(lái)傳遞關(guān)鍵數據肯定是不安全的，即便是采用了特殊的加密手段。

如果客戶(hù)端禁用了cookie，將直接導致服務(wù)不可用。

cookie的數據是有大小限制的，如果傳遞的數據超出限制大小，將會(huì )導致數據異常。

在http請求中攜帶大量的數據進(jìn)行傳輸會(huì )增加網(wǎng)絡(luò )負擔，同樣，服務(wù)端響應大量數據會(huì )導致請求變慢，并發(fā)量大的時(shí)候會(huì )非?？膳?。

總結

以上4種方案都是可行的方案，正如前面所說(shuō)，每種方案各有優(yōu)劣，不會(huì )十全十美，實(shí)際應用中要根據需求做權衡和取舍。這些都是屬于比較通用的方案，我相信在真正的實(shí)踐和落地過(guò)程中還會(huì )有其他問(wèn)題出現，有經(jīng)驗的過(guò)來(lái)人或許會(huì )有一些另辟蹊徑的“套路”，歡迎討論交流。