1

次のメッセージ転送シナリオがあります

クライアント->SignalRを呼び出します->NServiceBusを呼び出します->メッセージを内部的に処理します->結果を使用してNServiceBusゲートウェイサービスを呼び出します->SignalRハブを呼び出します->結果を使用してクライアントを更新します。

SignalRとロングポーリングのどちらを使用するかを選択する際には、SignalRがスケーラブルかどうかを知る必要があります。そのため、宿題をしているときに、AzureServiceBusでSignalRに出くわしました。セットアップは、Global.asaxアプリケーションの起動時に行われます。

最終的には、NServiceBusハンドラー内からこれを実行できる必要があります。

        var context = GlobalHost.ConnectionManager.GetHubContext<MyHub>();
        context.Clients.Group(group).addMessage(message);

問題は、クライアントが接続されていたマシンとは別のマシンから（潜在的に）呼び出しているため、コンテキストがジャックアップされるかどうかです。

また、SignalR実装がトピックをシードするために使用するシャーディングスキーマは何ですか？N個のトピックを使用するように設定できることはわかっていますが、実際にどのメッセージがどのトピックに送信されるか、および外部の発信者PoVからのメッセージに関連するかどうかをどのように判断しますか。

4

1 に答える 1

1

SignalRを介して登録しGlobalHost.ConnectionManager.GetHubContextたすべてのアプリケーションで使用できるはずです。これは、アプリケーションを呼び出す場合に行われます。ServiceBusMessageBusIMessageBusGlobalHost.DepenencyResolverGlobalHost.DepenencyResolver.UseServiceBus(...)

これを行うと、から返されaddMessageた他のハブメソッドへの呼び出しごとにメッセージがAzureServiceBusに公開されます。Webファーム内の他のノードに接続されているサブスクライブされたクライアントがある場合、他のノードはService Busからメッセージを取得し、サブスクライブされたクライアントに中継します。IHubContextGetHubContext

メッセージがどのトピックに送られるかは、外部の発信者のPoVからは関係がないはずです。複数のトピックを使用してスループットを向上させることができますが、ほとんどのユースケースでは1つで十分です。

複数のトピックを使用することを選択した場合、メッセージが送信されるトピックは本質的にランダムであると考えることができます。保証される唯一のことは、同じ送信者からのメッセージが同じトピックに送られることです。これにより、SignalRは同じ送信者からのメッセージを順番に保持できます。

警告： SignalRには、スケールアウトをサポートする公式リリースがまだありません。1.1バージョンは、正式にスケールアウトをサポートする最初のリリースになります。

于 2013-03-26T18:23:44.140 に答える