高流量Web應用程序中用戶會話的好替代方案？

什麼是在以下情況下良好的/可擴展的用戶會話的選擇：高流量Web應用程序中用戶會話的好替代方案？

用戶不必啓用了Cookie
URL爲255個字符的查詢字符串施加限制
很多GET請求（沒有隱藏表單域）
應用在多個服務器（Web場）
一些用戶進行連接代理運行（同一IP）
用戶連接通過HTTPS
50 000個併發用戶

來源

2011-02-07 This is it

如果你能保證客戶端始終連接到同一臺服務器，可以使用SSL ID作爲一個簡單的會話跟蹤機制。某些Web服務器公開此功能，並在Cookie不受支持時自動將其用於會話跟蹤。

唯一的解決辦法，將工作，不管是什麼，包括在URL中的會話ID。向URL中添加參數是實現此目的的最簡單方法，但ID可以嵌入URL中的任何位置，即作爲路徑的一部分。您將使用此ID從數據庫中獲取有關用戶的信息。

你會遇到的常見問題，當然與ID欺騙和具有會話數據庫是一個瓶頸。

來源

2011-02-07 15:26:10

也許URL Rewriting或一些URI縮短機制像http://tinyurl.com或http://goo.gl這樣你就可以通過你的會話細節以及在255個字符。
注：不建議使用這些服務，但該機制。

來源

2011-02-07 15:06:41 JSS

哼哼......我已被放下。爲什麼？ – JSS 2011-02-07 16:14:29

我沒有投票給你，我只提供一個解釋。 URL的查詢字符串部分是唯一受字符限制的部分，而不是整個URL。查詢字符串是'？'後的URL部分。 – rancidfishbreath 2011-02-07 18:07:38

首先，恕我直言，沒有很好的替代會話。問題是，當cookies被禁用時，你如何獲得它。答案是使用URL參數。所以，你必須將會話ID附加到每個請求（包括鏈接和表單）。所有其他要求並不真正相關。使你的邏輯無狀態，所以你沒有可擴展性問題：所有的請求都應該通過負載平衡器到達你的邏輯，所以你可以添加任意數量的服務器。

來源

2011-02-07 15:07:41 AlexR

首先，您的要求非常嚴格。我看到的唯一選擇是使用的方法是這樣的：http://code.google.com/p/seaside/

簡而言之：您的系統會生成statless網址像 http://host/app/@123445568978 然後你會走在DB獲取會話對象。

來源

2011-02-07 17:01:41 daitangio

50000個用戶在做什麼？持續拖放位置更新到服務器或每15分鐘點擊一次文本鏈接？在最後一種情況下：將所有內容都移動到一臺具有大量內存的服務器上。

來源

2011-02-17 21:08:37

高流量Web應用程序中用戶會話的好替代方案？

回答

相關問題