我从概念上想知道负载平衡如何通过Glassfish之类的Java EE容器在EJB级别（不是Web会话复制）上工作。从我收集到的远程接口的内容来看，是一个代理，它将您的呼叫委派给您在环境中可能拥有的许多服务器之一。
如果出现故障，是否应该能够在另一台服务器上“完成”？我想了解这种负载平衡背后的基本理论，为什么它比一堆在负载平衡器上都运行具有会话亲和力的纯Web应用程序的服务器更好？
最佳答案
我从概念上想知道
负载平衡在EJB级别上工作
（不是Web会话复制）与
Java EE容器（例如Glassfish）。
从我搜集到的遥控器中
接口是委托的代理
您对许多服务器之一的呼叫
可能在环境中。
你是对的。在Glassfish中，初始查找将尝试与jndi.properties文件中列出的服务器之一联系。然后，服务器知道群集中将用于循环的所有其他节点。远程引用（代理）将透明地为您完成此操作。理论上，可以动态地从群集中添加/删除节点。请参见Glassfish RMI-IIOP load balancing and fail-over。
如果事情失败了，那应该是
能够在另一台服务器上“完成”？一世
想了解基本理论
在此负载平衡背后，为什么
比一堆服务器都好
使用以下命令运行普通的Web应用程序
负载平衡器上的会话亲和力？
如果Bean是无状态的，则您甚至不需要任何亲缘关系，并且可以在任何节点上处理请求。每个远程参考自身都充当负载平衡器。
如果Bean是全状态的，则它会更加毛茸茸。集群将尝试维护该bean的2个副本。然后针对这两个副本调度该请求。如果一个节点崩溃，群集将重新创建另一个副本，直到该节点返回为止。这确实类似于具有会话亲缘关系的HTTP会话复制。
但是与Web服务器相反，bean是事务性组件。因此，如果发生异常，则事务将回滚并使有状态Bean无效，因为其状态可能不再一致。
正如Pascal指出的那样，对于某些类型的故障，存在某种类型的故障转移。如果该节点不可用，则请求可以重新路由到另一个节点。但是，如果节点在处理请求时失败，我不知道它是否可以在其他地方重新提交。
如果您想了解更多信息，建议您阅读Guide to GlassFish High Availability和Cluster Support in Glassfish。