粘滯會話：好還是壞？

我有一個Web應用程序，當一個相同的請求發送到我的兩個負載平衡服務器時，似乎有間歇競爭條件。很明顯，在這一點上既沒有完成交易，所以每個服務器上的兩個操作都是有效的。粘滯會話：好還是壞？

會議粘稠會解決這個問題？是否使用粘性會議皺起了眉頭？還有什麼可能是一些其他解決方案？

我現在在亞馬遜使用他們的負載平衡器託管。

來源

2011-11-21 Khalid Abuhakmeh

如果一個請求被髮送到負載均衡的服務器集合中，則只有一個服務器應該得到請求，通常通過循環法進行分配。如果你正在發出一個請求，並且它碰到了你的服務器，那麼別的東西是錯誤的。

否則我會假設你發出2個快速請求，並且他們碰到了你的兩個負載平衡服務器（如循環賽），你的交易在第二個請求到達服務器之前沒有完成，並且你認爲粘性會話會解決這個問題。

粘滯會話會將此會話中的所有請求發送到同一臺服務器。在你的例子中，兩個請求現在都會碰到同一個服務器，如果你什麼都沒做，第一個請求的事務就不會在第二個請求開始之前被提交，所以你會得到相同的結果，即粘性會話本身就沒有幫助。

如果交易類似於下訂單，那麼您可以製作您的代碼，以便在成功提交後，購物車的內容被刪除。完成的第一個請求會刪除購物車，第二個請求會失敗，並且您可以向用戶發出訂單已被放置的消息。

粘滯會話可能使其具有高可用性和可伸縮性變得更加複雜。對於前者，請考慮一臺服務器故障的情況 - 該服務器上的所有會話都將停機，您將不得不編寫代碼使其無法通過另一臺服務器。

對於後一種情況，假設您的會話持續一段時間，例如半小時，如果您有N位新用戶訪問該網站，他們最初將在您的兩臺服務器之間平均分配。如果在1/2小時之前，所有來自服務器1的用戶都離開並且另一個M用戶進來，那麼您將在具有原始N/2用戶加上新的M/2用戶的服務器2上承擔更多負載，而服務器1僅具有M/2個用戶，即您將浪費容量並需要編碼進行修復。

有些時候，粘性會話可能是有用的，但除非你有很好的理由來使用他們，我會避開他們

來源

2011-11-21 16:31:07

是兩個請求迅速傳送到負載均衡器，遺憾的是目前還不清楚。似乎我需要一種完全不依賴數據庫中狀態的方式，可能是內存中目標的緩存版本。 –

粘滯會話：好還是壞？

回答

相關問題