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 security 来管理它).该网站将在多达 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?

非常感谢.

推荐答案

如果我不启用它，是否意味着我可能会因为负载均衡器将我带到另一台服务器(不是对我进行身份验证的服务器)而突然注销?

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?

是的

将 Elastic Beanstalk 与典型的 Java Web 应用程序一起使用时，我认为您肯定希望启用会话粘性.否则来自用户浏览器的每个 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)或 memcached 服务器(例如 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屋！