2

我正在尝试了解如何创建自己的 IMessageHub。我不想依赖任何额外的基础设施，而且消息数量很少。所以我决定使用一个简单的套接字解​​决方案来复制消息。我查看了不同 ScaleoutMessageBus 实现的源代码，但这些似乎需要一个额外的严格递增的标识符（例如，Redis 实现使用“INCR”）。有人可以确认是这种情况吗？一个随机标识符不会砍吗？

标识符是下面 OnRecieved 方法的第二个参数

 public abstract class ScaleoutMessageBus : MessageBus
     {
...
   protected virtual void OnReceived(int streamIndex, ulong id, ScaleoutMessage message)
4

1 回答 1

2

您是正确的，标识符应该严格增加。

这用于 SignalR 客户端可以拥有他们收到的最后一条消息的全局标识符。当 SignalR 客户端重新连接到另一台服务器时（这在长轮询传输中尤其常见），它们将此标识符传递给新服务器，以便它可以将重新连接的客户端从其内存缓存中丢失的任何消息发送。

如果标识符曾经减少，SignalR 将继续运行，但每个服务器将立即刷新其接收消息的内存缓存。这可能会导致重新连接的客户端丢失消息。

要了解 SignalR 需要以这种方式运行的原因，请考虑来自具有以下顺序的标识符的横向扩展提供程序的消息：

1, 2, 3, 1, 2, 3

然后假设客户端重新连接到另一个服务器，说它收到的最后一个标识符是“2”。服务器无法在不冒发送重复消息或丢失消息的风险的情况下响应消息。使用 SignalR 的设计方式，客户端不应收到重复消息，但会错过消息“3、1、2”。

于 2014-09-29T19:10:48.593 回答