2009-07-24 117 views

回答

4

使用狀態通常會使程序員的工作更輕鬆。

但是,各州還引入了各種併發問題,這些問題在無狀態情況下根本不存在。

這實質上是功能和命令式編程之間的爭論。

+0

我不明白什麼「併發問題」,你可以在一個Web應用程序... – 2009-12-23 02:31:01

+0

假設你有兩個用戶在您的網站上同時。如果他們都同時提交,他們是否有可能觸及您的數據庫或其他服務並導致競爭狀況? – samoz 2009-12-24 03:07:06

1

類似於長表單的東西(以及真正需要多個頁面刷新的東西)在持久狀態下更容易,因爲您可以以簡單直接的方式實際跟蹤用戶所處的頁面/階段。但是,我個人並不認爲這樣一個小優點是值得的,但它在很大程度上取決於所討論的Web應用程序。

8

我們的項目使用Wicket web框架,它允許有狀態或無狀態的交互。有狀態的頁面有許多優點:

  • 在檢票口使用狀態頁面可以更容易地使用Wicket的AJAX框架
  • 狀態是一個更加「直觀」的編程模型進行部分頁面更新。例如,在一個wicket頁面類中,我可以在服務器端聲明一個私有成員字段,在頁面加載時進行設置,並在每次AJAX請求觸發頁面執行一些更新時再次訪問它。
  • Wicket通過在處理請求時同步用戶會話對象來防止Web層中最常見的併發問題。
  • 在服務器端存儲狀態可以有時提高性能;例如,一個耗時構造但必須可用於該頁面的對象只能在頁面首次實例化時加載一次。

有狀態應用程序中的任何事情都可以作爲無狀態來實現 - 您只需將狀態存儲在客戶端,並在每個請求中提交所有相關的狀態信息。

鏈接到檢票口:http://wicket.apache.org/

1

我因可擴展性的有狀態的客戶端 - 服務器的無狀態營,但面臨着解釋的障礙時,爲什麼這和越來越難實現使用無狀態服務器,你會得到一種從長遠來看,這是有狀態服務器閃耀的地方:)。 儘管我更喜歡有狀態的客戶端,但使用asp.net viewstate不太容易實現,也許這就是statefull web變得實用的地方。 我認爲有狀態的客戶端,無狀態服務器可以讓您更清楚輪胎之間來回傳輸的數據量。這有時會隱藏起來,直到使用有狀態服務器編程模型發生故障。而且,從無狀態到有狀態很容易(只是忽略你提供的狀態信息,因爲你已經知道了。)。相反,幾乎是不可能的/不值得。使用有狀態服務器的另一件事是,當您還使用有狀態客戶端時,清除狀態/緩存通常是一個問題。這只是不直觀和令人困惑,或者只是我是:)只要我是:)

無論如何GWT和許多其他現代工具包(Silverlight與WCF交談)似乎更喜歡有狀態的客戶端,無狀態服務器由於可伸縮性問題。也許有狀態的服務器應該是無狀態規則的例外......每個頁面/窗口都可以選擇。

來源:當你開始具有較高的流量 http://groups.google.com/group/google-web-toolkit/browse_thread/thread/2871ef5076c1bdb6/43e7a5377047aa44?#43e7a5377047aa44

1

無狀態的Web應用程序是必不可少的。

例如,出於安全原因,可能有大量用戶數據不希望存儲在客戶端。在這種情況下,您需要將其存儲在服務器端。您可以使用Web應用程序的默認會話,但如果您有多個應用程序實例,則需要確保每個用戶始終定向到相同的實例。

負載平衡器通常具有「粘性會話」的能力,其中負載平衡器知道哪些服務器向用戶發送請求。但這並不理想,例如它意味着每次重新啓動Web應用程序時,所有連接的用戶都將失去會話。

更好的方法是在某些數據存儲中將會話存儲在Web服務器後面,這些日子裏有很多可用於此的優秀nosql產品(redis,mongo,elasticsearch和memcached)。通過這種方式,Web服務器是無狀態的,但您仍然有狀態服務器端,並且可以通過選擇正確的數據存儲設置來管理此狀態的可用性。這些數據存儲通常具有很高的冗餘度,所以應該幾乎總是可以對Web應用程序甚至數據存儲進行更改,而不會影響用戶。

相關問題