服务器为每个用户创建一个会话,存储用户的相关信息,以便多次请求能够定位到同一个上下文,这个相关信息就是session。这样,当用户在应用程序的Web页之间跳转时,存储在session对象中的变量将不会丢失,而是在整个用户会话中一直存在下去。
session是对http无状态协议的补充,达到状态保持的目的
假设用户包含登录信息的session都记录在第一台server上,反向代理如果将请求路由到另一台server上,可能就找不到相关信息,而导致用户需要重新登录。
由于技术不断演进,客户端保存cookie出现了信息全量cookie,cookie存储sessionId和JWT三种方式,他们优缺点各异,可以点击笔者的另一篇博客查看相关介绍
快速了解会话管理三剑客cookie、session和JWT
思路: 多个server之间相互同步session,这样每个server之间都包含全部的session
优点:
只需要设定配置,应用程序不需要修改代码 不足: session的同步需要数据传输,占内网带宽,有延时所有server都包含所有session数据,数据量受最小内存的sever限制,水平拓展能力差思路: 将session存储在server后端的集中式缓存
优点:
没有安全隐患可以水平扩展,支持缓存集群或横向拓展 不足: 增加了一次网络调用需要修改应用代码session会话粘连:英文原词为"Sticky Sessions"
思路: 反向代理层让同一个用户的请求保证落在一台server上呢?
方法一:四层代理hash。反向代理层使用用户ip来做hash,以保证同一个ip的请求落在同一个server上(更推荐,保证传输层不引入业务层的逻辑)
方法二:七层代理hash。反向代理使用http协议中的某些业务属性来做hash,例如sid,city_id,user_id等,能够更加灵活的实施hash策略,以保证同一个浏览器用户的请求落在同一个server上
优点:
只需要改nginx配置,不需要修改应用代码可以支持server水平扩展 不足: server水平扩展,rehash后session重新分布,会有一部分用户路由不到正确的session即使hash散列均匀,也不能保证server的负载均匀