JSF 2.0應用程序的水平縮放

Question

鑑於JavaServer Faces在服務器端本身具有狀態性，建議使用哪些方法來水平縮放JSF 2.0應用程序？

如果一個應用程序上運行多個服務器JSF，我能想象以下場景：

1. 粘性會話：發送給定會話匹配到同一服務器的所有請求。
   • 問題：常用什麼技術來實現這個目標？
   • 問題：服務器故障導致丟失的會話......和一般好像脆弱的架構，開始新的（不是要擴展現有的應用程序）
2. 國家（會話）複製尤其是當：複製JSF在羣集中的所有JSF服務器上的狀態
   • 問題：常用什麼技術來實現此目的？
   • 問題：不規模。簇的總內存=最小服務器上的內存總量
3. 指示JSF（通過配置）將其狀態存儲在外部資源（例如運行速度非常快的內存數據庫的另一臺服務器）上，然後從JSF服務器何時需要應用程序狀態？
   • 問題：這是可能的嗎？
4. 指示JSF（通過配置）是無狀態的？
   • 問題：這是可能的嗎？

[編輯]

響應更新後的粘性會話

Answer 1

這拉維的建議可以通過粘性會話模式下配置負載平衡器來實現。

更多info

這樣，你的所有後續請求被髮送到同一個應用程序服務器。

Answer 2

帶「夥伴」語義的會話複製如何？

一個夥伴的總內存減半（每個服務器需要保存兩個服務器的會話數據），這比將每臺服務器的數據保存在那裏要好得多。

好友複製還可以減少帶寬開銷。

Answer 3

下面是Jelastic的PaaS一個想法：

對-Up在2服務器集羣應用程序實例，以及一個集羣中的兩個實例之間的應用會話複製。然後，您可以根據需要添加任意數量的2實例羣集，並在羣集之間加載餘額請求，每個會話都會粘貼到源自它的羣集。在集羣內，請求可以在實例之間進行負載平衡。

這種方式有一定程度的失敗安全性，因爲如果集羣中的一個實例失敗，另一個實例將以相同的會話狀態接管。另一方面，內存的影響並不像完全複製那樣嚴重。

總之，它是你的問題中的1.和2.的組合。當然，如果可用性更受關注，每個羣集中可以有兩個以上的實例。

鏈接到Jelastic文檔我解除了這個想法：http://jelastic.com/docs/session-replication。

聲明：我實際上不知道如何使用JSF2來配置它，並且與Jelastic沒有任何關係。只是喜歡這個想法，並認爲它可能有幫助。