场景：
通过负载均衡之后，用户第一次请求的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