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

Question

我有一个使用 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 以成功通过握手过程？

Answer 1

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

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

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

在握手后，well written CometD 应用程序将订阅（甚至是dynamic subscriptions）所有需要的频道，并最终恢复到与以前一样的功能，几乎是透明的。

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

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

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

您还想了解 CometD 的内存中 clustering features。