但是如果此时用户请求的一个服务模块可能需要调用到服务器B,当用户发起请求的时候,此时的服务器B上并没有存储该用户的sessionID,所以就会再次让用户进行一个登陆 *** 作。
还有可能会导致用户本来就想完成一个下单 *** 作,但是却还登陆了好几次的情况。
所以session共享方案在分布式环境和微服务系统下,显得尤其重要。
解决方案一:基于Nginx的ip_hash 负载均衡其实就是对请求过来的ip地址对你的多少台可用的服务器进行取模,然后就会把你的请求通过Nginx的反向代理给分发到对应的服务器上。
(这里会把可用的服务器放到一个数组中,如果取模得到的结果是几,就把请求分到服务器数组中的下标为几的服务器上)具体实现:需要你在Nginx.conf文件中进行对应的修改,根据自己的可用服务器upstream backend{ ip_hash; server 192.168.128.1:8080 ; server 192.168.128.2:8080 ; server 192.168.128.3:8080 down; server 192.168.128.4:8080 down; }server { listen 8081; server_name test.csdn.net; root /home/system/test.csdn.net/test; location ^~ /Upload/upload { proxy_pass http://backend; } }这种实现的优缺点:解决方案二:基于Tomcat的session复制这个解决方案其实就是当用户请求的时候,把产生的sessionID给复制到系统所有的服务器中,这样就能保证当用户请求的时候从服务器A可能调用到服务器B上的模块的时候,也能保证服务B也有该用户的sessionID,这样就不会再次让用户进行再次登录 *** 作了。
也就解决问题了。
具体代码中如何实现session复制呢?使用session复制的优缺点:解决方案三:使用Redis做缓存session的统一缓存这种方案呢,其实就是把每次用户的请求的时候生成的sessionID给放到Redis的服务器上。
然后再基于Redis的特性进行设置一个失效时间的机制,这样就能保证用户在我们设置的Redis中的session失效时间内,都不需要进行再次登录。
推荐:250期面试题如何进行代码的实现:使用Redis实现session共享的优缺点:解决方案四:结合cookie其实还可以把session放到cookie中去,因为每次用户请求的时候,都会把自己的cookie放到请求中,所以这样就能保证每次用户请求的时候都能保证用户在分布式环境下,也不会在进行二次登陆。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)