問題タブ [azure-servicebus-queues]

ASP.NET MVC Web サイトで Facebook のような通知システムを作成しようとしています。

シナリオでは、通知システムは次のように機能します

1. User1 は、MVC サイトのフォロー ボタンをクリックして User2 をフォローします。
2. MVC サイトはAPI リクエストを介してNotificationItemに送信します。NotificationManager

POST api/通知/送信

3. NotificationManager次に、この notificationItem を処理してから、Azure テーブル ストレージに保存します

4. NotificationHub項目を保存した後、クライアント (User2) は(SignalR ハブ)を介して notificationEvent をサブスクライブします。

5. NotificationHub次に、処理された通知データとともに User2 に通知します。

この画像の現在のプロセスとアーキテクチャを説明しようとしました

さて、私を悩ませているのは、ステップ番号5のこのコード行です

背後で行うことはnotificationItem、ストレージからクエリを実行し、それを処理してユーザーが読み取り可能な通知 (ei. "User1 is now follow you") を処理し、notificationItem(IsSent、DateSent) のステータスを更新します。

言うまでもなく、なんとなく「重い」動作をします。また、各サブスクライバーに配信またはブロードキャストする新しい NotificationItem があるたびに、リアルタイムでトリガーされます。

明らかに、ここではパフォーマンスとスケーラビリティの問題について話しています。そこで、この問題を解決できる可能性のある技術またはアプローチを調査しました。そして、Azure Service Bus バックプレーン アプローチを使用することが実行可能なオプションのようです

Azure Service Bus を使用した SignalR スケールアウト

SignalR でのスケールアウトの概要

特定の段落で、このアプローチのいくつかの制限について説明しています

サーバー ブロードキャスト (例: 株価情報): サーバーがメッセージの送信速度を制御するため、バックプレーンはこのシナリオに適しています。

クライアントからクライアントへ (例: チャット): このシナリオでは、メッセージの数がクライアントの数に比例する場合、バックプレーンがボトルネックになる可能性があります。つまり、より多くのクライアントが参加するにつれて、メッセージの速度が比例して増加する場合

高頻度のリアルタイム (リアルタイム ゲームなど): このシナリオでは、バックプレーンは推奨されません。

さて、私の場合のように、これは私に考えさせました。Server Broadcast と Client to Client (およびその間の何か) は、私が達成しようとしていることに適用できます。

これらは、私が現在取り組んでいる通知イベントのシナリオ (およびその受け入れ基準) です。

1. ユーザーに新しいフォロワーを通知する(リアルタイムまたはほぼリアルタイムの通知)
2. チャット メッセージ(リアルタイム、チャット者が現在入力しているかどうかを確認します)
3. ステータスを投稿する(リアルタイムまたはほぼリアルタイム)
4. 投稿にコメントする(リアルタイムで、おしゃべりが現在入力しているかどうかを確認できます)

何時間も考えた後 - 今頭にあるのは（経験不足の結果として）このような通知システムです

お気づきのとおり、これは現在のデザインとは大きく異なります。現在の設計では、Azure Webrole を 1 つだけ使用します。

これにwebroleは、Web サイト用の 、ハブ用の webrole、および通知データを処理するための worker ロールがあります。したがって、「負荷」を3つの異なる役割に分散し、可能性を開くscaling-out.

今、これが私の頭の中での質問です。

1. このアーキテクチャは、私が達成しようとしているものに適していますか?
2. 通知はキューにあるので、これで「リアルタイム」の通知更新を実現できますか?
3. SignalR ハブを別の Web ロールに分離したので、承認をどのように処理するのでしょうか?
4. サービス バス キューですか、それとも Azure キューですか?

どんな助けでも大歓迎です。

注: このプロジェクトは実際には Azure および .NET 指向であるため、Azure テクノロジのみを使用するつもりです。

Azure には、受け取るバッチ アイテムに関して何らかの制限がありますか? 次のコードは、さらに要求されたにもかかわらず、450 件のメッセージしか取得していません。

回数を増やしてみましたが、影響はありません。毎回 450 回です。これは、バッチ受信の Azure SDK ドキュメントで推奨されている方法のようです。

注: キューには何万ものアイテムがあります。

