JSF 2.0应用程序的水平扩展

Question

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

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

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

[编辑]

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

Answer 1

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

更多info

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

Answer 2

这是Jelastic PaaS的一个想法：

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

这种方式存在一定程度的失败安全性，因为如果群集中的一个实例失败，则另一个实例接管，具有相同的会话状态。另一方面，内存影响不像完全复制那样严重。

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

链接到Jelastic docs我提出了这个想法：http://jelastic.com/docs/session-replication。

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

Answer 3

使用“伙伴”语义进行会话复制怎么样？

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

好友复制还可以减少带宽开销。