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