Redisson在Tomcat多节点环境中会话超时设置不一致问题分析

问题背景

在使用Redisson作为Tomcat会话管理器时，开发者在多节点Tomcat环境中遇到了会话超时时间(MaxInactiveInterval)设置不一致的问题。具体表现为：当应用尝试根据租户配置动态设置会话超时时间时，部分会话能正确应用自定义超时值，而另一些会话则回退到默认的60分钟超时设置。

问题现象

在典型的实现中，开发者会通过以下方式设置会话超时：

HttpSession session = req.getSession();
session.setMaxInactiveInterval(getDynamicValuePerTenant());

然而在多节点环境中，这个设置并不总是能正确生效。有趣的是，当在设置超时前加入300毫秒的延迟时，问题就消失了，这表明问题可能与异步处理机制有关。

原因分析

根据RedissonSessionManager的配置参数：

updateMode="AFTER_REQUEST"
readMode="MEMORY"

可以推断出问题的根源在于会话更新的时机和读取策略：

1. AFTER_REQUEST更新模式：会话数据在请求处理完成后才被持久化到Redis
2. MEMORY读取模式：直接从本地内存读取会话数据，不保证与Redis中的最新数据一致

这种组合在多节点环境下会导致竞态条件：

• 节点A处理请求并设置新的超时时间，但更新尚未持久化到Redis
• 节点B在处理后续请求时，从本地内存读取可能过期的会话数据
• 导致部分请求看到旧的超时设置

解决方案

针对这一问题，有以下几种可行的解决方案：

1. 修改更新模式

将updateMode改为"DEFAULT"或"IMMEDIATE"，使会话变更立即同步到Redis：

updateMode="IMMEDIATE"

这种模式会带来一定的性能开销，但能保证数据一致性。

2. 调整读取模式

使用"REDIS"读取模式，确保总是从Redis获取最新数据：

readMode="REDIS"

这会增加网络I/O，但能避免读取到过期的本地缓存数据。

3. 应用层延迟处理

如问题描述中所示，在关键操作后加入短暂延迟也能临时解决问题，但这并非优雅的解决方案。

4. 实现会话锁定机制

对于需要强一致性的场景，可以考虑实现会话级别的锁机制，确保在更新会话属性时不会被其他请求干扰。

最佳实践建议

对于大多数生产环境，推荐采用以下配置组合：

<Manager className="org.redisson.tomcat.RedissonSessionManager" 
        configPath="${catalina.base}/conf/redisson.yaml" 
        readMode="REDIS" 
        updateMode="DEFAULT"
        broadcastSessionEvents="true" 
        keyPrefix="test-sessions:" />

这种配置在数据一致性和性能之间取得了较好的平衡，特别适合对会话状态一致性要求较高的多节点部署场景。

结论

Redisson在多节点Tomcat环境中提供了强大的会话管理能力，但需要根据具体业务需求合理配置读写策略。理解updateMode和readMode的相互作用对于构建可靠的分布式会话系统至关重要。通过适当的配置调整，可以完全避免会话超时设置不一致的问题。