Cookies如何与非持久性负载平衡器一起工作

我们有一个使用sso登录用户的Drupal应用程序。

我们正在使用AWS经典负载平衡器（ELB），AWS告诉我们ELB上没有会话持久性。

我要弄清楚的是，cookie如何在经典负载均衡器上不持久地工作。

example.com DNS指向ELB。池Server1和Server2中有2台服务器

我们想要发生的是，如果用户http://example.com/user/12345/未登录就在服务器1 上打了他们的主页，如果他们已经登录，他们将被重定向到sso页面http://example.com/user/login/sso，自动登录并获取cookie SESS<hexnumber>，然后重定向回http://example.com/user/12345/

我们不允许添加任何会话服务器（redis），这是确保它们将在两个重定向中都保留在服务器1上的保证。

据我所知，每次对“ example.com”的点击都会使用户最终进入服务器1或服务器2。

我的问题：

如果他们在server1上获取cookie，然后将其重定向到server2，server2将如何知道cookie已在server1上分配给该用户？

我似乎在圈子里想自己。过去使用没有会话持久性的LB进行这种类型的设置时，我们使用Redis服务器来保存会话，每个请求都会查看redis服务器以获取会话信息。

Cookie是在浏览器而不是服务器中设置的。它被限制为一个域，并且可以选择为URL中的特定路径，因此，只要两个服务器都被同一个域访问，cookie就会在那里。

如果cookie指向会话，则server1和server2都必须以某种方式访问​​该会话。如果无法在服务器之间共享会话，则需要强制用户坚持到特定服务器。这可以通过DNS和一点点URL重写魔术轻松实现：

• www.example.com指向两个服务器。
• www1.example.com仅指向server1
• www2.example.com仅指向server2

使用一组简单的（ish）重写规则和cookie，然后可以将用户锁定到特定服务器，以确保其会话持续存在。

这里有一些更多细节。

DNS：

• example.com A 1.1.1.1，A 2.2.2.2
• www.example.com CNAME example.com
• www1.example.com A 1.1.1.1
• www2.example.com A 2.2.2.2

重写规则：

• 持续性Cookie：“后端”
• 初始连接：未定义“后端”，将“后端”设置为www1或www2，具体取决于哪个服务器已应答并重定向到该服务器。Cookie必须设置为域“ example.com”，这样，它将同时在www1和www2上加载
• 如果定义了“后端”，请确保其值与服务器实例匹配，并在必要时重定向。
• 确保会话cookie是在服务器的完整域名中定义的，即www1.example.com或www2.example.com。

重写逻辑将在Web服务器本身中定义。所有现代Web服务器都具有非常有特色的重写语言，它们完全能够实现此功能。

如果您不能使用像Elasticache Redis这样的会话管理数据库（仅用于会话的Redis每月费用不应该超过$ 15），那么下一个最佳选择是在ELB上启用粘性会话。

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

这将迫使用户在整个会话中转到相同的后端节点。寿命为900秒的“负载平衡器生成的cookie”应该足够好，但是您可以对其进行调整。