Azureキュー - 機能 - メッセージの可視性 - 作業者？

Question

Azureのキュー、機能、および作業者に関する機能に関するいくつかの質問があります。私はこれがどのように機能するかは分かりません。

シナリオ：

• Q-通知Azureのストレージアカウントでキューです。
• f-process-notificationは、q-notificationsにバインドされているAzureの関数です。その仕事は、最初のメッセージをキューに入れて処理することです。

理論的には、q通知にメッセージが追加された場合、関数f-process-notificationを呼び出す必要があります。

質問：

1. トリガーされた機能は、労働者を持っている必要がありますを交換していますか？つまり、メッセージがキューに置かれるたびにf-process-notificationが呼び出されます。

2. キューに、可視性タイムアウトが5分のメッセージを配置するとします。基本的に私はメッセージをキューに入れていますが、5分経過するまではそのメッセージを処理すべきではありません。キューは、メッセージがキューに置かれた直後にf-process-notificationをトリガーするか、またはメッセージが表示されたとき、つまりキューに置かれてから5分後にf-process-notificationをトリガーするだけですか？

Answer 1

Azure関数では、キューでトリガーされた関数を実行している各関数Appインスタンスは、ターゲットキューに対して独自のリスナーを持ちます。指数バックオフ戦略を使用してキューを監視して新しい作業を監視します。新しいアイテムがキューに追加されると、リスナーは複数のアイテムをキューから取り除き（バッチ処理は設定可能です）、を並列ににディスパッチします。あなたの関数が成功すると、メッセージは削除されます。そうでなければ、キューに残って再処理されます。あなたの質問に答える - はい我々はいずれかを尊重視界のタイムアウトあなたが指定します。 5分のタイムアウトでメッセージが追加された場合は、その後に処理されます。

スケールアウトについて - 機能アプリケーションのN個のインスタンスが実行されている場合、それらはすべてキューの処理に協力します。各キュー・リスナーは、一括してバッチを取り出して処理します。実際には、作業はN個のインスタンスにわたって負荷分散されます。正確にあなたが望むもの:) Azure関数は、あなたのために複数の消費者/作業者パターンのすべての複雑さを舞台裏で実装しています。

Answer 2

私は通常、トリガーではなくリスナーロジックを使用します。コンシューマは、メッセージのキューを常に監視しています。同じバス/キューを処理している、異なるAzureワーカーロール内の消費コードのインスタンスが5つの場合など、複数のコンシューマがある場合、メッセージを受け取る最初のコンシューマが勝ちます（競合しています）。これにより、SOAアーキテクチャでよく見られるスケーリングのシナリオが提供されます。

この記事では、処理を延期するいくつかの方法について説明します。

http://markheath.net/post/defer-processing-azure-service-bus-message

幸運！