問題タブ [azure-queues]

メッセージがAzureキューに入れられるたびにイベントが発生する、イベント駆動型のAzureキューを構築しようとしています。AzureXplorerを使用すると、メッセージはAzureキューに適切に配置されますが、CloudQueueClient.ResponseReceivedイベントは発生しません。AzureV1.4を使用しています。これは私のワーカーロールからのコードです：

いくつかの調査のために Azure ベースのプロジェクトに取り組んでおり、CloudQueue インスタンスからメッセージを削除するときにいくつかの問題が発生しています。コードは非常に単純なので、キューからメッセージを削除しようとすると例外がスローされる理由が少しわかりません。

キューのデータを生成するコードは次のとおりです。

キューからデータを消費するコードは次のとおりです。

メッセージがキューに存在できない理由がわかりません。他の消費者以外にキューを変更しているものはありません。しかし、彼らは同じメッセージを受け取ることができないと確信しています (タイムスパンが切れない限り)。

キューが実際のAzureストレージを指す非常に単純なテストを行っていますが、理由はわかりません。コンピューターからテストを実行する方が、ワーカーの役割をazureにデプロイしてそこで実行するよりもはるかに高速です。ローカルでテストするときにDevStorageを使用していません。私の.cscfgには、実ストレージへの接続文字列が含まれています。

ストレージアカウントとロールは同じアフィニティグループにあります。

テストは、Webの役割とワーカーの役割です。このページは、実行するテストをワーカーに通知し、ワーカーはそれを実行して、消費した時間を返します。この特定のテストでは、32個のメッセージのバッチを使用してAzureキューから1000個のメッセージを取得するのにかかる時間を測定します。まず、アプリをAzureにデプロイしてそこから実行した後、VSでデバッグの実行をテストします。

結果は次のとおりです。

• 私のコンピューターから：34805.6495ミリ秒。
• Azureの役割から：7956828.2851ミリ秒。

つまり、Azureの内部よりも外部からキューにアクセスする方が高速であり、意味がありません。

私はこのようにテストしています：

は、1000個のPreTestExecuteアイテムをそれぞれ2048バイトでキューに入れます。

そして、これはItemTestこのテストのメソッドで起こることです：

私は間違っていること、同じコード、同じ接続文字列ではなく、これらの結果を得ました。

何か案が？

アップデート：

問題は私がそれを計算する方法にあるようです。

times.Add(sw.ElapsedTicks);fortimes.Add(sw.ElapsedMilliseconds);とこのブロックを置き換えました：

これのために：

そして今、結果は似ているので、どうやら精度の扱い方などに違いがあるようです。これについては後で調べます。

私は現在、単純な古いテーブル (SQL Server Service Broker ではありません) を使用して SQL Server Azure データベースにイベントが格納される分散型イベント ベース システムのリファレンス アーキテクチャをまとめているところです。

イベントは、新しいイベント メッセージのキューをポーリングするワーカー ロールを使用して処理されます。

私の調査では、複数のプロセッサがキューからメッセージを処理できるようにする解決策がいくつか見られます。私が見ている多くのパターンで私が抱えている問題は、複数のプロセスが単一のメッセージキューにアクセスしようとしているときに、ロックの管理などの複雑さが増すことです。

従来のキュー パターンでは、複数のプロセッサが 1 つのキューからプルすることを理解しています。ただし、イベント メッセージを任意の順序で処理できると仮定すると、キューとそのキュー プロセッサの間に 1 対 1 の関係を作成し、異なるキュー間で負荷を分散するだけの理由はないでしょうか?

queue_1 => processor_1
queue_2 => processor_2

この実装により、複数のプロセッサ間でキューへの同時アクセスを管理するために必要なすべての配管が回避されます。イベント パブリッシャーは、任意の負荷分散アルゴリズムを使用して、メッセージをパブリッシュするキューを決定できます。

私の検索でこの種の実装が見られないという事実は、この設計の大きな欠点を見落としていると思います。

編集

この投稿は、データベース テーブルをキューとして使用するか、MSMQ や Azure Queues などとして使用するかについて議論を引き起こしました。Azure AppFabric の持続的メッセージ バッファーを含め、利用可能なネイティブ キューイング オプションが多数あることは理解しています。オプションを評価した結果、SQL Azure テーブルで十分であると判断しました。私の質問の意図は、単一のキューに対して複数のプロセッサを使用することと、キューごとに 1 つのプロセッサを使用することについて議論することでした。