Azure キューに接続された 2 つのコンシューマー (異なるアプリケーション) があります。私は、ReceiveAndDeleteまたはPeekLockメッセージを受け取ることができ、消費中はメッセージを受け取ることができます。参照: http://msdn.microsoft.com/en-us/library/azure/hh851750.aspx。complete()abandon()

両方のアプリケーションでメッセージを受信したいので、メッセージを使用PeekLockしてからメッセージを使用したいと確信しています。abandon()削除メカニズムとして、キューのメッセージの有効期間を 10 秒に設定することにしました。

ただし、メッセージは 10 秒後に削除されるように見えるため、この 10 秒間、メッセージは両方のアプリケーションで何度も公開され続けます。カスタム重複検出を作成する必要がありますか、それとも一般的に間違ったアプローチを使用していますか?

特定のメッセージのパブリッシャーをコンシューマーから分離するためのキューベースのシステムを設計しています。追加の要件があります - パブリッシャーが新しいメッセージをプッシュし、同様の種類の以前のメッセージが既にキューにあり、まだ処理されていない (つまり、コンシューマーによって選択された) 場合、新しいメッセージの前に古いメッセージを重複排除する必要があります。メッセージがキューにプッシュされます。これは、時代遅れになっていることがわかっているメッセージの処理コストを節約するためです。私は、そのようなキューを実装するために使用されるテクノロジを調査しています。Azure サービス バスはオプションですか? キュー内の特定のメッセージの属性を変更できますか? また、そのようなキューを実装するのに最適なテクノロジについて何か提案はありますか?

MessageReceiver の ReceiveBatch メソッドを使用して、ServiceBus からバッチでメッセージを受信しようとしています。

Service Bus Explorer を使用して、キューに 20 個のメッセージが含まれていることを確認しました。

このコードは、messages 構造体で 1 つのメッセージのみを返します。不足しているプロパティはありますか？

サブスクリプション モデルがあり、新しい請求書の発行、電子メールの送信などの更新関連のロジックを実行したいと考えています。たとえば、ユーザーは今日サブスクリプションを購入し、更新は 1 年後に行われます。最近、Azure キューを使用していますが、このような更新に適用されると思います。

このような長期のスケジュールされたメッセージに対して BrokeredMessage.ScheduledEnqueueTimeUtc( http://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage.scheduledenqueuetimeutc.aspx )を使用してメッセージをプッシュすることにより、Azure Queue を使用することは可能ですか?

1分で通知を送信するなど、短期間で使用しましたが、うまく機能します。

このようにして、複数のプロセスでキューをリッスンし、更新ロジックを実行するプロセスが 1 つだけであることを確認できます。これは、リースおよび関連機能を介して Azure Queue に組み込まれているため、ロックに関連する多くの問題を解決します。

Azure Service Bus キューに受信できないメッセージがあります。そして、問題が何であるかについての指標が得られません。メッセージサイズと関係があると思います。以下のコードから、私が OpenFileDialog を使用していることがわかります。jpeg 画像を選択していますが、それらはキューに送信されています。現在、約 50KB 未満の小さな画像を送信すると、受信プロセスによって正常に表示されますが、100KB を超える大きな画像はキューに留まっています。MSDN によると、メッセージ サイズの制限は 256 KB であり、ここで何が起こっているのかわかりません。

私は2つのクラスを持っています。1 つは SendToQueue で、もう 1 つは RecvFromQueue です。これがコードです。

カスタム ビルドのスパウト Java コードを使用して、Apache Storm クラスターを介して Azure Service Bus (ASB) からメッセージを読み取ろうとしています。クラスター モードで実行するためにストーム トポロジを送信すると、次の問題に直面します。

• サービスまたはプロパティが登録されていません: com.microsoft.windowsazure.services.servicebus.ServiceBusContract クラス com.sun.jersey.api.client.Client
• Azure Service Bus コネクタを追加できません
• サービスのセットアップに失敗しました。
• 非同期ループが死んだ!

同じトポロジがローカル モード (クラスターなし) で送信されると、同じコードが正常に機能し、ASB からメッセージを受信できます。

Java 環境から ASB にアクセスし、この問題を解決できるときに、誰かが同様の問題に直面しましたか?