我正在使用AWS设置运行我的应用程序 - 在EC2实例上运行Elastic Load Balancer（ELB）后面的Tomcats，一个带有几个节点的memcached支持的Elasticache。我已经将我的Web应用程序配置为在Elasticache中存储会话数据，以便让Tomcat服务器对用户保持高可用性（即当Tomcat关闭时，用户没有注销，但他们的请求只是获得另一个可用的Tomcat服务）。除了我在测试过程中注意到的一个有趣案例外，它按预期工作。
当我关闭当前正在运行应用程序的Tomcat时，片刻之后，另一个Tomcat开始提供请求并且用户保持登录状态。但是，当我重新启动已停止的Tomcat时，应用程序将切换回其当前状态Tomcat在先前停止的实例上运行，这不是我所期望的 - 我认为该应用程序将继续在其新的Tomcat上运行，直到它被停止，然后它将尝试再次切换。
我已经四处寻找这种行为的解释，并且一些消息来源表明它可能是一个ELB配置问题，但没有提到哪个配置选项可能导致这个＆＃34;优先主要＆＃34;治疗。我的ELB当前配置为粘性会话，并使用AppCookieStickinessPolicy和一个cookieName为JSESSIONID。到目前为止，我所有的Tomcats都位于同一个可用区域（us-east-1b）。有任何想法吗？这种粘性行为是典型的吗？
编辑：亚马逊的文档：http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html似乎直接驳斥了我观察到的行为。
如果实例失败或变得不健康，负载均衡器会停止将请求路由到该实例，并根据现有的负载平衡算法选择新的健康实例。负载均衡器将会话视为现在＆＃34;卡住＆＃34;到新的健康实例，并继续将请求路由到该实例，即使失败的实例返回。
答案 0 :(得分：0)
我已经在我管理的生产系统上观察到这种行为多年，并不存在于亚马逊上。我认为这是tomcat用于会话复制到远程缓存的memcached-session-manager的默认行为。
当我松开tomcat节点时会发生完全相同的行为。 Tomcat进入memcached进行会话，并允许客户顺利地与另一个盒子进行交互，当原始盒子恢复时，用户返回到他们所在的盒子。
我无法告诉您它是否可配置，但我们在此处运行最低配置的设置，这似乎是MSM的默认行为。