ウェブアプリケーションがより少ないインスタンスにスケールアウトされたときのAzureサービスバスメッセージ

Question

ウェブアプリケーションの4つのインスタンスと、サービスバスキューにキューイングされた多数のメッセージ（4つのインスタンスすべてに達することを意味する）わずか2つのインスタンスにスケールダウンします。削除された他の2つのインスタンスのために意図されたサービスバス内のメッセージは、存続時間が経過して削除されるまで待ち行列に滞留するか、サービスバスはそれ以上4つのインスタンスがないことを理解し、 4つのインスタンスにメッセージを送信する必要はありませんか？

これが正しいかどうかわかりませんが、私の理解からは通常トピックがあり、複数のサブスクリプションがありますか？ （サブスクリプションを持っている）インスタンスのいずれかがなくなったときにサービスバスが理解し、そのメッセージがキューに入れられている間にそのサブスクリプションのメッセージを削除します（それ以前の多くのメッセージ）。

申し訳ありません質問が少しばかだと私はインターネット上の任意の答えを見つけることができませんでした。

Answer 1

メッセージは、削除された他の2つのインスタンスのために意味されたサービス・バスでは、生存時間が超過するまでキューに保持し、その後

Service Busのキューに削除されますトピックサブスクリプションはデッドレターキュー（DLQ）と呼ばれるセカンダリサブキューを提供します。 デッドレターキューの目的は、受信者に配信できないメッセージ、または処理できなかったメッセージを保持することです。詳細はdocumentを参照してください。

サービスバスは、4つのインスタンスが存在しないことを理解しているため、4つのインスタンスにメッセージを送信する必要はありませんか？

サービスバスキューファーストインファーストアウト（FIFO）メッセージとサービスバスキューメッセージは、1つのメッセージコンシューマのみが受信して処理します。複数のWebインスタンスがある場合、クエストが到着すると、WebApp LoadBlance（ARR）は、対応するインスタンスに要求を割り当ててメッセージを処理します。インスタンスが削除されている場合、WebApp loadBlance（ARR）は既存インスタンスに要求を割り当てます。

サービスバスは、インスタンス（サブスクリプションを持っている人）がいなくなったときに、そのメッセージがキューに入れられている間にそのサブスクリプションのメッセージを削除すると理解します（それ以前の多くのメッセージ）。

前述のように、WebApp LoadBlance not serviceバスによって割り当てられます。メッセージをどのように消費するかは、WebAppによって異なります。