session - AWS Elasticache Tomcat 故障转移 - 优先选择主 Tomcat？

Question

我正在使用 AWS 设置运行我的应用程序 - 在 EC2 实例上的弹性负载平衡器 (ELB) 后面运行的 Tomcat，一个带有几个节点的 memcached-backed Elasticache。我已将我的 Web 应用程序配置为将 session 数据存储在 Elasticache 中，以保持 Tomcat 服务器对用户高度可用(即，当 Tomcat 关闭时，用户不会注销，但他们的请求仅由另一个可用服务器提供服务 Tomcat )。它按预期工作，除了我在测试期间注意到的一个有趣案例。

当我关闭当前正在运行该应用程序的 Tomcat 时，片刻之后，另一个 Tomcat 开始处理请求并且用户保持登录状态。但是，当我重新启动已停止的 Tomcat 时，该应用程序会从当前状态切换回来Tomcat 在先前停止的实例上运行，这不是我所期望的 - 我认为该应用程序将继续在其新 Tomcat 上运行，直到它停止，然后它会尝试再次切换。

我四处寻找对这种行为的解释，一些消息来源表明它可能是 ELB 配置问题，但没有提到哪个配置选项可能导致这种“优先主要”处理。我的 ELB 当前配置为粘性 session ，并使用 AppCookieStickinessPolicy 和 JSESSIONID 的 cookieName。到目前为止，我所有的 Tomcat 都位于同一个可用区 (us-east-1b)。有任何想法吗？这种粘性行为是典型的吗？

编辑:亚马逊的文档在这里:http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html似乎直接反驳了我观察到的行为。

If an instance fails or becomes unhealthy, the load balancer stops routing requests to that instance, and chooses a new healthy instance based on the existing load balancing algorithm. The load balancer treats the session as now "stuck" to the new healthy instance, and continues routing requests to that instance even if the failed instance comes back.

Answer 1

多年来，我一直在我管理的不在亚马逊上的生产系统上观察到这种行为。我认为这是 memcached-session-manager 的默认行为tomcat 用于将 session 复制到远程缓存。

当我松开一个 tomcat 节点时，会发生完全相同的行为。 Tomcat 进入 memcached 进行 session ，并允许客户与另一个盒子顺利交互，当原始盒子恢复时，用户返回到他们所在的盒子。

我无法告诉您它是否可配置，但我们在这里运行了最低限度的配置设置，这似乎是 MSM 的默认行为。