$_SESSION
超全局变量的后端。 - Ryan Parman<?xml version='1.0' encoding='utf-8'?>
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<Manager className="com.amazonaws.services.dynamodb.sessionmanager.DynamoDBSessionManager"
createIfNotExist="true" />
</Context>
container_commands:
01-copy-aws-library:
command: "cp WEB-INF/.ebextensions/AmazonDynamoDBSessionManagerForTomcat-2.0.4.jar.jar /usr/share/tomcat8/lib/"
02-replace-tomcat-context:
command: "cp WEB-INF/.ebextensions/context.xml /etc/tomcat8/context.xml"
从个人经验来看,我建议将会话移动到数据库(RDS|DynamoDB|SimpleDB)或缓存服务器(AWS 最近开始支持 Redis)。这样做可以避免应用程序在扩展或因失败的健康检查而终止时带来很多麻烦。
为了存储会话,使用Redis在弹性缓存上是更好的选择。免费层级中有一个t1.micro节点可供使用,并由Amazon维护,因此您可以获得稳定、便宜和快速的会话存储,这些存储在自动扩展环境中的节点之间共享。如何配置PHP以在Redis中保留会话,我想您可以在互联网上找到。
使用DynamoDB的选项可能会很昂贵,因为您将为每次调用DynamoDB服务付费,此外,您需要考虑AWS通过HTTP(S)公开的服务可能会限制请求。
当使用典型的Java Web应用程序与Elastic Beanstalk时,我认为您一定会想要启用会话粘滞。否则,用户浏览器的每个HTTP请求都可能被路由到不同的服务器。
为了解决用户会话在他们所“粘附”的服务器关闭时被销毁的问题,您需要研究Tomcat会话复制。不幸的是,这不是Elastic Beanstalk默认提供的功能,因此为了设置会话复制,您需要为应用程序创建自定义的Elastic Beanstalk AMI。此外,您必须使用一个不依赖于组播的Tomcat会话复制实现,因为组播在AWS或我所知道的任何其他云环境中都不可用。一个不依赖于组播的实现示例是使用数据库(如Amazon RDS)或memcached服务器(如Amazon Elastic Cache)使会话在多个Tomcat实例之间可用。
还要注意的是,Elastic Beanstalk UI仅允许您启用负载均衡器生成的HTTP cookie。但是,在Elastic Beanstalk创建负载均衡器后,您可以进入EC2控制台并修改负载均衡器的设置,将其切换为应用程序生成的HTTP cookie,然后告诉它使用“JSESSIONID” cookie。