Azure Service Bus セッションを使用すると、関連するメッセージの無制限シーケンスを共同で順序付けして処理できます。 セッションは、先入れ先出し (FIFO) および 要求-応答 パターンで使用できます。 この記事では、Service Bus を使用するときにセッションを使用してこれらのパターンを実装する方法について説明します。
注
Service Bus の Basic レベルはセッションをサポートしていません。 Standard レベルと Premium レベルでは、セッションがサポートされます。 これらのレベルの違いについては、「Service Bus の価格」を参照してください。
先入れ先出し (FIFO) パターン
Service Bus キューまたはサブスクリプションからのメッセージの処理で FIFO 処理を実現するには、セッションを使用します。 Service Bus はメッセージ間の関係の性質に関する規範ではなく、メッセージ シーケンスの開始または終了場所を決定するための特定のモデルも定義しません。
送信者は、アプリケーションによって定義された一意の識別子に セッション ID プロパティを設定することで、トピックまたはキューにメッセージを送信するときにセッションを開始できます。 AMQP 1.0 プロトコル レベルでは、この値は group-id プロパティにマップされます。
セッション対応のキューまたはサブスクリプションでは、セッション ID を持つメッセージが少なくとも 1 つ存在すると、セッションが存在します。 セッションが存在すると、セッションの有効期限が切れたり消えたりする時間や API は定義されません。 理論的には、今日のセッションのメッセージ、1 年後の次のメッセージを受信できます。セッション ID が一致する場合、セッションは Service Bus の観点から同じです。
ただし、通常、アプリケーションは一連の関連メッセージの開始と終了を定義します。 Service Bus では、特定の規則は課されません。 たとえば、アプリケーションでは、最初のメッセージの Label プロパティを 開始、中間メッセージを コンテンツとして、最後のメッセージを 終了するように設定できます。 コンテンツ メッセージの相対位置は、開始メッセージ SequenceNumber からの現在のメッセージ SequenceNumber デルタとして計算できます。
Von Bedeutung
キューまたはサブスクリプションでセッションが有効になっている場合、クライアント アプリケーションは通常のメッセージを送受信 できなくなります 。 クライアントは、セッション ID を設定してセッションの一部としてメッセージを送信し、セッションを受け入れることで受信する必要があります。 クライアントは、セッションが有効になっているキューまたはサブスクリプションを引き続きピークすることがあります。 メッセージの参照を参照してください。
セッションの API は、キューおよびサブスクリプション クライアントに存在します。 セッションとメッセージを受信する方法には、メッセージの受信タイミングと方法を手動で制御する命令型モデルと、メッセージ ループと処理を自動的に管理することで処理を簡略化するハンドラー ベースのモデルの 2 つの方法があります。
サンプルについては、「 サンプル 」セクションのリンクを使用してください。
セッション機能
セッションは、順序付けされた配信を維持および保証しながら、インターリーブされたメッセージ ストリームの同時デマルチプレクシングを提供します。
クライアントは、セッションを受け入れるセッション レシーバーを作成します。 クライアントがセッションを受け入れて保持すると、クライアントは、そのセッションの セッション ID を 持つすべてのメッセージに対して排他的ロックをキューまたはサブスクリプションに保持します。 これは、後で到着する セッション ID を持つすべてのメッセージに対する排他ロックを保持します。
ロックは、受信側で close メソッドを呼び出すとき、またはロックの有効期限が切れると解放されます。 レシーバーには、ロックを更新するメソッドもあります。 代わりに、ロックの自動更新機能を使用して、ロックを更新し続ける期間を指定できます。 セッション ロックはファイルに対する排他ロックのように扱う必要があります。つまり、アプリケーションはセッションを必要としなくなったり、それ以上のメッセージが期待されないとすぐに閉じる必要があります。
複数の同時受信プロセスがキューからプルする場合、特定のセッションに属するメッセージは、そのセッションに対するロックを現在保持している特定の受信プロセスに送信されます。 この操作により、1 つのキューまたはサブスクリプション内のインターリーブされたメッセージ ストリームが異なる受信者に対してクリーンに多重分離され、それらの受信者は、Service Bus 内でサービス側でロック管理が行われるため、異なるクライアント コンピューター上でも動作できます。
前の図は、3 つの同時セッション レシーバーを示しています。
SessionId = 4 の 1 つのセッションにはアクティブな所有クライアントがありません。つまり、この特定のセッションからメッセージが配信されません。 セッションは、サブ キューのようにさまざまな方法で動作します。
セッションレシーバーが保持するセッションロックは、 ピークロック 決済モードで使用されるメッセージロックの傘です。 1 つのセッションに対してロックを設定できるのは、1 つの受信者だけです。 受信側には多数の処理中のメッセージがある場合がありますが、メッセージは順番に受信されます。 メッセージを破棄すると、次の受信操作で同じメッセージが再び処理されます。
メッセージ セッションの状態
ワークフローが高スケールの高可用性クラウド システムで処理される場合、特定のセッションに関連付けられているワークフロー ハンドラーは、予期しないエラーから復旧でき、作業が開始された場所とは別のプロセスまたはコンピューターで部分的に完了した作業を再開できる必要があります。
セッション状態機能を使用すると、ブローカー内のメッセージ セッションのアプリケーション定義注釈が有効になり、そのセッションに対して記録された処理状態が、新しいプロセッサによってセッションが取得されたときにすぐに使用できるようになります。
Service Bus の観点からは、メッセージ セッションの状態は、1 つのメッセージのサイズ (Service Bus Standard の場合は 256 KB、Service Bus Premium の場合は 100 MB) のデータを保持できる不透明なバイナリ オブジェクトです。 セッションに対する相対的な処理状態は、セッション状態内に保持することも、セッション状態がそのような情報を保持するストレージの場所またはデータベース レコードを指すことができます。
セッションの状態、 SetState、および GetStateを管理する方法は、セッション レシーバー オブジェクトにあります。 セッション状態が以前になかったセッションは、 GetStateの null 参照を返します。 以前に設定したセッション状態は、受信側の SetState メソッドに null を渡すことによってクリアできます。
セッションの状態は、セッション内のすべてのメッセージが使用されている場合でも、クリアされない限り ( null を返します) 維持されます。
キューまたはサブスクリプションに保持されているセッション状態は、そのエンティティのストレージ クォータにカウントされます。 そのため、アプリケーションがセッションで終了したら、外部管理コストを回避するために、アプリケーションで保持状態をクリーンアップすることをお勧めします。
配信数の影響
セッションのコンテキストでのメッセージあたりの配信数の定義は、セッションがない場合の定義とは若干異なります。 配信数がいつ増加するかをまとめた表を次に示します。
| シナリオ | メッセージの配信数がインクリメントされているか |
|---|---|
| セッションは受け入れられますが、セッション ロックの有効期限が切れます (タイムアウトのため) | イエス |
| セッションが受け入れられ、セッション内のメッセージは完了せず (ロックされている場合でも)、セッションは閉じられます | いいえ |
| セッションが受け入れられ、メッセージが完了した後、セッションが明示的に閉じられます | N/A (標準フローです。ここでは、メッセージはセッションから削除されます) |
要求 - 応答パターン
要求/応答パターンは、送信側アプリケーションが要求を送信し、受信側が送信者アプリケーションに応答を正しく送信できるようにする、確立された統合パターンです。 通常、このパターンには、応答を送信するアプリケーションの有効期間が短いキューまたはトピックが必要です。 このシナリオでは、セッションは同等のセマンティクスを持つ単純な代替ソリューションを提供します。
複数のアプリケーションは、送信者アプリケーションを一意に識別するように特定のヘッダー パラメーターを設定して、1 つの要求キューに要求を送信できます。 受信側アプリケーションは、キューに入ってくる要求を処理し、セッションが有効なキューで応答を送信し、セッション ID を要求メッセージで送信者が送信した一意の識別子に設定できます。 要求を送信したアプリケーションは、特定のセッション ID でメッセージを受信し、応答を正しく処理できます。
注
最初の要求を送信するアプリケーションは、セッション ID を認識し、それを使用してセッションを受け入れ、応答を予期しているセッションがロックされるようにする必要があります。 アプリケーションのインスタンスをセッション ID として一意に識別する GUID を使用することをお勧めします。 特定の受信者が応答をロックして処理できるように、キューのセッション レシーバーにセッション ハンドラーまたはタイムアウトを指定しないでください。
シーケンスとセッション
シーケンス番号 自体は、キューの順序とメッセージの抽出順序を保証しますが、セッションを必要とする処理順序は保証しません。
たとえば、キューには 3 つのメッセージがあり、2 つのコンシューマーがあるとします。
- コンシューマー 1 がメッセージ 1 を取得します。
- コンシューマー 2 がメッセージ 2 を取得します。
- コンシューマー 2 はメッセージ 2 の処理を終了し、メッセージ 3 を取得しますが、コンシューマー 1 はまだメッセージ 1 の処理を行っていません。
- コンシューマー 2 はメッセージ 3 の処理を終了しますが、コンシューマー 1 はまだメッセージ 1 の処理を行っていません。
- 最後に、コンシューマー 1 がメッセージ 1 の処理を完了します。
この場合、メッセージの処理は、メッセージ 2、メッセージ 3、メッセージ 1 の順に行われます。 メッセージ 1、2、3 を順番に処理する必要がある場合は、セッションを使用する必要があります。
メッセージを順番に取得するだけで済む場合は、セッションを使用する必要はありません。 メッセージを順番に処理する必要がある場合は、セッションを使用します。 一緒に属するメッセージに同じセッション ID を設定する必要があります。これは、セット内のメッセージ 1、4、8、および別のセットの 2、3、6 です。
メッセージの有効期限
セッションが有効なキューまたはトピックのサブスクリプションの場合、メッセージはセッション レベルでロックされます。 いずれかのメッセージの有効期間 (TTL) が期限切れになった場合、そのセッションに関連するすべてのメッセージは、エンティティのメッセージの有効期限設定でデッドレタリングが有効になっている場合に基づいて削除されるか、デッドレタリングされます。 つまり、TTL を通過したメッセージがセッション内に 1 つある場合、セッション内のすべてのメッセージの有効期限が切れています。 メッセージは、アクティブなリスナーがある場合にのみ期限切れになります。 詳細については、「メッセージの 有効期限」を参照してください。
サンプル
Azure portal、PowerShell、CLI、Resource Manager テンプレート、.NET、Java、Python、JavaScript を使用して、キューの作成中にメッセージ セッションを有効にすることができます。 詳細については、「 メッセージ セッションを有効にする」を参照してください。
Azure Service Bus の機能については、使用する言語のサンプルを試してみてください。
- 。網
- ジャワ
- パイソン
- JavaScript