4

私のアプリケーションは、Webロールの複数のインスタンスを介して、毎秒1000以上のリクエスト/トランザクションを受信します。これらの役割は、複数のストレージテーブルにまたがるすべてのトランザクションのレコードを書き込みます（ランダムに、Azureの500トランザクション/秒の制限を分散します）。ここで、複数のワーカーロールを使用してこのデータを処理/集約し、結果をSQLデータベースに書き込むための信頼できる方法が必要です。別名、これは水平方向にスケーリングする必要があります。

後処理でストレージテーブル内のすべてのトランザクションを保持/アーカイブする必要があるので、キュー用のテーブルのセットを1つ用意し、それらが処理されたときにアーカイブテーブルに移動するか、おそらく次の方法があります。確かではありませんが、単一のテーブルでこれを行います。

これらのキュー内の現在のワークロードを作業ロール全体に分散するメカニズムに関して、何をお勧めしますか？明らかに、各ロールは他のすべてのロールが何に取り組んでいるかを認識している必要があるため、未請求のトランザクションでのみ機能します。各ロールは、単一の作業負荷としてキューから1000レコードを取得し、複数のワーカーロールが同じキューで動作する可能性があると思います。

ワーカーロールの「状態」をキャッシュ（おそらくSQLサーバー）に保持する必要があります。

あなたの提案は大歓迎です。

4

4 に答える 4

9

テーブル サービスを介してキューイングを実装しようとするのではなく、適切なキュー サービスを使用してこの機能を実装することをお勧めします。これにより、どのレコードが処理されたかを知るために複雑なロジックを実装する必要がなくなります (トランザクション機能が非常に限られている Table Storage などのサービスでは特に、フォールト トレランスとエラーの可能性を考慮するとロジックが難しくなります)。複数のワーカーを確実に調整し、考えられるすべての障害シナリオを考慮し、同時にスケーラブルであることは、アプリケーション レベルでは試みません。

例えば：

  1. Web ロールは、トランザクションを表す要求を受け取ります。
  2. Web ロールはデータを複数のテーブルに書き込みます。
  3. Web ロールは、一意の ID (別の適切な主キーがない場合は、要求 ID など) を持つトランザクションを表すメッセージをキュー サービスに送信します。
  4. worker ロールはキューからメッセージをプルします。
  5. メッセージごとに、worker ロールはメッセージの一意の識別子に対応するテーブル ストレージからオブジェクトのセットを取得します。
  6. worker ロールは、必要に応じてデータを集計し、SQL Database に書き込みます。

ノート：

  1. Queue Service (ストレージから) または Service Bus キューのいずれかを使用します。
  2. スケーラビリティのために多くのキューに負荷を分散します。
  3. 一時的な障害を考慮して、すべてのレベルで適切な処理を適用してください。
  4. 同じメッセージを複数回処理する可能性に対処します (処理は冪等でなければなりません)。
于 2013-02-20T00:39:20.380 に答える
1

私もフェルナンドに同意します。キュー サービス API の GetMessages メソッドを使用すると、指定した数のメッセージを 1 回のトランザクションでキューから取り出すことができます。デキュー ロジックが正しく実装されている場合、処理がべき等であることを心配する必要はないかもしれませんが、ソリューションはより堅牢になります。

于 2013-02-20T01:58:02.850 に答える
1

私はフェルナンドに同意します。このトピックに関する私のブログ投稿をご覧ください。これは、Azure キューの大規模な処理に関係しています。これは、投稿したものよりも高いスループット要件で行ったプロジェクトに基づいています。

于 2013-02-20T00:52:13.993 に答える