时间戳

首页 > 解决方案 > CometD 故障转移能力 - 重启期间的 VM 切换

virtual-machine - CometD 故障转移能力 - 重启期间的 VM 切换

问题描述

我有一个使用 CometD 的聊天实现。

在前端，我有一个客户端，它的 clientId=123 正在与 VirtualMachine-1

VirtualMachine-1 和 Client 之间的长轮询连接是通过 clientId 完成的。在握手期间建立连接时，VirtualMachine-1 将 123 clientId 注册为它自己的并接受它的数据。

出于某种原因，如果 VM-1 重新启动或失败。Client 和 VM-1 之间的长轮询连接断开（由于 VirtualMachine-1 已死，心跳会失败，因此会断开连接）。

在这种情况下，CometD loadBalancer 会将客户端通信重新路由到新的 VirtualMachine-2。但是，由于 VirtualMachine-2 具有不同的 clientId，它无法理解来自客户端的“123”。

我的问题是 - 在这种情况下，cometD 的行为是什么？它如何将流量从 VM-1 重新路由到新的 VM-2 以成功通过握手过程？

标签： virtual-machineclient-serverlong-pollingcometd

解决方案

当一个 CometD 客户端被负载均衡器重定向到第二台服务器时，第二台服务器并不知道这个客户端。

客户端将发送一条/meta/connect消息clientId=123，第二个服务器将回复一个402::unknown_session和advice: {reconnect: "handshake"}。

当收到重新握手的建议时，客户端将发送一条/meta/handshake消息，并clientId=456从第二台服务器获取一条新消息。

握手后，编写良好的CometD 应用程序将订阅（甚至是动态订阅）所有需要的频道，并最终恢复到与以前一样的功能，几乎是透明的。

在从一台服务器切换到另一台服务器期间发布到客户端的消息完全丢失：CometD 没有实现任何持久性功能。

然而，在客户端确认消息之前持久化消息是可能的：CometD 提供了许多由 CometD 实现调用的侦听器，通过这些侦听器，应用程序可以将消息（或其他信息）持久化到他们自己选择的持久化（并且可能是分布式的）中) 存储：Redis、RDBMS 等。

CometD 为您透明地处理重新连接 - 它只需要客户端和新服务器之间的一些消息。

您还想了解 CometD 的内存中集群功能。

推荐阅读