jakarta-ee - 从概念上讲，EJB 层上的负载平衡如何在 Glassfish/任何 ejb 容器中工作

Question

我在概念上想知道负载平衡如何在 EJB 级别(不是 Web session 复制)上使用 Glassfish 等 Java EE 容器工作。根据我收集的信息，您的远程接口(interface)是一个代理，它将您的调用委托(delegate)给您在环境中可能拥有的许多服务器之一。

如果事情失败了，他们应该能够在另一台服务器上“完成”吗？我想了解这种负载均衡背后的基本理论，为什么它比一堆服务器都在负载均衡器上运行具有 session 亲和性的普通 Web 应用程序更好？

Answer 1

I am wondering conceptually how load-balancing works on the EJB-level (not web session replication) with Java EE containers like Glassfish. From what I have gleaned your remote interface is a proxy that delegates your call to one of many servers you may have in an environment.

你说的对。在 Glassfish 中，初始查找将尝试联系 jndi.properties 中列出的服务器之一。文件。然后服务器知道集群中将用于循环的所有其他节点。远程引用(代理)将透明地为您执行此操作。理论上节点可以动态地从集群中添加/删除。见 Glassfish RMI-IIOP load balancing and fail-over .

If things fail are they supposed to be able to "finish" on another server? I want to understand the basic theory behind this load balancing, why is it better than a bunch of servers all running a plain web application with session affinity on a load-balancer?

如果 bean 是无状态的，您甚至不需要任何类型的亲和性，并且可以在任何节点上处理请求。每个远程引用都充当自己的负载平衡器。

如果 bean 是有状态的，它会更毛茸茸。集群将尝试维护 bean 的 2 个副本。并且针对这两个副本分派(dispatch)请求。如果其中一个节点崩溃，集群将重新创建另一个副本，直到节点恢复——这确实类似于具有 session 亲和性的 HTTP session 复制。

但与 Web 服务器相反，bean 是事务性组件。因此，如果发生异常，事务将回滚并且有状态 bean 失效，因为它的状态可能不再一致。

正如 Pascal 所指出的，对于某种故障存在某种故障转移。 I节点不可用，请求可以重新路由到另一个节点。但是如果在处理请求时节点失败了，我不知道它是否可以在其他地方重新提交。

如果您想了解更多，建议您阅读 Guide to GlassFish High Availability和 Cluster Support in Glassfish .