我在概念上想知道如何使用像Glassfish这样的Java EE容器在EJB级别(而不是Web会话复制)上进行负载均衡.根据我收集的信息,您的远程接口是一个代理,可将您的呼叫委派给您在环境中可能拥有的众多服务器之一.
如果事情失败,他们应该能够在另一台服务器上"完成"吗？我想了解这种负载均衡背后的基本理论,为什么它比一堆服务器都更好,它们都在负载均衡器上运行具有会话亲和性的普通Web应用程序？
我在概念上想知道如何使用像Glassfish这样的Java EE容器在EJB级别(而不是Web会话复制)上进行负载均衡.根据我收集的信息,您的远程接口是一个代理,可将您的呼叫委派给您在环境中可能拥有的众多服务器之一.
你是对的.在Glassfish中,初始查找将尝试联系jndi.properties文件中列出的服务器之一.然后,服务器知道群集中将用于循环的所有其他节点.远程引用(代理)将透明地为您执行此操作.理论上可以动态地从集群中添加/删除节点.请参阅Glassfish RMI-IIOP负载平衡和故障转移.
如果事情失败,他们应该能够在另一台服务器上"完成"吗？我想了解这种负载均衡背后的基本理论,为什么它比一堆服务器都更好,它们都在负载均衡器上运行具有会话亲和性的普通Web应用程序？
如果bean是无状态的,您甚至不需要任何亲和力,并且可以在任何节点上处理请求.每个远程引用自身充当负载均衡器.
如果豆是有状态的,那就更有毛了.集群将尝试维护bean的2个副本.并且针对这两个副本发送请求.如果其中一个节点崩溃,则群集将重新创建另一个副本,直到节点恢复为止 - 它确实类似于具有会话亲缘性的HTTP会话复制.
但与Web服务器相反,bean是事务性组件.因此,如果发生异常,则回滚事务并使有状态bean失效,因为其状态可能不再一致.
正如Pascal所指出的那样,某种故障会有某种故障转移.我的节点不可用,请求可以重新路由到另一个节点.但是如果节点在处理请求时失败,我不知道它是否可以在其他地方重新提交.
如果您想了解更多信息,建议您阅读Glassfish中的GlassFish高可用性和群集支持指南.
如果事情失败,他们应该能够在另一台服务器上"完成"吗？
据我所知,故障转移(你指的是故障转移,而不是负载平衡)不是规范的一部分.但是,大多数供应商都支持故障转移,并且可以对多个EJB容器进行群集以提供此功能.基本上,每个打开的事务的进度都会传输到备份服务器,如果主容器在事务仍处于打开状态时失败,则备份服务器可以接管,在某些情况下,它可能会继续事务(例如,WebLogic 要求将方法声明为幂等).通常,备份容器将回滚事务并通知客户端重试其原始请求.
我想了解这种负载均衡背后的基本理论,为什么它比一堆服务器都更好,它们都在负载均衡器上运行具有会话亲和性的普通Web应用程序？
太多的概念混在一起提供答案.故障转移!=负载平衡,会话亲缘关系与故障转移无关(它只是意味着请求将发送到持有会话的服务器).可以使用HTTP会话状态复制(内存中复制,数据库等)在Web层实现故障转移.你需要澄清这个问题.
京公网安备 11010802040832号 | 京ICP备19059560号-6 