【问题标题】:HTTP load balancing behaviorHTTP 负载平衡行为
【发布时间】:2023-04-05 23:25:01
【问题描述】:

我正在尝试了解这种设置在应用程序服务器出现故障时的系统行为:

  • 两个托管 Web 应用程序的 tomcat 服务器前面的硬件负载平衡器
  • 负载平衡器粘性已激活
  • 两个 Tomcat 配置了持久会话管理器或集群

我的理解是,如果两个 tomcat 中的一个在服务请求时崩溃,用户会收到一条 http 错误消息,当他尝试刷新页面时,平衡器会将用户重定向到正在工作的 tomcat,它将再次开始处理请求。

这是正确的吗?当处理请求的服务器出现故障时,是否有办法避免用户收到错误消息?

【问题讨论】:

    标签: tomcat architecture load-balancing


    【解决方案1】:

    行为取决于负载平衡器的配置方式、您从 tomcat 服务器收到的错误以及应用程序的行为。

    负载均衡器会定期(每隔几秒)对其监控的服务器进行健康检查;因此,单个服务器完全有可能在用户请求之间崩溃并被负载均衡器注意到。然后将该服务器从组中取出,当用户下次刷新时,他们将被定向到剩余的服务器之一,而不知道中间有任何问题。

    这取决于您的应用程序是无状态的。如果任何状态存储在单个服务器上(这通过使用粘性会话暗示),那么当用户重定向到另一台服务器时,他们可能会遇到会话超时或其他错误,并且必须重新登录并重新开始。因此,避免用户出错的第一步是使应用程序无状态或以某种方式有效地共享状态。

    还值得考虑应用程序如何失败以及负载平衡器是否会检测到它。通常,负载均衡器配置为用于第 4 层或第 7 层健康检查。

    第 4 层检查网络服务器是否正在侦听给定端口(例如端口 80)。只要它响应,服务器就会保持在组中。这对于服务器启动/关闭类型的监控很好,但您可能会遇到应用程序出错或冻结但网络服务器在端口 80 上响应并且用户仍被定向到它的情况。

    第 7 层检查网页上配置为监控的给定内容。这是更“真实世界”的监控,因为它查看的是与用户相同类型的内容,并且会因应用程序级问题而将服务器从组中取出。

    【讨论】:

    • 好的,你的回答很清楚,但我的疑问仍然存在。假设我们有一个负载均衡器在第 7 层工作,并对后端服务器设置进行适当的健康检查。后端服务器正在工作,请求被路由到后端 1。现在后端服务器开始处理请求,当它正在处理请求时,发生了一些事情,服务器崩溃了。在这种情况下,我认为用户会收到错误消息并且没有办法避免这种情况。我说的对吗?
    • 是的,如果在处理请求时发生崩溃,则该请求将出错。根据您的应用程序的配置方式,接下来发生的事情会有所不同。如果是无状态的,那么它们会刷新,它们会转到好的服务器,然后继续。如果是有状态的,那么他们的会话数据就会丢失,他们可能需要重新登录,等等。
    猜你喜欢
    • 1970-01-01
    • 2022-06-13
    • 2022-01-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-11-16
    • 2017-09-21
    • 2012-09-13
    相关资源
    最近更新 更多