5

私は現在、単純な古いテーブル (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 つのプロセッサを使用することについて議論することでした。

4

4 に答える 4

5

このトピックの詳細については、テーブルをキューとして使用するを参照してください。問題は、「キュー」にアクセスする方法だけでなく、インデックスを作成する方法でもあります。クラスター化されたインデックスでは、次の行を直接シークしてデキューできるようにする必要があります。そうしないと、常にデッドロックが発生します。

プロセッサを同じキューに競合させたい場合、異なるキューに分散することによる負荷分散はアンチパターンです。これは、遅いプロセッサの後ろにアイテムがキューに入れられている場合に、コンボイと人為的な待ち時間につながりますが、キューが空であるため、他のプロセッサは空いていてアイドル状態です。

于 2011-05-04T19:39:19.820 に答える
1

S.Lott が述べたように、使用できるメッセージ キュー メカニズムがあります。MSMQ は Windows Azure ではあまり役に立ちませんが、Windows Azure には既に耐久性のあるキュー メカニズムがあります。各 worker ロール インスタンスを簡単に設定して、1 つ (または複数) のキュー アイテムを読み取ることができます。キュー アイテムが読み取られると、指定した時間 (時間が指定されていない場合は 30 秒) の間 "非表示" になります。キュー メッセージは最大 8K で、"耐久性がある" と見なされます。すべての Azure ストレージは (SQL Azure と同様に) 最低 3 回レプリケートされます。

gbn が説明するようなものを実装することはできますが、Windows Azure で作業する場合は、ネイティブの Azure キュー サービスを検討する必要があると思います。複数のキュー コンシューマーに簡単にスケーリングでき、同時実行性や特別な負荷分散コードについて心配する必要はありません。インスタンス数を増やす (または減らす) だけです。

Windows Azure キューの詳細については、Azure プラットフォーム トレーニング キットを参照してください。キューの基本について説明する簡単なラボがいくつかあります。

于 2011-05-04T19:14:02.223 に答える
1

キューとしてのテーブルは非常に簡単に実行できます。ここで私のSOの回答を参照してください: SQL Server Process Queue Race Condition

于 2011-05-04T18:49:22.797 に答える
0

あなたが見逃している点は、キューを使用するときの重要なポイントの 1 つは、注文が保存され、キューに入ると何が起こっても失われないということです。

現在、ポーラー プロセスは停止する可能性があります。さまざまな問題が発生している可能性がありますが、気にする必要はありません。キューは注文が安全な場所です。

ポーラーは、同じレベルの堅牢性を必要としません。たとえば、 Postfixは、メッセージ キューが多くのレベルで使用されるメール トランスポータの非常に安全な実装です (異なるセキュリティ レベルを必要とするアプリケーション内の各サブシステムは、キューを使用して他のサブシステムと通信します)。郵便物を紛失した場合、労働者は非常にひどく死ぬ可能性がありますが、郵便物はそうではありません。

編集

つまり、基本的な使用法は注文を保存することであり、ワーカーがそれに対して何をするか、まだ生きているワーカーの数などを無視することです。したがって、複数のキューを処理する唯一の理由は、注文 (アプリケーション ロジック) の複数の宛先を管理することです。労働者が彼らと一緒に働く方法を管理しないこと (デカップリング)。

于 2011-05-04T19:24:20.763 に答える