简体繁体 English

HTTP负载平衡行为

[英]HTTP load balancing behavior

原文 2013-08-01 11:48:51 7 1 tomcat/ architecture/ load-balancing

I am trying to understand the system behavior of such a setup in case of application server failure: 我试图了解在应用程序服务器出现故障时这种设置的系统行为：

hardware load balancer in front of two tomcat servers that host a web application 托管Web应用程序的两个tomcat服务器之前的硬件负载平衡器
load balancer stickyness active 负载均衡器粘性激活
two tomcats configured either with persistent session manager or in cluster 两个使用持久性会话管理器或群集配置的雄猫

My understanding is that if one of the two tomcats crashes when serving a request, the user gets an http error message and when he tries refresh the page the balancer redirects the user to the working tomcat which will start processing the request again. 我的理解是，如果在处理请求时两个tomcat之一崩溃，则用户会收到一条http错误消息，并且当他尝试刷新页面时，平衡器会将用户重定向到正在工作的tomcat，后者将再次开始处理请求。

Is this correct and there is no way to avoid that users get error messages when the server that is processing a requests fails? 这是否正确，并且在处理请求的服务器出现故障时，无法避免用户收到错误消息吗？

1 个解决方案

The behaviour depends on how the load-balancer is configured, the error that you're getting from the tomcat server and the behaviour of your application. 行为取决于负载均衡器的配置方式，从tomcat服务器收到的错误以及应用程序的行为。

A load-balancer will health-check the servers it is monitoring periodically (every few seconds); 负载均衡器将定期（每隔几秒钟）对正在监视的服务器进行健康检查； so it is entirely possible for a single server to crash between user requests and get noticed by the load-balancer. 因此，单个服务器完全有可能在用户请求之间崩溃并被负载均衡器注意到。 That server is then taken out of the group and when the user next refreshes they are directed to one of the remaining servers with no idea that anything has gone wrong in the middle. 然后将该服务器从组中删除，当用户下一次刷新时，将它们定向到其余服务器之一，而不知道中间有什么问题。

This depends on your application being stateless however. 但是，这取决于您的应用程序是无状态的。 If any state is being stored on the single server (which is implied by use of sticky sessions), then when the user redirects to another server they may get a session timeout or other error and have to relogin and start again. 如果任何状态都存储在单个服务器上（使用粘性会话暗示），则当用户重定向到另一台服务器时，他们可能会遇到会话超时或其他错误，必须重新登录并重新开始。 So step 1 to avoiding users getting errors is to make the application stateless or share state effectively in some manner. 因此，避免用户出错的步骤1是使应用程序变为无状态或以某种方式有效地共享状态。

It's also worth considering how the application fails and if the load-balancer will detect it. 还值得考虑应用程序如何失败以及负载均衡器是否会检测到它。 Typically load-balancers are configured for either layer 4 or layer 7 healthchecking. 通常，将负载均衡器配置为用于第4层或第7层健康检查。

Layer 4 checks that the webserver is listening on a given port (eg port 80). 第4层检查Web服务器是否正在侦听给定端口（例如，端口80）。 As long as that it responding the server is kept in group. 只要它响应，服务器就被分组。 This is fine for server up / down type monitoring but you can have situations where your application is errored or frozen but the webserver is responding on port 80 and users are still being directed to it. 这对于服务器启动/关闭类型监视很好，但是您可能会遇到以下情况：您的应用程序出错或被冻结，但Web服务器在端口80上响应，并且用户仍在定向到该端口。

Layer 7 checks a given piece of content on a webpage that it is configured to monitor. 第7层在配置为监视的网页上检查给定的内容。 This is much more 'real world' monitoring as it is looking at the same kind of content that a user is, and will take the server out of group for an application level problem. 这是一种“现实世界”的监视，因为它正在查看与用户相同的内容，并将服务器从应用程序级别的问题中脱颖而出。