Service Bus のキュー、トピック、サブスクリプションを検出する
Service Bus のメッセージング機能の中核を形成するメッセージング エンティティは、キュー、トピックおよびサブスクリプション、およびルール/アクションです。
キュー
キューでは、コンシューマーが競合している場合のメッセージ配信に先入れ先出し法 (FIFO) を使用します。 つまり、受信者は、通常はキューに追加された順序でメッセージを受信して処理します。 そして、1 つのメッセージ コンシューマーだけが、各メッセージを受信して処理します。 メッセージはキューに永続的に保存されるため、プロデューサー (送信者) とコンシューマー (受信者) はメッセージを同時に処理する必要はありません。
関連する利点として負荷平準化があります。これにより、プロデューサーとコンシューマーは異なるレートでメッセージを送受信できます。 多くのアプリケーションでは、システム負荷は時間の経過とともに変化します。 ただし、各作業単位に必要な処理時間は通常一定です。 メッセージ プロデューサーとコンシューマーの間をキューで仲介することは、コンシューマー側アプリケーションはピーク時ではなく平均時の負荷を処理できるだけでよいということを意味します。
キューを使用してメッセージ プロデューサーとメッセージ コンシューマーの間を仲介すると、必然的にコンポーネント間の結び付きは緩くなります。 プロデューサーとコンシューマーは相互に認識しないため、プロデューサーに影響することなく、コンシューマーをアップグレードできます。
キューは、Azure portal、PowerShell、CLI、または Resource Manager テンプレートを使用して作成できます。 次に、C#、Java、Python、JavaScript で記述されたクライアントを使用して、メッセージを送受信します。
受信モード
Service Bus がメッセージを受信する際のモードとして、[受信して削除] または [ピーク/ロック] という 2 つの異なるモードを指定できます。
受信して削除
このモードでは、コンシューマーからの要求が Service Bus に到達すると、メッセージが既読としてマークされ、コンシューマー アプリケーションに返されます。 このモードは最もシンプルなモデルです。 これは障害発生時にアプリケーション側でメッセージを処理しないことを許容できるシナリオに最適です。 たとえば、コンシューマーが受信要求を発行した後で、メッセージを処理する前にクラッシュしたというシナリオを考えてみましょう。 Service Bus がメッセージを使用中としてマークすると、アプリケーションは再起動時にメッセージの使用を開始します。 クラッシュ前に読み取られたメッセージは見逃してしまいます。
ピーク ロック
このモードでは、受信処理は 2 段階になります。これにより、メッセージが失われることを許容できないアプリケーションに対応することができます。
次に読み取られるメッセージを検索し、他のコンシューマーが受信できないようロックしてから、アプリケーションにメッセージを返します。
アプリケーションでのメッセージの処理が終了した後、Service Bus サービスに対して受信プロセスの第 2 段階を完了するよう要求が行われます。 次に、サービスによってこのメッセージが使用済みとしてマークされます。
アプリケーションは、なんらかの理由でメッセージを処理できない場合に、Service Bus サービスに対してメッセージを破棄するように要求できます。 Service Bus によってメッセージのロックが解除され、同じコンシューマーまたは競合する別のコンシューマーが再度そのメッセージを受信できるようになります。 第 2 に、ロックに関連付けられたタイムアウトがあります。 ロックがタイムアウトになる前にアプリケーションがメッセージの処理に失敗した場合には、Service Bus によってメッセージのロックが解除され、再度受信できる状態になります。
トピックとサブスクリプション
キューでは、1 つのコンシューマーが 1 つのメッセージを処理できます。 キューとは対照的に、トピックとサブスクリプションは、"発行とサブスクライブ" のパターンで一対多の形式の通信を実現します。 これは、多数の受信者にスケーリングする場合に便利です。 発行された各メッセージは、トピックに登録している各サブスクリプションで使用できるようになります。 パブリッシャーがトピックにメッセージを送信すると、1 つ以上のサブスクライバーがメッセージのコピーを受け取ります。
サブスクリプションでは、追加のフィルターを使用して、受信するメッセージを限定できます。 パブリッシャーは、メッセージをキューに送信するのと同じ方法でトピックにメッセージを送信します。 ただし、コンシューマーはトピックから直接メッセージを受信しません。 代わりに、コンシューマーはトピックのサブスクリプションからメッセージを受信します。 トピック サブスクリプションは、トピックに送信されたメッセージのコピーを受け取る仮想キューのようなものです。 コンシューマーは、キューからメッセージを受信する場合と同じ方法で、サブスクリプションからメッセージを受信します。
キューのメッセージ送信機能はそのままトピックに相当し、メッセージ受信機能はサブスクリプションに相当します。 特に、この機能は、サブスクリプションでは、競合コンシューマー、一時的な切り離し、負荷平滑化、負荷分散など、キューに関してこのセクションで既に説明したのと同じパターンがサポートされることを意味します。
ルールとアクション
多くのシナリオでは、特性のあるメッセージは、異なる方法で処理する必要があります。 この処理を実現するために、目的のプロパティを持つメッセージを検索し、該当するプロパティに特定の変更を行うようにサブスクリプションを構成できます。 Service Bus のサブスクリプションには、トピックに送信されたすべてのメッセージが表示されますが、仮想サブスクリプション キューにコピーできるのは、これらのメッセージの一部のみです。 このフィルター処理を行うには、サブスクリプション フィルターを使用します。 このような変更は、"フィルター アクション" と呼ばれます。 サブスクリプションの作成時に、メッセージのプロパティを操作するフィルター式を指定できます。 プロパティには、システム プロパティ (Label など) とカスタム アプリケーション プロパティ (StoreName など) の両方を指定できます。この場合、SQL フィルター式は省略可能です。 SQL フィルター式を指定しない場合は、サブスクリプションで定義されている任意のフィルター アクションが、そのサブスクリプションのすべてのメッセージに対して実行されます。