没有多播的 tomcat 会话复制
我计划使用在托管提供商处租用的 2 台专用根服务器。 这些机器将在集群中运行 tomcat 6。 如果我稍后添加其他计算机 - 它们不太可能通过多播访问，因为它们将位于不同的子网中。
是否可以在没有多播的情况下运行tomcat？ tomcat 6 集群的所有教程都包含多播心跳。 有 SimpleTcpCluster 的替代方案吗？
或者在这种情况下其他选择更合适？
i am planning to use 2 dedicated root servers rented at a hosting provider. those machines will run tomcat 6 in a cluster.
if i will add additional machines later on - it is unlikely that they will be accessible with multicast, because they will be located in different subnets.
is it possible to run tomcat without multicast? all tutorials for tomcat 6 clustering include multicast heartbeat. are there any alternatives to SimpleTcpCluster?
or are other alternatives more appropriate in this situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
由于无法控制两台服务器之间的距离（它们可能位于两个不同的数据中心）并且没有专用的服务器间通信线路，我宁愿通过循环 DNS 或将客户端重定向到 www1.yourdomain 的负载均衡器来运行它们.xxx 或 www2.yourdomain.xxx 并仔细处理服务器通信。
如果服务器彼此频繁通信，您可能会考虑更改架构，优化应用程序以“适合”一台服务器（至少一段时间），或者选择可控制位置的专用托管，服务器的距离和布线。 否则，您的服务器间通信、心跳等将使用与其通信的客户端相同的通道（例如相同的网段），这可能会减慢每个人的速度。
如果你真的期望那么大的负载，我想至少涉及一些钱，不是吗？ 明智地使用它，并利用您的设置技能来解决比在没有控制或专用线路的情况下设置分布式集群更困难的问题。
With no control over the distance between both servers (they might be in two different datacenters) and no dedicated inter-server-communication line, I'd rather run them via round-robin DNS or a loadbalancer that redirects clients to either www1.yourdomain.xxx or www2.yourdomain.xxx and handle server-communication carefully.
If the servers are heavily communicating with each other you might either look to change your architecture, optimize the hell out of your application to "fit" on one server (at least for a while) or go for dedicated hosting with control over the location, distance and cabling of your servers. Otherwise your inter-server-communication, heartbeat etc. would use the same channel as the clients that are communicating with it (e.g. the same network segment) which might slow everyone down.
If you are really expecting that much load I suppose there's at least some money involved, no? Use it wisely and use your setup skills for problems harder than setting up distributed clustering with no control or dedicated lines.
在给出我的其他答案后看到对该问题的评论，我对你的问题是什么感到困惑......是关于会话复制吗？ 集群通信？ 最好陈述您的问题，而不是您计划的本身存在问题的解决方案。
我将陈述一些可能的问题以及快速答案：
您的应用程序是 CPU/RAM 密集型的
带宽密集型
您的应用程序是存储密集型的，
您的应用程序很可能要
您只需要会话复制？
更多想法
我当然忘记了一些事情，但这可能提供一些起点。 更具体地了解潜在问题的性质，以获得更好的答案:)
Seeing the comment to the question after having given my other answer I'm puzzled about what your question is... Is it about session replication? Cluster communication? It might be better to state your problem instead of your planned solution that has problems itself.
I'll state some possible problems together with quick answers:
Your application is CPU/RAM intensive
Your application is bandwidth intensive
Your application is storage intensive
Your application is likely to be slashdotted
You just need session replication?
More ideas
I certainly have forgotten something, but this might provide some starting point. Be more concrete about the nature of your underlying problem to get better answers :)
我正在尝试部署耶鲁中央身份验证服务器（CAS），并且希望将其集群化以实现冗余，因为这是基础设施的关键部分。 CAS 要求复制会话，因为在用户登录应用程序 A 并导航到参与单点登录域的应用程序 B 后，应用程序 B 会向 CAS 发送请求以确定用户是否拥有活动“票证” 。 由于没有设备向应用程序 B 指示它应将自身寻址到哪个节点来验证票证，因此必须将一个节点中的所有活动票证复制到集群中的所有节点。 换句话说，会话粘性在这里不是一个解决方案，因为应用程序 B 在验证用户 cookie 中的票证时，不知道用户登录期间应用程序 A 中原始会话的 sessionId。
因此，CAS 要求会话将在所有节点上复制。 网络支持多播的要求增加了相当大的开销，并使这种方法的部署有点繁重。 我在谷歌代码上测试了这个项目：
http://code.google.com/p/memcached -session-manager
看起来非常有用且易于部署（至少在 Linux 操作系统上），但不幸的是仅提供会话故障转移，而不是会话复制解决方案。
I am attempting to deploy the yale Central Authentication Server (CAS) and I would like to cluster it for redundancy, because this is a critical piece of infrastructure. CAS requires that the session be replicated, because after a user logs in application A and navigates to application B that partakes in the single-sign-on domain, application B sends a request to CAS to determine whether the user has an active 'ticket'. Since there is no device to indicate to application B to which node it should address itself to validate the ticket, all the active tickets in one node must be replicated to all nodes in the cluster. In other words, session stickiness is not a solution here, because application B, when validating the ticket in the user's cookie, is not aware of the sessionId of the original session in application A during which the user logged in.
Thus, CAS requires that the session be replicated across all nodes. The requirement that the network support multicasting adds a non-trivial amount of overhead, and makes this approach a bit heavier to deploy. I tested this project at google code:
http://code.google.com/p/memcached-session-manager
which seems very useful and simple to deploy (at least on a linux OS), but unfortunately only provides for session failover, and is not a session replication solution.
只需使用 http://code.google.com/p/memcached-session-manager/ 。 效果很好。 我们多年来一直使用它来进行 20 个 Tomcat 服务器共享会话的设置。 您可以使用一台或两台 Memcached 服务器来处理会话复制。
Just use http://code.google.com/p/memcached-session-manager/ . It works great. We are using it for years for this setup with 20 Tomcat servers sharing sessions. You can have one or two memcached servers to handle the session replication.