2

私の質問は、IBMMQの単一のキューを使用した1対多のメッセージフローについてです。MQは初めてです。

シナリオ-単一のキューから読み取る複数のプロセスがあり、それらがキューからメッセージを読み取るときに、それらすべてが同じメッセージを受け取ると仮定します。

つまり、キューにメッセージがなく、2つのリーダーがブロックされている（MQGETを実行した）とします。

  1. 1つのメッセージがキューに入ります（論理的にはプロセス1を意味します）。両方が待機していた（MQGETを実行した）ときにメッセージを受け取るのか、それともランダムに1つのプロセスに対してのみメッセージを受け取るのか。

  2. メッセージが読み取られると、キューから削除されます。

  3. 読み取り後にメッセージがキューから削除された場合、プロセス1が処理中であり、新しいメッセージがそのメッセージに対して届き、代わりにプロセス2がメッセージを取得して削除されたとします。プロセス1が取得しようとすると、メッセージは取得されません。これは可能ですか。

基本的に、メッセージが正しいプロセスに送られ、メッセージが失われないように、単一のキューで複数のプロセスを管理する方法を知りたいです。

4

1 に答える 1

2

セレクターが使用されていない場合、キューで読み取る複数のアプリがメッセージを競合します。ストレートFIFO読み取りは、競合するアプリにメッセージを配信し、1つのメッセージがアプリインスタンスの1つに1回配信されるようにします。アプリが同期点の外でメッセージを取得するか、発行すると仮定すると、COMMIT他のアプリはメッセージを認識せず、完全に削除されます。

動作を変更するものは次のとおりです。

  • メッセージセレクター。アプリがMsgIDまたは他の選択基準によってメッセージを受信した場合、QMgrは選択に一致するメッセージのみをアプリで使用できるようにします。複数のアプリインスタンスが同じ選択基準を使用する場合、それらはセレクターによって定義されたサブセット内のメッセージをめぐって競合します。
  • ロールバック。アプリがメッセージをロールバックすると、メッセージは再び利用可能になり、同じまたは異なるアプリケーションインスタンスに移動する可能性があります。
  • 優先配達。メッセージが優先度順に並べられ、最も優先度の高いメッセージが最初に配信されることを除いて、FIFOと同様に動作します。
  • メッセージグループ。グループIDでメッセージを選択し、グループ内のすべてのメッセージが存在するまでGETが成功しないように指定することができます。部分的なグループがキューに到着した場合、キューの深さを確認することはできますが、アプリケーションにメッセージは配信されません。

質問を1つずつ見ていきます。

  1. メッセージはキューに入れられます（論理的にはプロセス1を意味します）。両方が待機していた（MQGETを実行した）ときにメッセージを受け取るのか、それともランダムに1つのプロセスに対してのみメッセージを受け取るのか。
    キューは安いです。アプリがFIFOを読み取っている場合は、App1とApp2宛てのメッセージを同じキューに入れないでください。異なるアプリ（または同じアプリの異なるインスタンス）間でキューを共有する唯一の方法は、キューから読み取るすべてのものがセレクターを使用し、セレクターがメッセージを効果的に分離して適切なアプリに移動する場合です。1つのインスタンスでもFIFOを実行している場合、それは機能しません。

  2. メッセージが読み取られると、キューから削除されます。
    はい、アプリが同期点のGET後にCOMMITまたは同期点のGET外側を発行する場合に限ります。アプリがキューを参照する場合、メッセージは残り、参照カーソルがキューから移動すると他のアプリで使用できるようになります。

  3. 読み取り後にメッセージがキューから削除された場合、プロセス1が処理中であり、新しいメッセージがそのメッセージに対して届き、代わりにプロセス2がメッセージを取得して削除されたとします。プロセス1が取得しようとすると、メッセージは取得されません。これは可能ですか。
    絶対。前述のように、FIFOモードでキューを読み取るアプリまたはアプリインスタンスはメッセージを競合します。実際にメッセージが「プロセス1に対して」到着する場合は、他のプロセスがメッセージを読み取れないようにするセレクターを使用するか、インスタンスごとに異なるキューを使用します。

于 2012-10-10T20:21:44.650 に答える