SpringSession DefaultCookieSerializer.setJvmRoute可以工作，但是HttpServletRequest没有必需的jvmRoute

Question

我已经Redis在旧版Spring MVC应用程序中实现了Spring Session
。我还使用DefaultCookieSerializer来设置jvmRoute，因为我需要一些服务器亲和力才能运行Talend作业。

当运行前端并检查Chrome中的页面时，我看到了jvmRoute该会话的附件。如果将其从“ node1”编辑为“
node2”，则保留该会话。如果我在部署期间重新部署服务器并发出请求，我将被重定向到集群中的另一个节点，这意味着Spring Sessions可以正常工作。

但是，我无法获得服务器关联性，因为当我调试HttpServletRequestSpring应用程序中的a时，HttpServletRequest.getSession().getId()它没有其中jvmRoute的内容（尽管十六进制数字与我在Chrome中看到的匹配），这就是我传递给Talend的内容工作。

如果我恢复为Tomcat会话并jvmRoute在的Engine组件中设置，则在Chrome和调试代码中都会server.xml看到jvmRoute该会话ID
的附加内容。

到底是DefaultCookieSerializer做什么的？我认为它会在创建cookie时对其进行编辑，这就是cookie的存储方式Redis。因此，jmvRoute如果您以这种方式进行设置，则在创建该cookie后对它的任何使用都应附带附件。

Answer 1

DefaultCookieSerializer到底能做什么？我认为它会在创建cookie时对其进行编辑，这就是将cookie存储在Redis中的方式。因此，如果以这种方式进行设置，则在创建此cookie后对它的任何使用都应附加jmvRoute。

首先，重要的是要意识到cookie本身没有存储在会话存储中（即您的Redis）。存储的是会话本身及其属性的表示。

除了会话存储之外，会话管理的另一个重要方面是用户的HTTP请求与存储的会话之间的关联。有了Spring Session的Servlet
API支持，这是它的责任HttpSessionIdResolver，并且默认情况下，Spring
Session使用基于cookie的实现，即CookieHttpSessionIdResolver。中还有一个基于HTTP标头的实现HeaderHttpSessionIdResolver。我之所以这样说是因为，重要的是要意识到会话存储是在不同级别上运行的独特关注点。

现在，关于CookieHttpSessionIdResolver，它将cookie的编写和读取问题委托给CookieSerializer（DefaultCookieSerializer默认情况下是……）。根据其配置，DefaultCookieSerializer在写入和读取会话cookie时会考虑许多选项，例如cookie名称，是否对Base64编码cookie值，是否使用httpOnlycookie指令等。

但是，我无法获得服务器关联性，因为调试Spring应用程序中的HttpServletRequest时，HttpServletRequest.getSession（）。getId（）中没有jvmRoute（尽管十六进制数字与我在Chrome中看到的匹配）
），这就是我转交给塔伦德工作的目的。

这是我不理解的部分-
如果您能够HttpSession从当前的情况下解决问题，HttpServletRequest那么您知道jvmRoute它必然会正确吗？这是jvmRoute当前JVM的，否则会话将无法HttpServletRequest在此JVM的处理下解决。

什么是spring会议和Tomcat的会话管理之间的不同，是在Tomcat中jvmRoute是会话ID生成相关的问题，而与spring会议将jvmRoute在会话cookie序列化的环境中使用。