即時貼：好還是壞？

Question

當一個相同的請求發送到兩個負載平衡服務器時，我有一個Web應用程序似乎處於間歇性競爭狀態。 顯然，此時都沒有完成事務，因此每個服務器上的兩個操作均有效。

即時貼會解決此問題嗎？ 粘性會話的使用是否會被拒絕？ 還有什么其他解決方案？

我現在正在使用他們的負載平衡器托管在Amazon中。

Answer 1

如果將單個請求發送到負載均衡的服務器集，則只有一個服務器應獲得該請求，通常通過循環分配。 如果您發出單個請求，但同時又擊中了您的服務器，則可能是其他問題。

否則，我將假設您正在發出2個快速請求，並且它們同時擊中了兩個負載平衡服務器（就像輪詢），您的事務未在第二個請求到達服務器之前完成，並且您認為粘性會話可以解決此問題。

粘性會話會將該會話中的所有請求發送到同一服務器。 在您的示例中，兩個請求現在都將命中同一台服務器，並且如果您什么也不做，則在第二個請求開始之前就不會提交第一個請求的事務，因此您將得到相同的結果，即僅粘性會話將無濟於事。

如果交易就像下訂單，那么您可以編寫代碼，以便在成功提交后刪除購物車中的內容。 完成的第一個請求將刪除購物車，第二個請求將失敗，您可以向用戶發送訂單已發出的消息。

粘性會話會使擁有高可用性和可伸縮性變得更加復雜。 對於前者，請考慮一台服務器宕機的情況-該服務器上的所有會話也將宕機，並且您必須編寫代碼以將其故障轉移到另一台服務器。

對於后一種情況，假定您的會話持續一定的時間間隔，例如1/2小時，如果您有N個新用戶來到站點，則最初他們將在兩台服務器之間平均分配。 如果在1/2小時之前服務器1的所有用戶都離開並且另外M個用戶進入，那么服務器2上的負載將增加，該服務器2上具有原始N / 2個用戶和新的M / 2個用戶，而服務器1上只有M / 2個用戶，即您將浪費容量，並且需要進行代碼修復。

有時候粘性會話可能有用，但是除非您有充分的理由使用它們，否則我將避免使用它們