JSF 2.0 应用程序的水平缩放
Posted
技术标签:
【中文标题】JSF 2.0 应用程序的水平缩放【英文标题】:Horizontal scaling of JSF 2.0 application 【发布时间】:2012-04-27 08:31:51 【问题描述】:鉴于 JavaServer Faces 在服务器端本身就是有状态的,建议使用哪些方法来水平扩展 JSF 2.0 应用程序?
如果一个应用程序运行多个 JSF 服务器,我可以想象以下场景:
-
粘滞会话:将与给定会话匹配的所有请求发送到同一服务器。
问题:通常使用什么技术来实现这一目标?
问题:服务器故障会导致会话丢失...并且通常看起来像脆弱的架构,尤其是在重新开始时(不尝试扩展现有应用程序)
状态(会话)复制:在集群中的所有 JSF 服务器上复制 JSF 状态
问题:通常使用什么技术来实现这一目标?
问题: 无法扩展。集群总内存 = 最小服务器总内存
指示 JSF(通过配置)将其状态存储在外部资源上(例如,另一台运行非常快的内存数据库的服务器),然后在需要应用程序状态时从 JSF 服务器访问该资源?
问题:这可能吗?
指示 JSF(通过配置)是无状态的?
问题:这可能吗?
[编辑]
根据 Ravi 对 Sticky Sessions 的建议进行了更新
【问题讨论】:
【参考方案1】:这可以通过将负载均衡器配置为粘性会话模式来实现。
更多info
这样你所有的后续请求都会发送到同一个应用服务器。
【讨论】:
谢谢@Ravi,我已经相应地更新了我的问题。但是,在我看来,这更像是一种创可贴解决方案,而不是一种架构解决方案。 是的,如果一个节点发生故障,那么该节点上的所有会话都将丢失。【参考方案2】:这是 Jelastic PaaS 的一个想法:
在 2 个服务器集群中配对应用程序实例,并在一个集群中的这 2 个实例之间应用会话复制。然后,您可以根据需要添加任意数量的 2 实例集群,并在集群之间对请求进行负载平衡,每个会话都附着在它起源的集群上。在集群内,请求可以在实例之间进行负载均衡。
这种方式有一定程度的故障安全性,因为如果集群中的一个实例发生故障,另一个实例会接管,并具有相同的会话状态。另一方面,内存影响没有完全复制那么严重。
简而言之,它是您问题中 1. 和 2. 的组合。当然,如果可用性更受关注,每个集群中可以有 2 个以上的实例。
Jelastic 文档的链接我是从 http://jelastic.com/docs/session-replication 提出这个想法的。
免责声明:我实际上不知道如何使用 JSF2 进行配置,并且与 Jelastic 没有任何关系。只是喜欢这个想法并认为它可能会有所帮助。
【讨论】:
【参考方案3】:具有“伙伴”语义的会话复制怎么样?
对于一个好友,总内存减半(每台服务器需要保存两台服务器的会话数据),这比必须保存每台服务器的数据要好得多。
伙伴复制还可以减少带宽开销。
【讨论】:
以上是关于JSF 2.0 应用程序的水平缩放的主要内容,如果未能解决你的问题,请参考以下文章
从 JSF 1.2 迁移到 JSF 2.0 后,每次导航都出现 ViewExpiredException