什么是session一致性问题?
假设用户包含登录信息的session都记录在第一台server上,反向代理如果将请求路由到另一台server上,可能就找不到相关信息,而导致用户需要重新登录。
session一致性的几种解决方案
session同步(复制)
即多个server之间相互同步session,这样每个server之间都包含全部的session。
优点
web-server(Tomcat)原生支持,只需要修改配置文件
缺点
session同步需要数据传输,占用大量网络带宽,降低了服务器群的业务处理能力
任意一台web-server保存的数据都是所有web-server的session总和,受到内存限制无法水平扩展更多的web-server。
大型分布式集群情况下,由于所有web-server都全量保存数据,所以此方案不可取。
session数据存储在客户端cookie
优点
服务器不需存储session,用户保存自己的session信息到cookie中。节省服务端资源
缺点
都是缺点,这只是一种思路。
具体如下:
每次http请求,携带用户在cookie中的完整信息,浪费网络带宽
session数据放在cookie中,cookie有长度限制4K,不能保存大量信息
session数据放在cookie中,存在泄漏、篡改、窃取等安全隐患
这种方式不会使用。
反向代理hash一致性
原理:利用反向代理使得同一个用户的请求落在一台固定的服务器上,不要发生服务器切换即可,服务器之前内存session中的数据还是在的;可以有两种实现;
四层代理ip_hash
原理:反向代理层使用用户ip来做hash,以保证同一个ip的请求落在同一个web-server上
七层代理根据http协议任意业务字段自定义hash
原理:反向代理使用http协议中的某些业务属性来做hash,例如sid,city_id,user_id等,能够更加灵活的实施hash策略,以保证同一个浏览器用户的请求落在同一个web-server上
优缺点
优点:
只需要改nginx配置,不需要修改应用代码
负载均衡,只要hash属性的值分布是均匀的,多台web-server的负载是均衡的
可以支持web-server水平扩展(session同步法是不行的,受内存限制)
缺点
session还是存在web-server中的,所以web-server重启可能导致部分session丢失,影响业务,如部分用户需要重新登录
如果web-server水平扩展,rehash后session重新分布,也会有一部分用户路由不到正确的session
但是以上缺点问题也不是很大,因为session本来都是有有效期的。所以这两种反向代理的方式可以使用
后端统一存储session数据
原理:将session存储在web-server后端的存储层,数据库或者缓存;但是由于session是频繁读取的数据而且有过期时间,所以我们一般存在Redis缓存中,而不是MySQL等db中
优点:
没有安全隐患
可以水平扩展,数据库/缓存水平切分即可
web-server重启或者扩容都不会有session丢失
不足
增加了一次网络调用,并且需要修改应用代码;如将所有的getSession方法替换为从Redis查数据的方式
总结
保证session一致性的架构设计常见方法:
session同步法:多台web-server相互同步数据
客户端存储法:一个用户只存储自己的session数据到cookie中
反向代理hash一致性: 做,保证一个用户的请求落在一台web-server
后端统一存储:web-server重启和扩容,session也不会丢失