可以在没有粘性会话的情况下进行会话复制吗?

发布于 2025-01-06 21:44:58 字数 209 浏览 4 评论 0原文

在 Tomcat 上下文中,是否可以在不启用粘性会话的情况下进行会话复制?

我理解粘性会话的目的是让客户端在整个会话中“粘”到一台服务器。通过会话复制,客户端与服务器的交互将被复制到整个集群(许多 Web 服务器)。

在上述情况下,是否可以进行会话复制?也就是说,客户端的会话遍布整个 Web 服务器,并且与任何一台 Web 服务器的每次交互都会被复制,从而实现无缝交互。

In the context of Tomcat, can session replication takes place without enabling sticky session?

I understand the purpose of sticky session is to have the client 'sticks' to 1 server throughout the session. With session replication, the client's interaction with the server is replicated throughout the cluster (many web servers).

In the above case, can session replication takes place? i.e. client's session is spread though out the web servers and each interaction with any one web server is replicated across, thus, allowing seamless interaction.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

生生漫 2025-01-13 21:44:58

AFAIK,tomcat集群不支持非粘性会话。来自 tomcat 文档

确保您的负载均衡器配置为粘性会话
模式。

但是有一个解决方案(我创建的,所以你知道我有偏见:-))称为 memcached-session-manager (msm),也支持非粘性会话。 msm 使用 memcached (或任何使用 memcached 协议的后端)作为会话备份/存储的后端。

在非粘性模式下,会话仅存储在 memcached 中,不再存储在 tomcat 中,与非粘性会话一样,会话存储必须是外部的(以避免数据过时)。

它还支持会话锁定:对于非粘性会话,多个并行请求可能会命中不同的 tomcat,并且可能会并行修改会话,因此某些会话更改可能会被其他会话覆盖。会话锁定允许同步发送到不同 tomcat 的并行请求。

msm 主页 主要描述了粘性会话方法(因为它是这样开始的)仅),有关非粘性会话的详细信息,您可以在邮件列表。

有关配置的详细信息和示例可以在 msm wiki (SetupAndConfiguration)< /a>.

只是为了让您了解复杂性:您需要的是一个或多个正在运行的 memcached 服务器(或某些服务器)。类似的memcached)和更新的tomcat context.xml,如下所示:

<Context>
  ...
  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:host1.domain.com:11211,n2:host2.domain.com:11211"
    sticky="false"
    sessionBackupAsync="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
    />
</Context>

您的负载平衡器不需要特殊配置,因此一旦您准备好这些东西,您就可以开始测试您的应用程序。

AFAIK, tomcat clustering does not support non-sticky sessions. From tomcat docs:

Make sure that your loadbalancer is configured for sticky session
mode.

But there's a solution (I created, so you know I'm biased :-)) called memcached-session-manager (msm), that also supports non-sticky sessions. msm uses memcached (or any backend speaking the memcached protocol) as backend for session backup/storage.

In non-sticky mode sessions are only stored in memcached and no longer in tomcat, as with non-sticky sessions the session-store must be external (to avoid stale data).

It also supports session locking: with non-sticky sessions multiple, parallel requests may hit different tomcats and could modify the session in parallel, so that some of the session changes might get overwritten by others. Session locking allows synchronization of parallel requests going to different tomcats.

The msm home page mainly describes the sticky session approach (as it started with this only), for details regarding non-sticky sessions you might search or ask on the mailing list.

Details and examples regarding the configuration can be found in the msm wiki (SetupAndConfiguration).

Just to give you an idea regarding the complexity: what you need is one or more memcached servers running (or s.th. similar speaking memcached) and an updated tomcat context.xml like this:

<Context>
  ...
  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:host1.domain.com:11211,n2:host2.domain.com:11211"
    sticky="false"
    sessionBackupAsync="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
    />
</Context>

Your load-balancer does not need special configuration, so once you have these things in place you can start testing your application.

浊酒尽余欢 2025-01-13 21:44:58

关于此主题的精彩文章如下:

他们提到的 terracotta 产品在这里有一个简单的教程:

Terracotta 在 Tomcat 上工作,但你必须注意检查 Terracotta 的哪些部分是免费的,哪些是商业的。几年前,他们的冗余商店得到了支付,我不记得这个解决方案是一个单独的产品。

An excellent article about this topic here:

The terracotta product they mention has a simplistic tutorial here:

Terracotta works on Tomcat but you must pay attention to check which bits of Terracotta are free and which are commercial. A couple of years ago their redundant store was paid and I don't remember this solution being a separated product.

家住魔仙堡 2025-01-13 21:44:58

我实际上找到了这个问题的反面。对我来说,带有 OOTB 选项的会话复制 (Tomcat7) 只能在没有粘性会话的情况下正常工作。打开日志记录后,我发现启用 JVMRoutes 后,我的会话 ID 从 A123456789 变为 A123456789.01 —— 后缀为 jvmroute。该会话已成功从集群中的节点 01 复制到节点 02,但使用相同的 ID (A123456789.01)。当我将节点 01 从集群中取出时,流量开始滞留在节点 02 上 - 现在它会查找会话 A123456789.02,当然该会话并不存在。 .01 存在,但基本上闲置直到过期。如果我启动另一台服务器并复制会话,然后关闭 02,我会得到更奇怪的行为,因为会话会从中断处继续。

对我来说,到目前为止,没有粘性会话的会话复制(只是集群中节点之间的常规 RR)是唯一有效的方法。

I have actually found the inverse to this question. Session replication for me (Tomcat7) with the OOTB options only works properly WITHOUT Sticky Session. After turning the logging up I found that with the JVMRoutes enabled my session ID goes from A123456789 to A123456789.01 -- suffixed with the jvmroute. That session is successfully replicated from Node 01 in the cluster to Node 02 but uses the same ID (A123456789.01). When I take Node 01 out of the cluster then the traffic starts to stick on Node 02 -- and it looks now for a session A123456789.02 which of course does not exist. .01 is there, but basically sits idle until it expires. If I bring the other server up and the sessions are replicated and then take 02 down, I get even odder behaviour because the session is picked up where it left off.

For me, so far, session replication without sticky sessions (just regular RR amongst the nodes in the cluster) is the only thing that has worked.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文