さまざまな種類の通知を持つアプリケーションを開発しています。通知の例:
- メッセージが作成されました
- 提出されたリスト
- 上場承認
接続されているクライアントがリアルタイムで更新を取得できるように、これらすべてを SignalR に結び付けたいと思います。
アーキテクチャに関する限り、現在、アプリケーションは完全に Azure Web サイトでホストされている単一のソリューション内にあります。これらの各通知タイプのトリガーは、このアプリケーション内に存在します。
トリガーがヒットしたら、signalR に「このメッセージを次のクライアントに送信してください」と、userId のリストとともに伝えたいと思います。userId に基づいて接続されたクライアントを識別することは可能であると想定しています...そしてsend message to clients、MVC アプリの速度を低下させたり、データを失うリスクを冒したりしないように、プロセスは Web アプリケーションの外部で実行する必要があると想定しています壊れた非同期呼び出し。最初の質問 -これらの仮定は正しいですか?
そう仮定すると、これは、クライアントにメッセージを送信するための専用の Web/worker ロールのようなものが必要になることを意味します。Web アプリケーションからこのプロセスにメッセージを直接渡すことはできますが、プロセスが停止するとどうなりますか? 回復力に関する懸念から、メッセージを渡す適切な方法は、ある種のキューを介することであると私は信じています。2 番目の質問 -これは有効な一連の思考ですか?
そう仮定すると、これは古き良き Azure SQL データベースをキューとして使用できることを意味しますが、次のようなメッセージ キューイングを処理するための特殊な (そしておそらく安価な) サービスがいくつかあるようです。
http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/
3 番目の質問:これを signalR のキューイング メカニズムとして使用する必要がありますか? 将来、キャッシュに Redis を使用することに興味があります... Redis はキュー サービスよりも優れていますか?
最後の質問:
ここで提案したアーキテクチャを説明しようとしました。
ここで最も不明なのは、MVC アプリがキューに入れるタイミングを知る方法、または SignalR プロセスがブロードキャストするタイミングを知る方法です。接続されているクライアントを気にせずに、MVC アプリをやみくもにキューに入れる必要がありますか? これにより、キューに大量の無駄なスペースが発生し、worker ロールに無駄なサイクルが発生するようです。これは、接続されるクライアントの割合が非常に少ないためです。
私が考えることができる唯一の他のアプローチは、MVC アプリに SignalR プロセスへの可視性を与えて、クライアントが接続されているかどうかを確認することです...接続されている場合は、エンキューします。これは、トリガーがヒットするたびにダイアグラムの赤い線をヒットしなければならないことを意味するため、私は不快に感じます.
スケーラブルでパフォーマンスの高い SignalR メッセージ ブロードキャストに推奨されるアーキテクチャは何ですか? パフォーマンスが最優先事項であり、そのすぐ後にコストが続きます。
おまけの質問:
- 一部のメッセージが他のメッセージよりも優先度が高い場合はどうなりますか? 2 つのキューを使用し、一方が常に他方より先にチェックされるようにする必要がありますか?