分布式下的session处理方式

现在的企业级别开发下,分布式的问题是随处可见。今天我们来看看分布式情况下session的处理。
目前的处理方式有以下几种:
1、session黏性。就是说,用户在访问了某台服务器后,之后的操作就让其只走该服务器就好。那么久可以让用户只访问该台机器了。
eg:nginx配置

upstream test{
    #这里添加的是上面启动好的两台服务器
    ip_hash;#粘性Session
     server 192.168.22.229:8080 weight=1;
     server 192.168.22.230:8080 weight=1;
}

优点:操作简单,不用对session做任何操作
缺点:当一台机器挂掉后,流量切向其他的机器。会丢失部分用户的session
适用场景:发生故障对客户产生的影响较小;服务器发生故障是低概率事件。

2、使用广播的方式
当一台服务器中的session中(增删改)了之后,将这个session中的所有数据,通过广播一样的方式,同步到其他的服务器中去。
优点:容错性增高
缺点:机器不能太多,session数量不能太大,否则会造成网络阻塞,是服务器变慢。

3、使用中间件共享session
使用redis或者Memcached去当做有个中间件,session中的数据存放在其中。这里需要的是redis或者Memcached必须是集群。
两种做法:
(1)黏性:说白了就是,和第一种方式一样,一个用户的请求只走一个服务器并且在拿session数据的时候,都只在该台服务器上,但是用户的session需要保存在redis上,作为备份(容灾用)。当一台服务器挂掉了,那么就可以将该用户的session复制到其他的机器上并且把流量转发。
(1)非黏性:这种情况下,就是将用户的session存放在redis上,用户在访问的时候,读取修改都在redis上
目前这种做法是大家使用最多的方法

4、session数据存放数据库中
这种方法的优缺点大家都知道的。
优点:数据可以持久化,服务器挂掉了也没关系。
缺点:慢慢慢!!!而且用户过多的时候,性能低下。

  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值