JSF 2.0 应用程序的水平缩放答案

【问题标题】：Horizontal scaling of JSF 2.0 applicationJSF 2.0 应用程序的水平缩放
【发布时间】：2012-04-27 08:31:51
【问题描述】：

鉴于 JavaServer Faces 在服务器端本身就是有状态的，建议使用哪些方法来水平扩展 JSF 2.0 应用程序？

如果一个应用程序运行多个 JSF 服务器，我可以想象以下场景：

粘滞会话：将与给定会话匹配的所有请求发送到同一服务器。
- 问题：通常使用什么技术来实现这一目标？
- 问题：服务器故障会导致会话丢失...并且通常看起来像脆弱的架构，尤其是在重新开始时（不尝试扩展现有应用程序）
状态（会话）复制：在集群中的所有 JSF 服务器上复制 JSF 状态
- 问题：通常使用什么技术来实现这一目标？
- 问题： 无法扩展。集群总内存 = 最小服务器总内存
指示 JSF（通过配置）将其状态存储在外部资源上（例如，另一台运行非常快的内存数据库的服务器），然后在需要应用程序状态时从 JSF 服务器访问该资源？
- 问题：这可能吗？
指示 JSF（通过配置）是无状态的？
- 问题：这可能吗？

[编辑]

根据 Ravi 对 Sticky Sessions 的建议进行了更新

【问题讨论】：

【解决方案1】：

这可以通过将负载均衡器配置为粘性会话模式来实现。

更多info

这样你所有的后续请求都会发送到同一个应用服务器。

【讨论】：

【解决方案2】：

这是 Jelastic PaaS 的一个想法：

在 2 个服务器集群中配对应用程序实例，并在一个集群中的这 2 个实例之间应用会话复制。然后，您可以根据需要添加任意数量的 2 实例集群，并在集群之间对请求进行负载平衡，每个会话都附着在它起源的集群上。在集群内，请求可以在实例之间进行负载均衡。

这种方式有一定程度的故障安全性，因为如果集群中的一个实例发生故障，另一个实例会接管，并具有相同的会话状态。另一方面，内存影响没有完全复制那么严重。

简而言之，它是您问题中 1. 和 2. 的组合。当然，如果可用性更受关注，每个集群中可以有 2 个以上的实例。

Jelastic 文档的链接我是从 http://jelastic.com/docs/session-replication 提出这个想法的。

免责声明：我实际上不知道如何使用 JSF2 进行配置，并且与 Jelastic 没有任何关系。只是喜欢这个想法并认为它可能会有所帮助。

【讨论】：

【解决方案3】：

具有“伙伴”语义的会话复制怎么样？

对于一个好友，总内存减半（每台服务器需要保存两台服务器的会话数据），这比必须保存每台服务器的数据要好得多。

伙伴复制还可以减少带宽开销。

【讨论】：