有很多方法可管理用户会话,包括将这些会话本地存储到对 HTTP 请求作出响应的节点,或在架构中指定一个能够以可扩展和可靠的方式存储这些会话的层。常见使用方法包括使用粘性会话或使用分布式缓存进行会话管理。下面介绍这些方法。

粘性会话(也称为会话关联)可以将站点用户路由到管理该用户会话的特定 Web 服务器。会话的有效性可以通过多种方法确定,包括客户端 Cookie 或通过可配置持续时间参数(可在将请求路由到 Web 服务器的负载均衡器上设置)确定。

使用粘性会话的部分优势在于,因为会话存储在运行应用程序的 Web 服务器上,所以具备成本效益,并且,由于消除了网络延迟,这些会话的检索速度通常很快。在单独的节点上使用存储会话的缺点是,在发生故障时,可能会丢失驻留在故障节点上的会话。此外,当 Web 服务器的数量发生变化时,例如服务器扩展时,由于活动会话存在于特定服务器上,流量可能会在 Web 服务器上不均匀地分布。如果无法恰当地缓解这一问题,会影响应用程序的可扩展性。 

为了处理可扩展性问题和为会话提供可从任何一个 Web 服务器访问的共享数据存储,可以从 Web 服务器本身使 HTTP 会话抽象化。对此,一个常见解决方案是利用内存中键值存储,如 RedisMemcached

虽然众所周知,键值数据存储极为快速,延迟为次毫秒级,但是增加的网络延迟和成本却是其缺点。利用键值存储的另一个优点是,它们还可以用来缓存任何数据,而不只是 HTTP 会话,这样有助于提高应用程序的整体性能。

为会话管理选择分布式缓存时,应确定需要多少节点来管理用户会话。一般来说,可以通过预计流量和/或可接受多大风险来做决定。在分布式会话缓存中,会话按缓存集群中的节点数量来分配。在发生故障时,只有存储在故障节点上的会话才会受影响。如果降低风险比降低成本更重要,即使较少的节点也够用,添加更多节点可以进一步降低每个节点存储的会话的百分比,这样可能更理想。

另一个注意事项是,是否需要复制会话。部分键值存储通过只读副本提供复制。在节点发生故障时,会话不会完全丢失。复制节点在单个架构中是否重要决定了应使用哪个键值存储。用于内存中键值存储的 ElastiCache 服务包括支持复制的 ElastiCache for Redis 和不支持复制的 ElastiCache for Memcached

在键值存储中存储会话有多种方式。很多应用程序框架提供了可使在内存中 GET/SET 这些会话所需的一些集成管道抽象化的库。在其他情况下,您可编写自己的会话处理程序来直接持久存储会话。 


使用 Amazon ElastiCache 等完全托管的服务,很容易便能开始在云中进行缓存。它消除了设置、管理和实施缓存的复杂性,使您能够专注于能为组织创造价值的任务。立即注册 Amazon ElastiCache