打开APP
userphoto
未登录

开通VIP,畅享免费电子书等14项超值服

开通VIP
互联网分布式系统Session一致性问题解析

  1. 什么是Session?

  用户使用网站的服务,需要使用浏览器与Web服务器进行多次交互。HTTP协议本身是无状态的,需要基于HTTP协议支持会话状态(Session State)的机制。具体的实现方式是:在会话开始时,分配一个

  唯一的会话标识(SessionID),并通过Cookie将这个标识告诉浏览器,以后每次请求的时候,浏览器都会带上这个会话标识SessionID来告诉Web服务器这个请求是属于哪个会话的。在Web服务器上,各个会话都有独立的存储,保存不同会话的信息。如果遇到禁用Cookie的情况,一般的做法就是把这个会话标识放到URL的参数中。

  2. 什么是Session一致性问题?

  当Web服务器从一台变为多台时,就会出现Session一致性问题。

  如上图所示,当一个带有会话标识的HTTP请求到了Web服务器后,需要在HTTP请求的处理过程中找到对应的会话数据(Session)。但是,现在存在的问题就是:如果我第一次访问网站时请求落到了左边的服务器,那么我的Session就创建在左边的服务器上了,如果我们不做处理,就不能保证接下来的请求每次都落在同一边的服务器上了。这就是Session一致性问题。

  二、Session一致性解决方案

  1. Session Stiky

  在单机的情况下,会话保存在单机上,请求也是由这个机器处理,因此不会有问题。当Web服务器变为多台以后,如果保证同一个会话的请求都在同一个Web服务器上处理,则对该会话来说,与之前单机的情况是一样的。

  如果要做到这样,就需要负载均衡器能够根据每次请求的会话标识SessionID来进行请求转发,如下图所示。这种方式称之为Session Stiky方式。

  该方案本身非常简单,对于Web服务器来说,该方案和单机的情况是一样的,只是我们在负载均衡器上做了手脚。这个方案可以让同样Session的请求每次都发送到同一个Web服务器来处理,非常利于针对Session进行服务端本地的缓存。

  其所存在的问题包括:

  如果有一台Web服务器宕机或者重启,则该机器上的会话数据就会丢失。如果会话中有登录状态数据,则用户需要重新登陆。

  会话标识是应用层的信息,则负载均衡器要将同一个会话的请求都保存到同一个Web服务器上的话,就需要进行应用层(七层)的解析,这个开销比第四层的交换要大。

  负载均衡器变为了一个有状态的节点,要将会话保存到具体Web服务器的映射,因此内存消耗会更大,容灾会更麻烦。

  打个比方来说,对于Session Stiky,如果说Web服务器是我们每次吃饭的饭店,会话数据就是我们吃饭用的碗筷。要保证每次吃饭都用自己的碗筷,我就把餐具存在某一家,并且每次都去这家店吃,这是个不错的主意。

  Session Replication

  如果我们继续以去饭店吃饭类比,那么除了前面的方式之外,如果我在每个店都存放一套自己的餐具,就可以更加自由地选择饭店。Session Replication就是这样一种方式,如下图所示。

  

  可以看到,在Session Replication方案中,不再要求负载均衡器来保证同一个会话地多次请求必须到同一个Web服务器上了。而我们的Web服务器之间则增加了会话数据的同步。通过同步就保证了不同Web服务器之间的Session数据的一致。

  但是,Session Replication方案也存在一些问题,包括:

  同步Session数据造成了网络带宽的开销。只要Session数据有变化,就需要将数据同步到其他所有机器上,机器数越多,同步带来的网络带宽开销就越大。

  每台Web服务器都要保存所有的Session数据,如果整个集群的Session数很多的话,每台机器用于保存Session数据的内容占用会很严重。

  这就是Session Replication方案。这个方案是靠应用容器来完成Session的复制从而使得应用解决Session问题的,应用本身并不关心这个事情。不过,这个方案并不适合集群机器数多的场景。如果只有几台机器,用该方案是可以的。

  session数据集中存储

  思路:将session存储在web-server后端的存储层,数据库或者缓存

  优点:

  没有安全隐患

  可以水平扩展,数据库/缓存水平切分即可

  web-server重启或者扩容都不会有session丢失

  不足:增加了一次网络调用,并且需要修改应用代码

  对于db存储还是cache,个人推荐后者:session读取的频率会很高,数据库压力会比较大。如果有session高可用需求,cache可以做高可用,但大部分情况下session可以丢失,一般也不需要考虑高可用。

  总结

  保证session一致性的架构设计常见方法:

  session同步法:多台web-server相互同步数据

  客户端存储法:一个用户只存储自己的数据

  反向代理hash一致性:四层hash和七层hash都可以做,保证一个用户的请求落在一台web-server上

  后端统一存储:web-server重启和扩容,session也不会丢失

本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请点击举报
打开APP,阅读全文并永久保存 查看更多类似文章
猜你喜欢
类似文章
【热】打开小程序,算一算2024你的财运
2.2.4.2 解决应用服务器变为集群后的Session问题
揭开J2EE集群的神秘面纱(二)
SAP Spartacus 和 Sticky session 相关的话题
web之保持会话(Session)
Windows平台分布式架构实践
有关一致性哈希算法的应用场景
更多类似文章 >>
生活服务
热点新闻
分享 收藏 导长图 关注 下载文章
绑定账号成功
后续可登录账号畅享VIP特权!
如果VIP功能使用有故障,
可点击这里联系客服!

联系客服