私にはスターターワーカーがいます。いくつかの初期化を行います。他のワーカーにこのスターター ワーカーを待ってもらいたい。私が考えている唯一の方法は、メッセージをキューに入れることです。ワーカーはキューをポーリングします。メッセージを読んだ後に開始します。同期するためのより良い方法はありますか?

Azure CloudBlobClient、CloudQueueClient、CloudBlobクラスのスレッドセーフを理解するのに助けが必要です。

私は、複数の独立したジョブプロセッサを含むワーカーロールを開発しています。これらの各ジョブプロセッサは、特定のキューから読み取り、同じである可能性のあるいくつかのBLOBコンテナーに書き込み/更新します。

これらのジョブプロセッサがお互いに足を踏み入れていないことを確認したいと思います。

1>ロックを使用せずにこれが当てはまるかどうかを確認するにはどうすればよいですか？個別のCloudBlobClientとCloudQueueClientを各ジョブプロセッサ（すべて同じプロセス内に存在する）に割り当てる場合、それらは互いに独立しており、すべてのジョブプロセッサが個別のクライアントインスタンスを使用するため、実行されません。お互いにまったく？

2>同じジョブプロセッサ内で、Parallel.ForEachを使用してCloudBlobClientで並列処理を実行しようとすると、GetBlobReferenceまたはUploadTextを並列に呼び出す必要がありますか、それともこれらのメソッドはスレッドセーフですか？Azureのドキュメントには、そうではないと書かれていますが、オンラインで見たほとんどの例では、これらのメソッドに同期メカニズムを適用していないようです。これを達成するための最良の方法は何ですか？1つのCloudBlobClientを使用して、GetBlobReferenceまたはUploadTextを並行して呼び出す最良の方法を意味しますか？

複数のスレッドを開始できる Azure ワーカー ロールを実装する予定です。各スレッドは、ストレージ キューに対して読み取りまたは書き込みを行う場合があります。異なるワーカー ロール インスタンスでは、競合状況は当てはまりません。しかし、同じ worker ロール内で実行されている異なるスレッドから同じキューに同時にアクセスしても安全ですか?

キューにメッセージを何度も挿入しないようにしたいと思います。一意性を強制するために使用できるID/名前はありますか？

Azureキューからxmlメッセージを取得する既存のワークフローエンジンがあります。XMLピースには、実行されたワークフローアクションに関する情報が含まれています。この情報は、実際のワークフロークラスに渡されて処理されます。

たとえば、ワークフロークラスには次の手順がありますA。

ステップ1->ステップ2->ステップ3

Step 2はの前提条件ですが、はのStep 3要件Step 1ですStep 2。

したがって、エンジンからactionAというメッセージを受信すると、その特定のインスタンスに対して完了とマークされ、に進みます。WaitforStep1Step 1Step 2

WaitforStep2今私の問題は次のとおりです。の代わりに情報を含むメッセージを受信したWaitforStep1場合、インスタンスはを通過せずに直接ジャンプします。Step 3Step 2

これを防ぐ方法はありますか？

免責事項：私はWFの初心者です。

MSDNによると、メッセージ ペイロードは最大 8KB (8192 バイト) まで拡張される場合があります。

AddMessage メソッドは、メッセージをキューの最後に追加します。メッセージのサイズは最大 8 KB です。その内容は、UTF-8 でエンコードできる形式である必要があります。

ただし、キューにメッセージを追加すると、ペイロードが 8192 バイト未満である必要があるメッセージの例外を受け取ります。魔法の領域は約 6500 バイトのようです。私が送信しているデータは純粋な文字列であり、そのサイズは、.Lengthメンバーと、それらが取得されたソースによって送信された長さの両方から検証されます (CRLF 区切り文字には一定の 2 バイトの違いがあります)。

私の質問は2つあります：

1) メッセージ ペイロードに追加された隠しデータによって、サイズが膨張したり、このような奇妙な動作が発生したりすることはありますか? (ペイロードだけでなく、オブジェクト全体に適用される制限など、しかし、それでも、メッセージごとに 1.5KB をどのように説明できるでしょうか?)

2)ペイロードが実際に 8192 未満であることを確実に確認するにはどうすればよいですか?

いくつかの追加情報: 私は VS 2010 Ultimate で Azure SDK 1.4 を使用しており、SQLExpress (2008 だと思います) を使用してコンピューティング エミュレーターとストレージ エミュレーター (まだこのアプリを展開していません) を実行しています。

また、最大サイズが 8192 バイトであることをコードで確認しました (追加のシステム制限が課された場合)。

CloudQueueMessage: 最大キュー メッセージ サイズ: 8192