WebSphere MQ Telemetry Transport サービス品質レベルおよびフロー

WebSphere MQ Telemetry Transport は、サービス品質 (QoS) で定義されているレベルに従ってメッセージを配送します。サービス品質レベルについては、以下に示します。

QoS レベル 0「最大で一回」送達
メッセージは基礎となる TCP/IP ネットワークのベスト・エフォートで送達されます。 応答は想定されておらず、プロトコルで、再試行のセマンティクスは定義されていません。 メッセージは、一度ブローカーに到着するか、または一度も到着しないかのいずれかです。

以下の表は、QoS レベル 0 プロトコル・フローを示しています。

クライアント メッセージおよび方向 ブローカー
QoS = 0

PUBLISH
---------->

アクション: メッセージをサブスクライバーへパブリッシュする
QoS レベル 1「最低で一回」送達
ブローカーによるメッセージの受信は、PUBACK メッセージによって確認されます。 通信リンクまたは送信デバイスのいずれかで障害が識別された場合、または指定された時間が過ぎても確認通知メッセージが受信されなかった場合、送信側は、メッセージ・ヘッダー内の DUP ビットをセットしてメッセージを再送信します。メッセージは、少なくとも一度ブローカーに到着します。SUBSCRIBE および UNSUBSCRIBE メッセージは、QoS レベル 1 を使用します。

QoS レベル 1 のメッセージは、メッセージ・ヘッダー内にメッセージ ID があります。

以下の表は、QoS レベル 1 プロトコル・フローを示しています。

クライアント メッセージおよび方向 ブローカー

QoS = 1
DUP = 0
Message ID = x

PUBLISH
---------->

アクション:
  • メッセージをデータベースに保管する
  • メッセージをサブスクライバーへパブリッシュする
アクション: メッセージを廃棄する

PUBACK
<----------

 

クライアントがアプリケーション内で定義されている時間枠内に PUBACK メッセージを受信しないか、障害が検出されて通信セッションを再始動しなければならない場合、クライアントは DUP フラグをセットして PUBLISH メッセージを再送します。

クライアントから重複メッセージを受信すると、ブローカーはサブスクライバーに対してメッセージをリパブリッシュし、別の PUBACK メッセージを送信します。

QoS レベル 2「一回だけ」送達
QoS レベル 1 に加えて余分のプロトコル・フローを使用し、受信側アプリケーションに重複したメッセージが送達されないようにします。 これは最高レベルの送達であり、重複したメッセージを受け入れられない場合に使用されます。 ネットワーク・トラフィックは増えることになりますが、メッセージの内容が重要なときには、それだけの価値がある場合があります。

QoS レベル 2 のメッセージは、メッセージ・ヘッダー内にメッセージ ID があります。

以下の表は、QoS レベル 2 プロトコル・フローを示しています。

クライアント メッセージおよび方向 ブローカー

QoS = 2
DUP = 0
Message ID = x

PUBLISH
---------->

アクション: メッセージをデータベースに保管する
 

PUBREC
<----------

Message ID = x
Message ID = x

PUBREL
---------->

アクション:
  • データベースを更新する
  • メッセージをサブスクライバーへパブリッシュする
アクション: メッセージを廃棄する

PUBCOMP
<----------

Message ID = x

障害が検出される場合、または定義された時間枠を超えた場合、プロトコル・フローのそれぞれの部分が、DUP ビットをセットして再試行されます。 別のプロトコル・フローを送信すると、メッセージは確実に「一回」と「一回だけ」でサブスクライバーへ送達されます。

QoS1 および QoS2 はメッセージが送達される必要があることを示しているため、ブローカーはメッセージをデータベースに保管します。ブローカーがこのデータにアクセスできない場合は、メッセージが失われる可能性があります。詳細について、およびこのような問題を回避するためのアクションについては、Telemetry アプリケーションの設計を参照してください。

QoS レベル 1 および 2 に関する前提事項

どのネットワークにおいても、デバイスまたは通信リンクに障害が起こる可能性があります。障害が起こる場合、リンクの一方の側は、相手側で何が起こっているのか認識できないことがあります。このような状況を 未確定 (in doubt) 状態と呼びます。 このようなシナリオでは、メッセージの送達に関係するデバイスおよびネットワークの信頼性に関していくらかの想定を行う必要があります。

WebSphere MQ Telemetry Transport では、クライアントとブローカーはどちらも一般的には信頼性があると想定しますが、通信チャネルの方が信頼性が低いと見なします。さらに、クライアント・デバイスに障害が発生する場合、ほとんどの場合、一時的な障害ではなく、破局的な障害となります。ですから、デバイスのデータを回復できる見込みは低くなります。一部のデバイスは、不揮発性ストレージ (例えば、フラッシュ ROM) を持っています。 クライアント・デバイス上にさらに持続性の高いストレージがあると、一部のモードの障害から最も重要なデータが保護されます。

通信リンクの基本障害を超えると、障害モード・マトリックスは複雑になり、WebSphere MQ Telemetry Transport の仕様が処理できるよりも多くのシナリオが発生します。

確認されていないメッセージを再送するまでの時間の遅延 (再試行間隔) は、アプリケーションによって異なり、プロトコル仕様では定義されません。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ac10850_