会话管理

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

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

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

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

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

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

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