简介针对分布式Web应用中Tomcat集群会话无法共享的痛点这份tomcat-redis-session-manager资源包面向中高级Java开发与运维人员通过将Session数据持久化至Redis实现跨节点的会话一致性。压缩包共40个文件包含20个Java源码、15个Jar依赖库和5个XML配置文件整体约1.99MB目录按Tomcat 7/8.0/8.5/9与JDK 1.7/1.8的多种版本组合区分每个版本均提供源码、所需Jar及context.xml配置示例方便对照选用。其中Redis存储逻辑基于Tomcat的SessionStore接口扩展配套的common-pool2与Jedis依赖可直接放入lib目录帮助读者快速搭建环境。目前已有610人学习下载适合正在改造传统单体应用或搭建高可用集群的开发者参考既能直接集成使用也能通过源码研究Session序列化与过期策略的实现细节。 接手一个老项目用户量一上来就面临一个尴尬场景Nginx后面挂着两台Tomcat用户在A实例上登录下一次请求被负载均衡分到B实例直接变成未登录状态。这种Session不同步的问题在我经历过好几个Java Web集群项目之后基本已经成了固定剧情。当时我选的解决工具是tomcat-redis-session-manager一个把Tomcat本地Session挪到Redis里的Manager扩展。这篇文章就围绕这个项目把它的原理、集成步骤、配置关键点以及我在生产环境里踩过的坑完整梳理一遍。适合正在维护多实例Tomcat应用、或者准备从单机往集群迁移的Java后端开发。1. 什么时候需要给Tomcat装一个共享Session仓库1.1 从一次用户骂街说起很多团队第一次意识到Session共享问题都是出了线上事故之后。我有一个朋友的公司做了一个面向C端的门户网站部署两台Tomcat做负载均衡。最初他们以为只要服务器数量上去了稳定性自然有保障结果上线第三天就收到大量用户反馈登录状态一会儿有效一会儿无效有时候刷新几遍才能看到自己的账户信息。排查之后发现问题出在Session上。用户第一次请求被分配到Tomcat ATomcat A把登录Session存在自己的JVM内存里第二次请求如果被Nginx转发到Tomcat BTomcat B的本地内存里自然没有这份Session。浏览器端携带的JSESSIONID在B实例上查找不到对应会话此时B就会认为用户是新人要么让他重新登录要么在响应里生成一个新的JSESSIONID。用户体感就是登录状态不稳定动不动要重新登。1.2 为什么Session复制和粘滞会话都差点意思面对这个问题的第一反应往往是两个方案开启Tomcat的Session复制比如DeltaManager或者让Nginx做粘滞会话sticky session。Session复制的原理是Tomcat A上的Session发生变化后通过组播或TCP把序列化好的数据同步给集群里其他的Tomcat实例。坏处很明显集群规模一大同步消息数量呈指数膨胀每次请求结束都要做一次全量或增量复制网络和CPU双双受苦。实际生产中Session复制在三台以下的极小集群里勉强能用再往上就是给自己挖坑。粘滞会话则是把同一个用户的请求固定转发到同一台Tomcat。这个方案对后端来说最简单却把状态压力全部留给了单台机器。想象一下某台Tomcat被分配给了一部分活跃用户它挂了那部分用户的Session也跟着消失而且Nginx若只在转发时做粘滞判断、不考虑后端存活状态维护起来非常费劲。再加上后端一旦需要滚动发布、重启实例粘滞会话同样会造成用户大面积掉线。所以理智的选择是把Session从Tomcat的内存仓库里拿出来集中放到一个独立的存储中间件中。Redis因为支持多种数据结构、有丰富的过期策略、本身是网络存储服务不绑定任何一个应用实例成了最常用的Session外部化载体。tomcat-redis-session-manager这个项目做的事情就是接管Tomcat的Session生命周期让Session数据的读写发生在Redis上而不是Tomcat的堆内存里。2. 看懂调用链RedisSessionManager到底在Tomcat里干了什么2.1 Manager的三件事创建、查找、销毁在Tomcat架构里Session是由一个Manager组件统一管理的。无论是StandardManager、PersistentManager还是第三方提供的RedisSessionManager它们的核心职责都是三件事创建新Session、根据SessionID查找已有Session、销毁过期Session。Tomcat本身定义了一个Manager接口但大多数人写自定义Manager时会选择继承StandardManager而不是直接从头实现这个接口。原因在于StandardManager已经处理好了Session的生成策略、监听器通知、生命周期管理等底层繁琐逻辑我们只需要覆盖几个关键方法把数据存取改造成Redis读写即可。tomcat-redis-session-manager就是这样一个典型的继承实现。它的核心类是RedisSessionManager内部组合了一个RedisSession对象。这个RedisSession不是StandardSession那样的纯内存对象它内部维护了一个currentSessionAttributes的Map结构作为缓存同时对Redis上的真实Session数据进行读写。2.2 请求生命周期里Session怎么进Redis一次典型的请求会经历这样的链路请求到达Tomcat后容器根据JSESSIONID调用findSession。如果属于RedisSessionManager它会先从Redis里读取序列化后的Session数据反序列化后封装成RedisSession对象返回。请求处理过程中Servlet代码可以正常执行session.setAttribute之类的操作。请求结束后Tomcat触发save方法RedisSessionManager把Session的过期时间更新到Redis并根据数据变化情况决定是否需要把整个Session对象重新写回Redis。这个设计把Session的存取与Web应用的业务逻辑解耦了。对于业务代码来说它看到的还是普通的javax.servlet.http.HttpSession和单机部署时没有任何区别。这种透明接管的做法正是这个项目最大的价值所在。理解这个调用链对排错非常有意义。我见过有人在排查时只盯着业务代码却不知道Session数据其实是从Redis反序列化回来的结果浪费了大半天时间。实际上你只要在Redis里执行一条keys session:*命令看到前面带着session:前缀的key就能立刻意识到当前请求的会话已经由RedisManager接管了。这个后缀前缀也不是绝对的早期版本默认前缀就叫session:有些fork版本改成了可配置项。3. 从下载到跑通集成步骤与配置项详解3.1 选对分支与依赖版本组合很多人以为下载了jar包丢进Tomcat就能用实际上这个项目存在历史演进分支版本和目标Tomcat环境的对应关系必须注意。经典版本是jcoleman/tomcat-redis-session-manager它支持Tomcat 6、7以及早期8.x。后来Tomcat 9横空出世包名从javax.servlet换成jakarta.servlet老版本就编译不过了社区里为此出现了多个兼容性fork比如JosephCMusic/tomcat-redis-session-manager这样的后续维护分支。我做的项目当时是Tomcat 8.5所以直接用的经典老版本配套的源码编译依赖jedis和commons-pool2。如果你现在新建项目用的是Tomcat 9或Tomcat 10建议先确认你拿到的Manager jar包是用哪个Tomcat版本编译的不然启动时会出现各种NoSuchMethodError或ClassNotFoundException非常让人头疼。依赖jar的版本也需要对齐。RedisSessionManager早期版本基于Jedis 2.x如果你强行塞一个Jedis 4.x进去会因为API差异报错。最稳妥的办法是找到项目源码里的pom.xml照着里面锁定的jedis版本和commons-pool2版本去下载依赖。别偷懒直接搜最新版那是在给自己制造工作量。3.2 在context.xml里挂上自定义Manager集成的方式也很直白把这个Manager配置到Tomcat的conf/context.xml里或者放到某个应用的META-INF/context.xml中二选一即可。全局配置的作用范围是这台Tomcat上所有的Web应用而应用内配置只对单个应用生效。公司内如果只有一个业务系统共享这台Tomcat用全局配置省事如果一台Tomcat上跑着多个互相隔离的应用建议用应用内配置避免Session互相干扰。配置内容大致如下Context Valve classNamecom.orangefunction.tomcat.redissessions.RedisSessionHandlerValve / Manager classNamecom.orangefunction.tomcat.redissessions.RedisSessionManager host127.0.0.1 port6379 database0 passwordyour-redis-password maxInactiveInterval60 maxActiveSession10000 / /Context其中RedisSessionHandlerValve这个Valve是用来在请求结束后触发Session保存动作的必须和Manager成对出现。很多初学者只配置了Manager忘了配Valve结果Session永远写不进Redis查半天找不到原因。关键参数的意义如下host、portRedis地址和端口不多解释。databaseRedis的db编号默认0。多个应用共用一套Redis时可以分库隔离。passwordRedis认证密码没有密码就不写。maxInactiveIntervalSession过期时间单位秒。这个值对应的是Session在Redis里的TTL上限应用里如果单独调用了setMaxInactiveInterval那么请求时会动态更新。maxActiveSessionRedisSessionManager内部的一个容量限制参数防止有人恶意创建海量Session拖垮Redis。3.3 验证如何确认Session真的进了Redis配置完成后启动Tomcat不要急着马上测试业务功能先做一次最小化验证。先看Tomcat启动日志。正常启动时RedisSessionManager会打印一行register redis session manager之类的日志看到这行说明Manager已经成功注册了。如果这里就报错排查方向应该是依赖jar缺失、Redis网络不通、配置项拼写错误。然后起一个最简单的Servlet往Session里写一个字符串属性再访问任意一个页面触发Session创建。之后在Redis客户端里执行keys session:*如果能看到类似session:9C7F3A0B2E4D1F6A的key说明Session已经成功写入。再执行type session:9C7F3A0B2E4D1F6A返回的应该是string类型说明这个Manager的默认存储方式是序列化字符串而不是hash结构。ttl命令可以确认Session是否有合理的过期时间。我习惯再用一个最直观的办法测试共享效果在Tomcat A和Tomcat B上都部署同一个应用配置同一个Redis然后在浏览器里请求A生成Session把JSESSIONID拿到Linux服务器上用curl带过去请求B看B能否识别出相同的Session。这个测试能直接验证整个集群的Session共享链路是否通畅。4. 序列化、脏写入与会话锁三个必踩的坑4.1 存进去的对象不带接口直接NotSerializableExceptionRedisSessionManager默认使用Java原生序列化机制意味着你放进Session的所有自定义对象类必须实现java.io.Serializable接口。很多人只注意到把登录用户信息塞进Session却忽略了嵌套对象。我遇到过一位同事他把一个UserInfo对象放进了SessionUserInfo本身实现了Serializable但里面的成员变量是一个自定义的Address对象Address没有实现Serializable。序列化时直接报了NotSerializableException。这个异常在请求处理过程中被Tomcat封装成了java.io.IOException表面看起来像是Redis写失败实际上根源是对象图的某个节点没有实现接口。解决办法有两类。第一类是给所有涉及的实体类补齐Serializable接口第二类是改用JSON序列化方案。有一些fork版本支持把Session数据序列化成JSON字符串或者通过实现自定义的Serializer接口来替换默认序列化方式。如果你的系统里有大量历史对象、短期内无法逐个改造优先考虑支持自定义序列化器的版本或直接上Spring Session。4.2 getAttribute之后改属性Session不会自动回写这是整个项目里最常见的坑我称之为脏写入问题。看过代码的朋友应该知道RedisSession内部有一个modifiedAttributes之类的集合用来标记哪些属性被显式setAttribute过。当请求结束时Manager遍历这个集合把对应的属性序列化后写回Redis。但问题在于如果你先session.getAttribute(user)拿到一个Java对象然后直接修改这个对象的内部字段比如user.setName(admin)这个操作并不会触发setAttribute所以modifiedAttributes集合里没有user这个key修改结果自然不会被同步到Redis。这种现象在单机Session中不存在因为Tomcat本地Session直接持有对象引用你改了对象内容内存里就是改了。但RedisSessionManager的存储模型是每次序列化快照式的它只认你通过setAttribute交给它的值。正确的写法是UserInfo user (UserInfo) session.getAttribute(user); user.setName(admin); session.setAttribute(user, user);核心原则是重新把修改后的完整对象塞回Session。这也意味着Session里放的对象应该设计成可以整体替换的而不是依赖内部状态变化来触发持久化。如果你需要频繁修改某个对象的某个字段还不想每次都setAttribute那就要考虑把Session里的数据设计得更细粒度比如一个字段一个key或者直接考虑上Spring Session结合SessionRepository自定义的更新机制。4.3 关于锁的朴素理解和真实差距Session在单机集群模式下通常是指同一个JVM里的互斥锁用于避免多个并发请求同时修改Session导致的数据竞争。Tomcat标准Manager里对Session有访问锁机制RedisSessionManager也沿袭了类似的思路同一个Tomcat实例内多个线程访问同一个Session时是有锁保护的。但是集群环境下这个锁的覆盖范围仅限于单个Tomcat实例并不能跨实例协调。设想一下用户同一个浏览器标签页同时发出两个请求一个请求落到Tomcat A另一个落到Tomcat B两个实例都从Redis读出了同一个Session的旧副本各自修改后写回Redis最后写入的覆盖了前一个另一个请求的修改就丢了。这就是分布式环境下的Session丢失问题的变体。要彻底解决这个问题需要引入真正的分布式锁或版本号机制。tomcat-redis-session-manager本身没有提供这方面的方案所以在生产环境里必须从架构层面规避比如确保同一个用户的请求都路由到同一个Tomcat实例这时候粘滞会话反而变成了保护手段或者在业务层面保证同一个用户的不同请求之间没有并发冲突。这个坑对并发量高的站点尤其致命我实际处理时最终是把Nginx的ip_hash策略打开配合RedisSessionManager。这样正常情况下同一个用户总是落到同一台Tomcat再退一步说即使某台机器挂了Session数据还在Redis里Failover之后用户也不会掉线只是Session访问又会回归到Redis的中央存储模型。5. 集群联调与生产加固比项目本身更重要的几件事5.1 Nginx的路由策略还要不要配置从Session跨机器不丢的角度RedisSessionManager已经解决了集中存储的问题但生产环境的请求路由依然值得认真设计。ip_hash虽然能保证同一个IP的请求大概率落到同一台后端但在NAT环境下同一个用户的来源IP可能变化就会导致路由不稳定。更复杂一点的是如果前端挂的是CDN所有用户的请求都从CDN节点转发过来来源IP可能都一样ip_hash直接退化为只打一台机器的灾难。我当时用的方案是Nginx的sticky模块基于Cookie做会话保持。Nginx第一次收到请求时会在响应里种一个routeCookie后续请求带上这个CookieNginx就根据Cookie中的路由信息把请求转发给同一台Tomcat。这个方案的粒度更精准也不会被NAT打乱。有人可能会问既然Session已经塞进Redis了为什么还要做会话保持答案可以从上面第4节的3个坑里找到一是避免并发修改造成的Session覆盖二是减少反序列化次数降低Redis请求压力三是某些遗留代码的线程安全问题在单实例访问下不会暴露。会话保持和集中存储并不冲突它们是两道不同方向的安全措施。5.2 Redis故障时的Session安全这是另一个容易让人措手不及的问题。当我刚开始把Session迁到Redis时脑子里有个错误的安全感Tomcat标准Manager把Session存在JVM内存里Tomcat重启就全没了现在有了RedisSession存活周期变长了总该安全了吧。但真相是使用RedisSessionManager之后如果Redis挂掉了Tomcat处理请求时无法加载Session用户的会话数据会直接消失而且影响范围是集群整体不是单台。所以在正式环境里必须针对Redis高可用做设计。最直接的手段是给Redis配置主从加哨兵Sentinel或者直接上Redis Cluster。但要注意早期版本的tomcat-redis-session-manager对Sentinel和Cluster的支持并不好基本只支持单机Redis或简单的Master-Slave模式。假如你的基础设施已经做了主从切换客户端连的是新主节点而旧主上未同步的数据就丢了Session此刻也面临丢失风险。我在测试环境亲身遇到过Redis主节点宕机哨兵把从节点提升为主节点连接恢复后应用并没有报错但大量Session位置从Redis里查不出来用户大面积强制重新登录因为旧主节点上未复制到从节点的Session数据在故障切换瞬间丢掉了。这个问题的彻底解法很残酷要么接受Session在故障切换的瞬间可能丢失要么在业务上降低对Session数据的依赖比如把重要状态放到数据库里要么自己封装一层Redis的读写策略比如故障降级到本地Session但那样又会破坏一致性。对于中小规模应用我的建议是给Redis配好主从加哨兵Session丢失的概率控制在极小范围内同时在Gateway层面做好拓扑感知尽量优雅处理那段故障窗口。5.3 如果项目还能换方案Spring Session值不值得迁移用tomcat-redis-session-manager有一个绕不开的问题它不是Servlet标准委员会出的也不是Tomcat官方维护的社区活跃度起伏不定Tomcat一升级就面临兼容性风险。如果你所在的团队技术栈已经用Spring Boot或Spring Cloud我更推荐直接评估Spring Session。Spring Session和tomcat-redis-session-manager的核心区别在于它不是去替换Tomcat的Manager而是通过一层Filter代理HttpServletRequest和HttpSession把Session的读写委托给一个SessionRepository。Spring Session官方把redis的repository实现和维护工作接了过来兼容性稳定性更好也允许你用Jackson或Kryo做自定义序列化不用受限于Java原生序列化。但换方案不是没有成本。tomcat-redis-session-manager最大的优势是透明它替换的是Tomcat容器级别的组件Web应用本身完全无感知WAR包丢进去就能跑。Spring Session则要求应用使用统一的SessionRepository接口并且要调整一些Session过滤相关的代码。如果你们的应用是遗留的老WAR包、ClassLoader又比较乱强行上Spring Session反而会引入一堆兼容性疑难杂症。所以我的建议是分场景看待老系统、以WAR包部署、没有能力大改代码那就继续用tomcat-redis-session-manager的fork版本锁死Tomcat版本别随便升级新系统、Spring Boot项目、对可维护性要求高从一开始就用Spring Session把Session层抽象掉。结尾我在生产环境里的体会把这个项目跑通并不难难的是把它跑在生产环境里。回头梳理这段经历最值钱的教训有两个第一个是Session外部化意味着状态责任从Tomcat转移到了RedisRedis的稳定性直接等于应用的可用性所以Redis高可用一定要前置设计第二个是Session的生命周期和请求路由强相关光有Session Manager还不够Nginx策略、应用代码的序列化意识、对象更新的写法全都得跟着调整。如果你手头的项目正卡在多实例Session同步的问题上这个项目能解决八成问题剩下的两成需要你在部署架构上想办法。本文还有配套的精品资源点击获取 Tomcat集群Session共享：基于Redis的集中会话管理实践
简介针对分布式Web应用中Tomcat集群会话无法共享的痛点这份tomcat-redis-session-manager资源包面向中高级Java开发与运维人员通过将Session数据持久化至Redis实现跨节点的会话一致性。压缩包共40个文件包含20个Java源码、15个Jar依赖库和5个XML配置文件整体约1.99MB目录按Tomcat 7/8.0/8.5/9与JDK 1.7/1.8的多种版本组合区分每个版本均提供源码、所需Jar及context.xml配置示例方便对照选用。其中Redis存储逻辑基于Tomcat的SessionStore接口扩展配套的common-pool2与Jedis依赖可直接放入lib目录帮助读者快速搭建环境。目前已有610人学习下载适合正在改造传统单体应用或搭建高可用集群的开发者参考既能直接集成使用也能通过源码研究Session序列化与过期策略的实现细节。 接手一个老项目用户量一上来就面临一个尴尬场景Nginx后面挂着两台Tomcat用户在A实例上登录下一次请求被负载均衡分到B实例直接变成未登录状态。这种Session不同步的问题在我经历过好几个Java Web集群项目之后基本已经成了固定剧情。当时我选的解决工具是tomcat-redis-session-manager一个把Tomcat本地Session挪到Redis里的Manager扩展。这篇文章就围绕这个项目把它的原理、集成步骤、配置关键点以及我在生产环境里踩过的坑完整梳理一遍。适合正在维护多实例Tomcat应用、或者准备从单机往集群迁移的Java后端开发。1. 什么时候需要给Tomcat装一个共享Session仓库1.1 从一次用户骂街说起很多团队第一次意识到Session共享问题都是出了线上事故之后。我有一个朋友的公司做了一个面向C端的门户网站部署两台Tomcat做负载均衡。最初他们以为只要服务器数量上去了稳定性自然有保障结果上线第三天就收到大量用户反馈登录状态一会儿有效一会儿无效有时候刷新几遍才能看到自己的账户信息。排查之后发现问题出在Session上。用户第一次请求被分配到Tomcat ATomcat A把登录Session存在自己的JVM内存里第二次请求如果被Nginx转发到Tomcat BTomcat B的本地内存里自然没有这份Session。浏览器端携带的JSESSIONID在B实例上查找不到对应会话此时B就会认为用户是新人要么让他重新登录要么在响应里生成一个新的JSESSIONID。用户体感就是登录状态不稳定动不动要重新登。1.2 为什么Session复制和粘滞会话都差点意思面对这个问题的第一反应往往是两个方案开启Tomcat的Session复制比如DeltaManager或者让Nginx做粘滞会话sticky session。Session复制的原理是Tomcat A上的Session发生变化后通过组播或TCP把序列化好的数据同步给集群里其他的Tomcat实例。坏处很明显集群规模一大同步消息数量呈指数膨胀每次请求结束都要做一次全量或增量复制网络和CPU双双受苦。实际生产中Session复制在三台以下的极小集群里勉强能用再往上就是给自己挖坑。粘滞会话则是把同一个用户的请求固定转发到同一台Tomcat。这个方案对后端来说最简单却把状态压力全部留给了单台机器。想象一下某台Tomcat被分配给了一部分活跃用户它挂了那部分用户的Session也跟着消失而且Nginx若只在转发时做粘滞判断、不考虑后端存活状态维护起来非常费劲。再加上后端一旦需要滚动发布、重启实例粘滞会话同样会造成用户大面积掉线。所以理智的选择是把Session从Tomcat的内存仓库里拿出来集中放到一个独立的存储中间件中。Redis因为支持多种数据结构、有丰富的过期策略、本身是网络存储服务不绑定任何一个应用实例成了最常用的Session外部化载体。tomcat-redis-session-manager这个项目做的事情就是接管Tomcat的Session生命周期让Session数据的读写发生在Redis上而不是Tomcat的堆内存里。2. 看懂调用链RedisSessionManager到底在Tomcat里干了什么2.1 Manager的三件事创建、查找、销毁在Tomcat架构里Session是由一个Manager组件统一管理的。无论是StandardManager、PersistentManager还是第三方提供的RedisSessionManager它们的核心职责都是三件事创建新Session、根据SessionID查找已有Session、销毁过期Session。Tomcat本身定义了一个Manager接口但大多数人写自定义Manager时会选择继承StandardManager而不是直接从头实现这个接口。原因在于StandardManager已经处理好了Session的生成策略、监听器通知、生命周期管理等底层繁琐逻辑我们只需要覆盖几个关键方法把数据存取改造成Redis读写即可。tomcat-redis-session-manager就是这样一个典型的继承实现。它的核心类是RedisSessionManager内部组合了一个RedisSession对象。这个RedisSession不是StandardSession那样的纯内存对象它内部维护了一个currentSessionAttributes的Map结构作为缓存同时对Redis上的真实Session数据进行读写。2.2 请求生命周期里Session怎么进Redis一次典型的请求会经历这样的链路请求到达Tomcat后容器根据JSESSIONID调用findSession。如果属于RedisSessionManager它会先从Redis里读取序列化后的Session数据反序列化后封装成RedisSession对象返回。请求处理过程中Servlet代码可以正常执行session.setAttribute之类的操作。请求结束后Tomcat触发save方法RedisSessionManager把Session的过期时间更新到Redis并根据数据变化情况决定是否需要把整个Session对象重新写回Redis。这个设计把Session的存取与Web应用的业务逻辑解耦了。对于业务代码来说它看到的还是普通的javax.servlet.http.HttpSession和单机部署时没有任何区别。这种透明接管的做法正是这个项目最大的价值所在。理解这个调用链对排错非常有意义。我见过有人在排查时只盯着业务代码却不知道Session数据其实是从Redis反序列化回来的结果浪费了大半天时间。实际上你只要在Redis里执行一条keys session:*命令看到前面带着session:前缀的key就能立刻意识到当前请求的会话已经由RedisManager接管了。这个后缀前缀也不是绝对的早期版本默认前缀就叫session:有些fork版本改成了可配置项。3. 从下载到跑通集成步骤与配置项详解3.1 选对分支与依赖版本组合很多人以为下载了jar包丢进Tomcat就能用实际上这个项目存在历史演进分支版本和目标Tomcat环境的对应关系必须注意。经典版本是jcoleman/tomcat-redis-session-manager它支持Tomcat 6、7以及早期8.x。后来Tomcat 9横空出世包名从javax.servlet换成jakarta.servlet老版本就编译不过了社区里为此出现了多个兼容性fork比如JosephCMusic/tomcat-redis-session-manager这样的后续维护分支。我做的项目当时是Tomcat 8.5所以直接用的经典老版本配套的源码编译依赖jedis和commons-pool2。如果你现在新建项目用的是Tomcat 9或Tomcat 10建议先确认你拿到的Manager jar包是用哪个Tomcat版本编译的不然启动时会出现各种NoSuchMethodError或ClassNotFoundException非常让人头疼。依赖jar的版本也需要对齐。RedisSessionManager早期版本基于Jedis 2.x如果你强行塞一个Jedis 4.x进去会因为API差异报错。最稳妥的办法是找到项目源码里的pom.xml照着里面锁定的jedis版本和commons-pool2版本去下载依赖。别偷懒直接搜最新版那是在给自己制造工作量。3.2 在context.xml里挂上自定义Manager集成的方式也很直白把这个Manager配置到Tomcat的conf/context.xml里或者放到某个应用的META-INF/context.xml中二选一即可。全局配置的作用范围是这台Tomcat上所有的Web应用而应用内配置只对单个应用生效。公司内如果只有一个业务系统共享这台Tomcat用全局配置省事如果一台Tomcat上跑着多个互相隔离的应用建议用应用内配置避免Session互相干扰。配置内容大致如下Context Valve classNamecom.orangefunction.tomcat.redissessions.RedisSessionHandlerValve / Manager classNamecom.orangefunction.tomcat.redissessions.RedisSessionManager host127.0.0.1 port6379 database0 passwordyour-redis-password maxInactiveInterval60 maxActiveSession10000 / /Context其中RedisSessionHandlerValve这个Valve是用来在请求结束后触发Session保存动作的必须和Manager成对出现。很多初学者只配置了Manager忘了配Valve结果Session永远写不进Redis查半天找不到原因。关键参数的意义如下host、portRedis地址和端口不多解释。databaseRedis的db编号默认0。多个应用共用一套Redis时可以分库隔离。passwordRedis认证密码没有密码就不写。maxInactiveIntervalSession过期时间单位秒。这个值对应的是Session在Redis里的TTL上限应用里如果单独调用了setMaxInactiveInterval那么请求时会动态更新。maxActiveSessionRedisSessionManager内部的一个容量限制参数防止有人恶意创建海量Session拖垮Redis。3.3 验证如何确认Session真的进了Redis配置完成后启动Tomcat不要急着马上测试业务功能先做一次最小化验证。先看Tomcat启动日志。正常启动时RedisSessionManager会打印一行register redis session manager之类的日志看到这行说明Manager已经成功注册了。如果这里就报错排查方向应该是依赖jar缺失、Redis网络不通、配置项拼写错误。然后起一个最简单的Servlet往Session里写一个字符串属性再访问任意一个页面触发Session创建。之后在Redis客户端里执行keys session:*如果能看到类似session:9C7F3A0B2E4D1F6A的key说明Session已经成功写入。再执行type session:9C7F3A0B2E4D1F6A返回的应该是string类型说明这个Manager的默认存储方式是序列化字符串而不是hash结构。ttl命令可以确认Session是否有合理的过期时间。我习惯再用一个最直观的办法测试共享效果在Tomcat A和Tomcat B上都部署同一个应用配置同一个Redis然后在浏览器里请求A生成Session把JSESSIONID拿到Linux服务器上用curl带过去请求B看B能否识别出相同的Session。这个测试能直接验证整个集群的Session共享链路是否通畅。4. 序列化、脏写入与会话锁三个必踩的坑4.1 存进去的对象不带接口直接NotSerializableExceptionRedisSessionManager默认使用Java原生序列化机制意味着你放进Session的所有自定义对象类必须实现java.io.Serializable接口。很多人只注意到把登录用户信息塞进Session却忽略了嵌套对象。我遇到过一位同事他把一个UserInfo对象放进了SessionUserInfo本身实现了Serializable但里面的成员变量是一个自定义的Address对象Address没有实现Serializable。序列化时直接报了NotSerializableException。这个异常在请求处理过程中被Tomcat封装成了java.io.IOException表面看起来像是Redis写失败实际上根源是对象图的某个节点没有实现接口。解决办法有两类。第一类是给所有涉及的实体类补齐Serializable接口第二类是改用JSON序列化方案。有一些fork版本支持把Session数据序列化成JSON字符串或者通过实现自定义的Serializer接口来替换默认序列化方式。如果你的系统里有大量历史对象、短期内无法逐个改造优先考虑支持自定义序列化器的版本或直接上Spring Session。4.2 getAttribute之后改属性Session不会自动回写这是整个项目里最常见的坑我称之为脏写入问题。看过代码的朋友应该知道RedisSession内部有一个modifiedAttributes之类的集合用来标记哪些属性被显式setAttribute过。当请求结束时Manager遍历这个集合把对应的属性序列化后写回Redis。但问题在于如果你先session.getAttribute(user)拿到一个Java对象然后直接修改这个对象的内部字段比如user.setName(admin)这个操作并不会触发setAttribute所以modifiedAttributes集合里没有user这个key修改结果自然不会被同步到Redis。这种现象在单机Session中不存在因为Tomcat本地Session直接持有对象引用你改了对象内容内存里就是改了。但RedisSessionManager的存储模型是每次序列化快照式的它只认你通过setAttribute交给它的值。正确的写法是UserInfo user (UserInfo) session.getAttribute(user); user.setName(admin); session.setAttribute(user, user);核心原则是重新把修改后的完整对象塞回Session。这也意味着Session里放的对象应该设计成可以整体替换的而不是依赖内部状态变化来触发持久化。如果你需要频繁修改某个对象的某个字段还不想每次都setAttribute那就要考虑把Session里的数据设计得更细粒度比如一个字段一个key或者直接考虑上Spring Session结合SessionRepository自定义的更新机制。4.3 关于锁的朴素理解和真实差距Session在单机集群模式下通常是指同一个JVM里的互斥锁用于避免多个并发请求同时修改Session导致的数据竞争。Tomcat标准Manager里对Session有访问锁机制RedisSessionManager也沿袭了类似的思路同一个Tomcat实例内多个线程访问同一个Session时是有锁保护的。但是集群环境下这个锁的覆盖范围仅限于单个Tomcat实例并不能跨实例协调。设想一下用户同一个浏览器标签页同时发出两个请求一个请求落到Tomcat A另一个落到Tomcat B两个实例都从Redis读出了同一个Session的旧副本各自修改后写回Redis最后写入的覆盖了前一个另一个请求的修改就丢了。这就是分布式环境下的Session丢失问题的变体。要彻底解决这个问题需要引入真正的分布式锁或版本号机制。tomcat-redis-session-manager本身没有提供这方面的方案所以在生产环境里必须从架构层面规避比如确保同一个用户的请求都路由到同一个Tomcat实例这时候粘滞会话反而变成了保护手段或者在业务层面保证同一个用户的不同请求之间没有并发冲突。这个坑对并发量高的站点尤其致命我实际处理时最终是把Nginx的ip_hash策略打开配合RedisSessionManager。这样正常情况下同一个用户总是落到同一台Tomcat再退一步说即使某台机器挂了Session数据还在Redis里Failover之后用户也不会掉线只是Session访问又会回归到Redis的中央存储模型。5. 集群联调与生产加固比项目本身更重要的几件事5.1 Nginx的路由策略还要不要配置从Session跨机器不丢的角度RedisSessionManager已经解决了集中存储的问题但生产环境的请求路由依然值得认真设计。ip_hash虽然能保证同一个IP的请求大概率落到同一台后端但在NAT环境下同一个用户的来源IP可能变化就会导致路由不稳定。更复杂一点的是如果前端挂的是CDN所有用户的请求都从CDN节点转发过来来源IP可能都一样ip_hash直接退化为只打一台机器的灾难。我当时用的方案是Nginx的sticky模块基于Cookie做会话保持。Nginx第一次收到请求时会在响应里种一个routeCookie后续请求带上这个CookieNginx就根据Cookie中的路由信息把请求转发给同一台Tomcat。这个方案的粒度更精准也不会被NAT打乱。有人可能会问既然Session已经塞进Redis了为什么还要做会话保持答案可以从上面第4节的3个坑里找到一是避免并发修改造成的Session覆盖二是减少反序列化次数降低Redis请求压力三是某些遗留代码的线程安全问题在单实例访问下不会暴露。会话保持和集中存储并不冲突它们是两道不同方向的安全措施。5.2 Redis故障时的Session安全这是另一个容易让人措手不及的问题。当我刚开始把Session迁到Redis时脑子里有个错误的安全感Tomcat标准Manager把Session存在JVM内存里Tomcat重启就全没了现在有了RedisSession存活周期变长了总该安全了吧。但真相是使用RedisSessionManager之后如果Redis挂掉了Tomcat处理请求时无法加载Session用户的会话数据会直接消失而且影响范围是集群整体不是单台。所以在正式环境里必须针对Redis高可用做设计。最直接的手段是给Redis配置主从加哨兵Sentinel或者直接上Redis Cluster。但要注意早期版本的tomcat-redis-session-manager对Sentinel和Cluster的支持并不好基本只支持单机Redis或简单的Master-Slave模式。假如你的基础设施已经做了主从切换客户端连的是新主节点而旧主上未同步的数据就丢了Session此刻也面临丢失风险。我在测试环境亲身遇到过Redis主节点宕机哨兵把从节点提升为主节点连接恢复后应用并没有报错但大量Session位置从Redis里查不出来用户大面积强制重新登录因为旧主节点上未复制到从节点的Session数据在故障切换瞬间丢掉了。这个问题的彻底解法很残酷要么接受Session在故障切换的瞬间可能丢失要么在业务上降低对Session数据的依赖比如把重要状态放到数据库里要么自己封装一层Redis的读写策略比如故障降级到本地Session但那样又会破坏一致性。对于中小规模应用我的建议是给Redis配好主从加哨兵Session丢失的概率控制在极小范围内同时在Gateway层面做好拓扑感知尽量优雅处理那段故障窗口。5.3 如果项目还能换方案Spring Session值不值得迁移用tomcat-redis-session-manager有一个绕不开的问题它不是Servlet标准委员会出的也不是Tomcat官方维护的社区活跃度起伏不定Tomcat一升级就面临兼容性风险。如果你所在的团队技术栈已经用Spring Boot或Spring Cloud我更推荐直接评估Spring Session。Spring Session和tomcat-redis-session-manager的核心区别在于它不是去替换Tomcat的Manager而是通过一层Filter代理HttpServletRequest和HttpSession把Session的读写委托给一个SessionRepository。Spring Session官方把redis的repository实现和维护工作接了过来兼容性稳定性更好也允许你用Jackson或Kryo做自定义序列化不用受限于Java原生序列化。但换方案不是没有成本。tomcat-redis-session-manager最大的优势是透明它替换的是Tomcat容器级别的组件Web应用本身完全无感知WAR包丢进去就能跑。Spring Session则要求应用使用统一的SessionRepository接口并且要调整一些Session过滤相关的代码。如果你们的应用是遗留的老WAR包、ClassLoader又比较乱强行上Spring Session反而会引入一堆兼容性疑难杂症。所以我的建议是分场景看待老系统、以WAR包部署、没有能力大改代码那就继续用tomcat-redis-session-manager的fork版本锁死Tomcat版本别随便升级新系统、Spring Boot项目、对可维护性要求高从一开始就用Spring Session把Session层抽象掉。结尾我在生产环境里的体会把这个项目跑通并不难难的是把它跑在生产环境里。回头梳理这段经历最值钱的教训有两个第一个是Session外部化意味着状态责任从Tomcat转移到了RedisRedis的稳定性直接等于应用的可用性所以Redis高可用一定要前置设计第二个是Session的生命周期和请求路由强相关光有Session Manager还不够Nginx策略、应用代码的序列化意识、对象更新的写法全都得跟着调整。如果你手头的项目正卡在多实例Session同步的问题上这个项目能解决八成问题剩下的两成需要你在部署架构上想办法。本文还有配套的精品资源点击获取