如何解决由群集或负载平衡引起的问题？

Question

您好我有一个部署在两个weblogic应用服务器上的应用程序

最近我们发现在某些情况下返回的用户会话为空。开发人员的反馈是，它可能是因为会话没有复制到其他服务器。

我们如何证明情况确实如此？

Answer 1

您是否正在使用两个应用程序服务器都可以通过某种通信协议访问的单个会话存储？如果没有，那肯定是这样的。考虑一下，如果您的weblogic服务器将会话存储在内存中的任何位置，并且让用户通过cookie传递其会话ID，那么其他服务器无法访问其他计算机上的内存。除非您使用粘性负载平衡。你呢？

Answer 2

这里要考虑两个概念 - 会话粘性和会话复制。

会话粘性是一种机制，其中weblogic服务器确保如果来自具有会话A的用户的请求进入服务器1，则来自具有会话A的用户的下一个请求将仅到达服务器1。

这是通过配置能够提供会话粘性的硬件负载均衡器（如F5）来实现的。或配置安装在apache / iis / weblogic上的weblogic代理。

第一次请求到达WLS受管服务器时，它会以会话ID响应并向其附加服务器的JVM ID（这是主要ID），如果受管服务器是群集的一部分，它还会附加辅助服务器jvm id（辅助服务器是正在复制会话的服务器）

代理维护一个包含所有JVM ID和受管服务器的相应IP的表，它还会定期检查服务器是否已启动并运行。

下次当另一个请求通过具有现有会话ID和主jvm id的代理时，代理会解析此并尝试将请求发送到该服务器，如果它在一段时间内无法尝试发送到辅助服务器。

会话复制 - 在配置具有2个或更多受管服务器的WLS群集时，默认情况下会启用此功能。每次任何数据都是会话更新时，其数据也会在辅助服务器中复制。

因此，在您的情况下，如果您的应用程序用户正在丢失会话或在正常使用之间重定向到登录页面，那么检查会话是否因超时而无效，如果您已定义群集并使用WLS代理然后检查代理调试输出，以确保主服务器和辅助服务器被附加到会话ID。

最后，在wls的示例应用程序部署中有一个简单的示例，您可以使用它来测试会话复制和故障转移功能。

所以要证明会话迷路的原因， 1）检查服务器日志以查看会话是否因超时而失效， 2）如果使用wlproxy，启用调试，并在下次出现问题时检查代理日志中是否将请求发送到其他服务器，以及该服务器是否不是辅助服务器。