如何解决集群或负载均衡引起的问题？
您好，我有一个应用程序部署在两个 weblogic 应用程序服务器上，
最近我们遇到了以下问题：在某些情况下，返回的用户会话为空。开发人员反馈说，这可能是由于会话未复制到其他服务器造成的。
我们如何证明情况确实如此？
Hi I have a application that is deploy on two weblogic app servers
recently we have issue that for certain cases the user session returned is null. Developer feedback is that it could be caused by the session not replicating to the other server.
How do we prove if this is really the case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您是否使用两个应用程序服务器都可以通过某种通信协议访问的单个会话存储？如果不是的话，那么事情肯定是这样的。想想看，如果您的 weblogic 服务器将会话存储在内存中的任何位置，并且让用户通过 cookie 传递其会话 id，那么其他服务器就无法访问另一台计算机上的内存。除非您使用粘性负载平衡。你是？
Are you using a single session store that both application servers can access via some communication protocol? If not, then it is definitely the case. Think about it, if your weblogic servers are storing the session in memory anywhere, and having users pass their session id via cookies, than the other server has no way of accessing the memory on the other machine. Unless you are using sticky load balancing. Are you?
这里需要考虑两个概念 - 会话粘性和会话复制。
会话粘性是一种机制，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，请启用调试，下次出现问题时检查代理日志中请求是否发送到其他服务器，以及该服务器是否不是辅助服务器。
There's 2 concepts to consider here - Session stickiness and session replication.
Session Stickiness is a mechanism where weblogic server ensures that if a request from a user with session A goes to server 1 then the next request from user with session A will go to server 1 only.
This is achieved by configuring a hardware loadbalancer (like F5) which is capable of providing session stickiness. or configuring weblogic proxy installed on apache/iis/weblogic.
The first time a request reached WLS managed server, it responds with a session id and appends to it the JVM id of the server (this is the primary id), if the managed server is part of a cluster, it also attaches a secondary server jvm id (the secondary server is the server where the session is being replicated)
The proxy maintains a table of all JVM id's and corresponding IP of managed server, it also checks periodically if the servers are up and running or not.
The next time when another request passes the proxy with existing session id and a primary jvm id, the proxy parses this and tries to send the request to that server, if it cannot within some time it tries to send to secondary server.
Session Replication - This is enabled by default when you configure a WLS cluster with 2 or more managed server. Each time any data is updates to a session, its data is replication in a secondary server too.
So in your case if your application users are loosing session or getting redirected to login page between normal usage, then check that the session did not get invalidated because of a timeout, if you have defined a cluster and using WLS proxy then check the proxy debug output to make sure the primary and secondary server are being appended to the session id.
Finally there's a simple example in the sample application deployment of wls that you can use to test session replication and failover functionality.
So to prove why session is getting lost,
1) check server log to see if session got invalidated because of timeout,
2) if using wlproxy, enable debug, and the next time the issue happens check in the proxy log if the request was sent to a different server, and if that server is not the secondary server.