我试图了解这种设置在应用程序服务器出现故障时的系统行为:
- 两个托管 Web 应用程序的 Tomcat 服务器前的硬件负载平衡器
- 负载均衡器粘性激活
- 两个配置了持久会话管理器或集群的 tomcat
我的理解是,如果两个 tomcat 之一在服务请求时崩溃,用户会收到一条 http 错误消息,并且当他尝试刷新页面时,平衡器会将用户重定向到正在工作的 tomcat,它将再次开始处理请求。
这是正确的吗?当处理请求的服务器失败时,没有办法避免用户收到错误消息吗?
我试图了解这种设置在应用程序服务器出现故障时的系统行为:
我的理解是,如果两个 tomcat 之一在服务请求时崩溃,用户会收到一条 http 错误消息,并且当他尝试刷新页面时,平衡器会将用户重定向到正在工作的 tomcat,它将再次开始处理请求。
这是正确的吗?当处理请求的服务器失败时,没有办法避免用户收到错误消息吗?
行为取决于负载均衡器的配置方式、您从 tomcat 服务器获得的错误以及应用程序的行为。
负载均衡器将定期(每隔几秒)对它正在监视的服务器进行健康检查;因此,单个服务器完全有可能在用户请求之间崩溃并被负载均衡器注意到。然后将该服务器从组中取出,当用户下次刷新时,他们将被定向到剩余的服务器之一,而不知道中间有任何问题。
然而,这取决于您的应用程序是无状态的。如果任何状态存储在单个服务器上(这通过使用粘性会话暗示),那么当用户重定向到另一台服务器时,他们可能会遇到会话超时或其他错误,并且必须重新登录并重新开始。因此,避免用户出错的第一步是使应用程序无状态或以某种方式有效地共享状态。
还值得考虑应用程序如何失败以及负载平衡器是否会检测到它。通常,负载均衡器配置为用于第 4 层或第 7 层健康检查。
第 4 层检查网络服务器是否正在侦听给定端口(例如端口 80)。只要它响应,服务器就会保持在组中。这对于服务器启动/关闭类型的监控很好,但是您可能会遇到应用程序出错或冻结但网络服务器在端口 80 上响应并且用户仍被定向到它的情况。
第 7 层检查网页上配置为监控的给定内容。这是更“真实世界”的监控,因为它正在查看与用户相同的内容,并且会因应用程序级别的问题而将服务器从组中取出。