負載均衡器能夠根據每次請求的會話標識來進行請求**。缺點：如果有一台web伺服器宕機或者重啟，那麼這台機器上的會話資料會丟失。如果會話中有登入狀態資料，那麼使用者就要重新登陸了
會話標識是應用層的資訊，那麼負載均衡器要將同乙個會話的請求都儲存到同乙個web伺服器上的話，就需要進行應用層(第
7層)的解析，這個開銷比第
4層的交換要大
負載均衡器變為了乙個有狀態的節點，要將會話儲存到具體web伺服器的對映。和無狀態的節點相比，記憶體消耗會更大，容災方面會更麻煩
不再要求負載均衡器來保證同乙個會話的多次請求必須到同乙個web伺服器上了。而我們的
web伺服器之間則增加了會話資料的同步。通過同步就保證了不同
web伺服器之間的
session
資料的一致。
一般的應用容器都支援 session replication的方式。與
session sticky
方案相比，
session replication
方式對負載均衡器沒有那麼多的要求，不過這個方案本身也有問題
同步session 資料造成了網路頻寬的開銷。 只要
session
資料有變化，就需要將資料同步到所有其他機器上，機器數越多，同步帶來的網路頻寬開銷就越大
每台web伺服器都要儲存所有的
session
資料，如果整個集群的
session
資料很多的話，每台機器用於儲存
session
資料的內容占用會很嚴重
機器數量少時是可以的
不同的web伺服器從同樣的地方來獲取
session,
保證了不同的
web伺服器上讀到的
session
資料都是一樣的。而儲存
session
資料的具體方式，可以使用資料庫，也可以使用其他分布式儲存系統。 這個方案解決了
session replication
方案中記憶體的問題，而對於網路頻寬，這個方案也比
session replication
要好。 該方案存在的問題是什麼呢
讀寫session 資料引入了網路操作，這相對於本機的資料讀取來說，問題就在於存在時延和不穩定性，不過我們的通訊基本都發生在內網，問題不大。
如果集中儲存session 的機器或者集群有問題，就會影響我們的應用
相對於session replication ,當
web伺服器數量比較大，
session
數比較多的時候，這個集中儲存方案的優勢是非常明顯的
將session資料放在
cookie
裡，然後在
web伺服器上從
cookie
中生成對應的
session
資料。這個方案不依賴外部的乙個儲存系統，也就不存在從外部系統獲取，寫入session資料的網路時延,
不穩定性了 不足
cookie的長度的限制
安全性。 session資料本來都是伺服器資料，而這個方案是讓這些服務端資料到了外部網路及客戶端，因此存在安全性上的問題。我們可以對寫入
cookie
的session
資料做加密，不過對於安全來說，物理上不能接觸才是安全的
頻寬消耗。
不是內部web伺服器之間的頻寬消耗，而是我們資料中心的整體外部頻寬的消耗。
效能影響，每次http請求和響應都帶有
session
資料，對
web伺服器來說，在同樣的處理請求下，
響應的結果輸出越少，支援的併發請求就會越多
web伺服器 簡單web伺服器實現
三次握手 一般情況下是瀏覽器先傳送請求資料，c s ack 應答 三次握手成功後，才開始進行通訊資料的收發。四次揮手 一般情況下是客戶端先關閉，給瀏覽器傳送關閉資訊。如果瀏覽器傳送了關閉資訊，但是伺服器沒有回過去，較慢 那麼瀏覽器一直發是不是就會有問題？所以會等待 2msl的時間。一般為2 5分鐘。...
統計多台伺服器日誌
q 當某應用部署了多台伺服器時，一次請求可能被路由到其中任意一台做處理，如何通過日誌查詢一次請求的處理結果？a 每台伺服器都去找找總能找到吧。ok,思路是對的，但是人工去操作好麻煩，寫個shell指令碼跑一下。1 建立乙個應用伺服器ip列表檔案prodiplist，如下 10.174.88.199 ...
多台伺服器session cookie之間的關係
1 同域跨子域使用一套session和cookie的辦法，ini set session.cookie domain 當前域 可以在php.ini裡修改配置 session.cookie domain 2 同域不同埠 在區域網內使用ip加埠的訪問方式搭了兩個相同程式的站，結果發現使用者在乙個站下登入...