nginx集群tomcat，session共享问题

场景：

通过负载均衡之后，用户第一次请求的tomcat和第二次请求的tomcat基本不是同一个，但是你在第一次请求放在session中的值只有一个tomcat才， 第二个请求的那个tomcat里面是没有的。这样就出现了用户不停登入的情况。

方法一：复制session信息

原理：讲道理，这个方法比较蠢，就是有几个tomcat，就复制几个session，只要有一个tomcat中的session发生变化，其他tomcat中的session跟着复制变化， 保证所有用户的session在所有的tomcat中都存在而且相同。这样一来无论用户的请求被分配到哪个tomcat都是无所谓的，因为所有的tomcat中都有他们存放的session。

打个比方：如果tomcat相当于饭店，会话相当于筷子的话，如果每次吃饭都要用自己的筷子，那是不是要把每个饭店都放一双自己的筷子。这就是这个方法的原理。

实现：

1、修改sever.xml文件：将Cluster的注释去掉

2、打开自己项目的web.xml（不是tomcat/conf/web.xml）,增加distributable。

优点：实现简单，没有什么花里胡哨的操作。如果集群的tomcat不多，而且用户没有那么多的时候可以选择这种方式。

缺点：只要Session数据有变化，就需要将数据同步到所有其他机器上，机器越多，同步带来的网络带宽开销就越大；当用户很多时，

每台机器用于保存Session数据的内容占用会很严重。

方法二：ip绑定

原理：说白了就是上篇中说到的负载均衡算法的ip绑定，就是你第一次访问哪个tomcat，之后所有的请求都会被分配到那个tomcat上。

打个比方：如果tomcat相当于饭店，会话相当于筷子的话，要保证每次吃饭都用自己的筷子的话，我就把筷子存在某一家饭店，并且每次都去这家店吃饭。

优点：实现也比较简单，需要修改一下nginx的配置文件即可。

缺点：

1、一大堆人连同一个网访问的时候，就没有负载均衡这一说了，这一大堆的ip都是一样，都去访问同一个tomcat。

2、如果这个人访问的tomcat突然挂了，那nginx的故障转移机制将会分发给另一个tomcat服务器，这样一来所有请求这个tomcat的所有用户就又需要重新登入了。

3、如果这个人用着用着突然在用的网络不稳定，然后这个人换了另一个网，这样ip一换，这个人又要重新登入了。

方法三：tomcat-redis-session-manager（开源项目--基于redis实现）

session管理：

1.Manager接口类

定义了用来管理session的基本接口，包括：createSession，findSession，add，remove等对session操作的方法；

还有getMaxActive，setMaxActive，getActiveSessions活跃会话的管理；还有Session有效期的接口；以及与Container相关联的接口；

2.ManagerBase抽象类

实现了Manager接口，提供了基本的功能，使用ConcurrentHashMap存放session，提供了对session的create，find，add，remove功能，

并且在createSession中了使用类SessionIdGenerator来生成会话id，作为session的唯一标识；

3.ClusterManager接口类

实现了Manager接口，集群session的管理器，Tomcat内置的集群服务器之间的session复制功能；

4.ClusterManagerBase抽象类

继承了ManagerBase抽象类，实现ClusterManager接口类，实现session复制基本功能；

5.PersistentManagerBase抽象类

继承了ManagerBase抽象类，实现了session管理器持久化的基本功能；内部有一个Store存储类，具体实现有：FileStore和JDBCStore；

6.StandardManager类

继承ManagerBase抽象类，Tomcat默认的Session管理器（单机版）；对session提供了持久化功能，tomcat关闭的时候会将session保存到javax.servlet.context.tempdir路径下的SESSIONS.ser文件中，

启动的时候会从此文件中加载session；

7.PersistentManager类

继承PersistentManagerBase抽象类，如果session空闲时间过长，将空闲session转换为存储，所以在findsession时会首先从内存中获取session，

获取不到会多一步到store中获取，这也是PersistentManager类和StandardManager类的区别；

8.DeltaManager类

继承ClusterManagerBase，每一个节点session发生变更(增删改)，都会通知其他所有节点，其他所有节点进行更新操作，任何一个session在每个节点都有备份；

9.BackupManager类

继承ClusterManagerBase，会话数据只有一个备份节点，这个备份节点的位置集群中所有节点都可见；相比较DeltaManager数据传输量较小，

当集群规模比较大时DeltaManager的数据传输量会非常大；

10.RedisSessionManager类

继承ManagerBase抽象类，非Tomcat内置的管理器，使用redis集中存储session，省去了节点之间的session复制，依赖redis的可靠性，比起sessin复制扩展性更好；

Tomcat提供了一个开放的session管理和持久化的org.apache.catalina.session.ManagerBase，继承这个抽象类并做一些简单的配置，

即可让你的session管理类接管Tomcat的session读取和持久化，这里使用的是tomcat-redis-session-manager来管理session；

RedisSessionManager继承于org.apache.catalina.session.ManagerBase类，对session的相关操作都在此类中；

修改$TOMCAT_HOME/conf目录下的context.xml文件

<Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" />

<Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager"

host="localhost"

port="6379"

database="0"

maxInactiveInterval="60"/>

方法四：使用jwt（推荐使用）

原理：放弃session机制，使用jwt机制。简单来说就是userid+随机数+签名加密生成一个token，前后端通信通过token来交互。客户端第一次请求登入之后，

服务器端给客户端一个token，服务器将token作为key值，userid作为value值，30分钟作为有效时间存入redis中；客户端第二次访问controller之前进行拦截，

判断是否有token，如果有token解密获取userid，然后取查询redis，token和userid是否匹配，如果匹配就允许访问controller，请求返回之后，

服务器将重新生成新的token返回给客户端。简单来说就是每次请求成功之后token都会改变，token存在redis中，这样一来至于redis分发到哪个tomat并不影响，

因为token是存在redis中的。

方法五：使用 spring session