|
|
1
18
这一切都是通过外部Web服务器完成的,它可以监听世界(我推荐nginx或lighttpd)。 关于速率限制,nginx能够限制,即每个IP每分钟50个请求,总共获得503个页面,您可以自定义。 关于预期的临时停机,在rails世界中,这是通过特殊的maintainance.html页面完成的。当rails应用程序服务器发生故障时,会有某种自动化来创建文件或符号链接。我建议不要依赖文件存在,而是依赖应用服务器的实际可用性。 但实际上,您可以在不丢失任何连接的情况下启动/停止服务。也就是说,您可以在不同的UNIX套接字/IP端口上运行应用服务器的单独实例,并让平衡器(nginx/lighty/haproxy)也使用该新实例。然后关闭旧实例,所有客户端只使用新实例。没有连接丢失。当然,这种情况并不总是可能的,这取决于您在新版本中引入的更改类型。 haproxy是一个仅限平衡器的解决方案。它可以非常有效地平衡对服务器场中应用服务器的请求。 对于相当大的服务,你最终会得到这样的结果:
|
|
|
2
5
|
|
|
3
2
我建议在应用程序之外实施速率限制,否则高流量仍然会杀死你的应用程序。一个好的解决方案是将其作为apache代理的一部分来实现,类似于 mod_evasive |