分布式【session共享】

一、业务场景

        用户去登录项目，用户进行一个session会话，一般的大公司的项目都是有Nginx进行反向代理的。

在Nginx的反向代理下，一般会把用户的请求分发到不同的服务器上，但是如果用户请求的请求是存放在该请求的服务器A上。如果此时用户请求的一个服务模块可能需要调用到服务器B，当用户发起请求的时候，此时的服务器B上并没有存储该用户的sessionID，所以就会再次让用户进行一个登陆操作。还有可能会导致用户本来就想完成一个下单操作，但是却还登陆了好几次的情况。

       故session共享方案在分布式环境和微服务系统下，显得尤其重要。

二、解决方案

       2.1、基于Nginx的ip_hash负载均衡

                即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;
 
    } 
}

                【优缺点】：

                  

        2.2、基于Tomcat的session复制

                  当用户请求的时候，把产生的sessionID给复制到系统所有的服务器中，这样就能保证当用户请求的时候从服务器A可能调用到服务器B上的模块的时候，也能保证服务B也有该用户的sessionID，这样就不会再次让用户进行再次登录操作了。也就解决问题了。

                 【具体实现】：                

                【优缺点】：               

                     

             2.3、使用Redis做缓存session统一

                      把每次用户的请求的时候生成的sessionID给放到Redis的服务器上。然后在基于Redis的特性进行设置一个失效时间的机制，这样就能保证用户在我们设置的Redis中的session失效时间内，都不需要进行再次登录。

                     【具体实现】： 

                     

                      【优缺点】：

                         

                2.4、结合cookie

                其实还可以把session放到cookie中去，因为每次用户请求的时候，都会把自己的cookie放到请求中，所以这样就能保证每次用户请求的时候都能保证用户在分布式环境下，也不会在进行二次登陆。