8.3. 启用粘性会话
典型的集群部署由负载均衡器(反向代理)和 2 个或更多红帽在专用网络上构建 Keycloak 服务器组成。出于性能的目的,如果负载均衡器将所有与特定浏览器会话相关的请求转发到同一红帽构建的 Keycloak 后端节点,这可能很有用。
原因在于,红帽构建的 Keycloak 在 covers 下使用 Infinispan 分布式缓存,以保存与当前身份验证会话和用户会话相关的数据。Infinispan 分布式缓存配置有有限所有者数。这意味着,与会话相关的数据存储在一些集群节点中,其他节点需要远程查找数据(如果它们想要访问数据)。
例如,如果带有 ID 123 的身份验证会话保存在 node1 上的 Infinispan 缓存中,然后 node2 需要通过网络向 node1 发送请求,以返回特定的会话实体。
如果特定的会话实体始终在本地可用,这非常有用,这可通过粘性会话的帮助来完成。带有公共前端负载均衡器和 Keycloak 节点的两个后端红帽构建的工作流可能类似如下:
- 用户发送初始请求以查看红帽构建的 Keycloak 登录屏幕
- 此请求由 frontend 负载均衡器提供,它将转发到一些随机节点(如 node1)。严格说,节点不需要随机设置,但可以根据其他标准(客户端 IP 地址等)进行选择。它都取决于底层负载均衡器(反向代理)的实施和配置。
- 红帽构建的 Keycloak 创建具有随机 ID (如 123)的身份验证会话,并将其保存到 Infinispan 缓存中。
- Infinispan 分布式缓存根据会话 ID 的哈希分配会话的主所有者。有关此问题的更多详细信息,请参阅 Infinispan 文档。假设 Infinispan 分配的 node2 是此会话的所有者。
- Red Hat build of Keycloak 创建 Cookie AUTH_SESSION_ID,其格式为 <session-id>.<owner-node-id>。在我们的示例中,它将是 123.node2。
- 使用红帽构建的 Keycloak 登录屏幕和浏览器中的 AUTH_SESSION_ID cookie 将响应返回给用户
从这一刻,如果负载均衡器将所有下一个请求转发到 node2,因为这是 ID 为 123 的身份验证会话的所有者,因此 Infinispan 可以在本地查找此会话。身份验证完成后,身份验证会话将转换为用户会话,该会话也会保存在 node2 上,因为它具有相同的 ID 123。
集群设置中不强制使用粘性会话,但出于上述原因,这对性能很好。您需要配置 loadbalancer 以保留 AUTH_SESSION_ID cookie。进行此更改的适当流程取决于您的负载均衡器。
如果您的代理支持在没有处理来自后端节点的 Cookie 的情况下处理会话关联性,您应该将 spi-sticky-session-encoder-infinispan-should-attach-route
选项设置为 false
,以避免将节点附加到 Cookie,并只依赖反向代理功能。
bin/kc.[sh|bat] start --spi-sticky-session-encoder-infinispan-should-attach-route=false
默认情况下,spi-sticky-session-encoder-infinispan-should-attach-route
选项值为 true
,以便节点名称附加到 Cookie 以指明后续请求应发送到的节点。