nginx集群tomcat，session共享问题

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了nginx集群tomcat，session共享问题，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4939字，纯文字阅读大概需要8分钟。

内容图文

场景：

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

内容总结

以上是互联网集市为您收集整理的nginx集群tomcat，session共享问题全部内容，希望文章能够帮你解决nginx集群tomcat，session共享问题所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---