Amazon Web Services上的会话粘性 [英] Session stickiness on Amazon Web Services

问题描述

我对在Amazon Web Services上使用会话粘性感到困惑。当我使用Amazon Elastic Beanstalk部署Java Web应用程序时，可以选择启用会话粘性，然后指定cookie的有效期。

I'm a bit confused about the use of the session stickiness on Amazon Web Services. When I deploy my java web application using Amazon Elastic Beanstalk, I can choose to enable the session stickiness and then specify a cookie expiration period.

我的应用程序在会话中使用cookie （JSESSIONID）以及其他小物件。只有登录后才能访问大多数网站（我使用Spring安全性进行管理）。该网站最多可以在25个小型EC2实例上运行。

My application uses cookies for the session (JSESSIONID) as well as for other small things. Most of the website is accessible only after logging in (I use Spring security to manage it). The website will run on up to 25 small EC2 instances.

我应该启用会话粘性吗？如果我不启用它，是否意味着我可能因为负载均衡器将我带到另一台服务器（而不是对我进行身份验证的服务器）而突然登出？如果启用了会话粘性，那么通过身份验证的服务器关闭时是否注销？基本上，为什么和何时使用会话粘性？

Should I enable the session stickiness? If I don't enable it, does it mean that I could be suddendly logged out because the load balancer took me to another server (not the server that authenticated me)? If I enable the session stickiness, do I get logged out when the server that authenticated me gets shut down? Basically, why and when should I use session stickiness?

非常感谢。

推荐答案

如果我不启用它，是否意味着我会因为负载均衡器将我带到另一台服务器（而不是对我进行身份验证的服务器）而突然登出？ / p>

If I don't enable it, does it mean that I could be suddendly logged out because the load balancer took me to another server (not the server that authenticated me)?

是

如果我启用了会话粘性，当通过身份验证的服务器关闭时我是否注销？

If I enable the session stickiness, do I get logged out when the server that authenticated me gets shut down?

是

当在典型的Java Web应用程序中使用Elastic Beanstalk时，我认为您肯定希望启用会话粘性。否则，来自用户浏览器的每个HTTP请求都可以路由到另一台服务器。

When using Elastic Beanstalk with a typical Java webapp, I think you will definitely want to enable session stickiness. Otherwise each HTTP request from a user's browser could be routed to a different server.

要解决在服务器卡住时用户会话被破坏的问题要关闭，您需要查看 Tomcat会话复制。不幸的是，Elastic Beanstalk并不是随货提供的，因此，要设置会话复制，您必须创建一个自定义的Elastic Beanstalk AMI，以供您的应用程序使用。另外，您还必须使用不依赖多播的Tomcat会话复制实现，，因为多播在AWS或我所知道的任何其他云环境上都不可用。不依赖多播的一种实现示例是使用数据库（例如Amazon RDS）或内存缓存服务器（例如Amazon Elastic Cache）来使会话在多个Tomcat实例中可用的情况。

To get around the issue of the user's session being destroyed when the server they are "stuck" to gets shut down you would need to look into Tomcat session replication. This isn't something that Elastic Beanstalk comes with out of the box unfortunately, so in order to setup session replication you would have to create a custom Elastic Beanstalk AMI for your application to use. Also, you would have to use an implementation of Tomcat session replication that does not rely on multicast, since multicast isn't available on AWS, or any other cloud environment that I know of. An example of an implementation that doesn't rely on multicast would be one that uses a database (such as Amazon RDS) or memcached server (such as Amazon Elastic Cache) to make the sessions available across multiple Tomcat instances.

还请注意，Elastic Beanstalk UI仅允许您启用负载平衡器生成的HTTP cookie。但是，在Elastic Beanstalk创建负载平衡器之后，您可以进入EC2控制台并修改负载平衡器的设置，以将其切换到应用程序生成的HTTP cookie，然后告诉它使用 JSESSIONID cookie。

Also note that the Elastic Beanstalk UI only allows you to enable load balancer-generated HTTP cookies. However after Elastic Beanstalk has created the load balancer, you can go into the EC2 console and modify the load balancer's settings to switch it to application-generated HTTP cookies, and then tell it to use the "JSESSIONID" cookie.

这篇关于Amazon Web Services上的会话粘性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！