java - 负载平衡 Web 应用程序

Question

有负载均衡的 tomcat 网络服务器。每个请求都可以由不同的 tomcat 服务器提供服务。

在为基于 j2ee (struts) 的 Web 应用程序编写代码时，我们如何处理这个问题？

Answer 1

首先，您需要为 session 关联/粘性 session 设置负载均衡器，以便它继续根据 JSESSIONID 将所有请求转发到同一个 Tomcat(只要它已启动)。

The Tomcat clustering doc声明您的应用程序成功复制其 session 的两个重要要求:

• 所有 session 属性都必须实现 java.io.Serializable
• 确保您的 web.xml 具有 <distributable/>元素或设置在您的 <Context distributable="true" />

如果您开始将未实现 Serializable 的对象放入 session 中(或具有未实现 Serializable 的属性/字段)，那么您将遇到问题。

(我相信，实际上，无论您使用哪个 servlet 容器，这些要点都适用。)

更新:为了解决评论中关于为什么在多个服务器之间平衡负载时使用粘性 session 的一些问题，我认为用一个例子来解释是最简单的。

首先，只有当您的应用程序在 session 中保留某种数据时，这才真正重要，这可能不是每个应用程序(尽管可能是大多数)。如果您不在 session 中保留数据，那么您可能不会关心这些，您可以在这里停止阅读。

拥有一个将数据保存在 session 中但没有粘性 session 的环境会带来令人头疼的问题。

假设first.jsp更新特定 session 属性中的某些值，并且 second.jsp碰巧读取了这个相同的 session 属性。您可以设置 Tomcat 将 session 数据复制到集群中的所有服务器，但这种复制不会立即发生。如果初始请求为 first.jsp 怎么办？由 server1 处理完成后一纳秒，同一访问者向 second.jsp 发出请求，在您的非粘性环境中由 server2 处理.由于复制不是即时的，您是否有任何方式知道您是否正在读取最新的 session 数据？您是否必须添加某种逻辑来同步您在集群中的读取？这将成为巨大的痛苦。

设置 session 亲和性/粘性 session 消除了这个麻烦；通过让来自同一个客户端服务器的所有请求都由同一个节点发出，您不必担心“这个节点在处理请求时是最新的吗？”当节点出现故障时，客户端仍然可以故障转移到集群中的另一个节点，该节点具有其 session 数据的副本，但对于粘性 session ，这种情况很少见，而不是常态。

需要粘性 session 还有另一个原因:集群中节点之间的负载。如果 session 中的请求可以由任何节点处理，那么这意味着您在集群中设置了所有到所有的复制(意味着节点 1 的 session 数据被复制到节点 2、节点 3、...、节点N, node2 的 session 数据被复制到 node1, node3, ... none N, etc)。当集群变大时，全对所有 session 复制会变得带宽和资源密集型，因为集群中的每个添加都意味着需要与集群中的每个其他单个节点通信的另一个节点。

另一种方法是将一个节点的数据复制到集群中的几个“伙伴”，这样万一该节点发生故障，它的数据在其他地方可用，而无需每个节点都必须有一个副本。在这种情况下，您将配置集群，以便节点 1 将其数据复制到节点 2 和节点 3，节点 2 将其数据复制到节点 3 和 4，等等，从而形成一个链。在这种情况下，向集群添加额外的节点不会像在 all-to-all 方案中那样导致节点之间的通信量快速增加。