AWS上无需依赖cookie的sticky sessions会话保持替代方案有哪些？

1. 配置负载均衡调度算法为源IP哈希 #

• Classic Load Balancer（CLB）原生支持源IP哈希调度策略，该策略会根据客户端的公网IP地址计算哈希值，将同一IP发起的所有请求始终路由到同一台后端EC2实例，全程不需要依赖浏览器Cookie。
• 注意事项：
  • 若大量用户通过同一NAT网关/代理服务器访问服务，会出现多用户流量集中到单台EC2的负载不均问题
  • 用户切换网络环境（如WiFi切蜂窝流量、更换办公网络）时，公网IP变更会导致请求被调度到新的EC2实例，仍可能触发报错

2. 抽离会话状态到共享存储 #

• 问题的核心根源是会话数据存储在单台EC2本地，导致跨实例请求无法读取对应会话数据触发502错误，你可以将所有会话相关数据、分析操作的中间状态统一存储到共享层：
  • 可选的共享存储方案包括自建Redis/Memcached、AWS ElastiCache托管缓存服务、或者关系型数据库的会话专用表
  • 改造完成后无论请求被调度到哪台EC2实例，都可以从共享存储读取到完整的会话数据，从根本上消除跨实例请求报错的问题，不需要依赖任何形式的会话保持策略，同时后端EC2的扩缩容、故障切换都不会影响用户使用。

3. 基于自定义标识的路由规则 #

• 若你可以将Classic Load Balancer升级为Application Load Balancer（ALB），可以实现不依赖Cookie的自定义粘性策略：
  • 前端在所有Ajax请求的请求头或者查询参数中携带用户的唯一会话标识
  • 配置ALB基于该自定义会话标识做哈希调度，同一标识的请求会被固定路由到同一台EC2实例，不需要浏览器开启Cookie支持。
• 如果不希望升级负载均衡类型，也可以在CLB和后端EC2之间新增一层反向代理集群，由反向代理层读取请求中的自定义会话标识实现哈希调度，同样可以实现不依赖Cookie的会话保持。

内容的提问来源于stack exchange，提问作者user3288051