4

クライアントがメッセージの永続化や確実な配信を許可しない場合、MQ クライアントとサーバーを使用して耐久性のあるアーキテクチャ環境を作成するにはどうすればよいでしょうか?

クライアントにデータの永続化に必要なコンポーネントが含まれていないように見える場合に、販売可能で耐久性のあるアーキテクチャを構築する方法を理解しようとしています。

ありがとう、

S

4

2 に答える 2

4

ミドルウェア メッセージングは​​、リモート ノードまたはネットワークの障害の影響を軽減するためにデータをローカルに永続化する必要性から生まれました。当時のアイデアは、キュー マネージャーは、アプリケーションが存在するボックスにローカルにインストールされ、トランスポート スタックの一部として扱われるというものでした。たとえば、トランスポートとして TCP と WMQ をインストールすると、一部のアプリは TCP を使用し、他のアプリは WMQ を使用します。

その後の 20 年間で、MQSeries (現在の WebSphere MQ) の作成につながった元の問題は大部分が解決されました。ネットワークは可用性が数 9 向上し、ハードウェアとソフトウェアの高可用性クラスタリングにより、さまざまなコンポーネントを 24 時間 365 日利用できるようにするオプションが提供されました。

したがって、あなたの質問に対処するために今日広く使用されている慣行は、2 つの基本的なアプローチに従っています。コンポーネントの可用性を高めて、クライアントが常にメッセージング サーバーを検出できるようにするか、ローカル キューイングを提供するためにアプリケーションが存在する場所に QMgr を配置します。

于 2012-05-01T15:25:46.157 に答える
1

MQ のデフォルトの操作では、メッセージが送信されると (MQPUT または JMS 用語の Producer.send)、メッセージがキュー マネージャーのキューに到達するまで、アプリケーションは MQPUT 呼び出しで応答を返しません。つまり、MQPUT は同期呼び出しであり、完了コード OK を受け取った場合は、クライアント アプリケーションが接続されているキュー マネージャーがメッセージを正常に受信したことを意味します。最終的な宛先にはまだ到達していない可能性がありますが、MQ サーバーの保護に到達しているため、MQ を使用してメッセージを管理し、必要な場所に転送することができます。

クライアントがキュー マネージャーに接続されているか、ローカルにバインドされているかに関係なく、メッセージを送信するアプリケーションは、MQPUT 呼び出しが正常に返されるまでデータを管理します。同様に、受信側アプリケーションは、MQGET (または JMS consumer.receive) 呼び出しが成功してデータを取得すると、そのデータに対して責任を負います。

複数のレベルのメッセージ保護が利用可能です。非永続メッセージと非同期 PUT を使用している場合は、メッセージが宛先に到達するかどうかはあまり重要ではないと効果的に言っています (ただし、通常は到達します)。MQ にメッセージを実際に処理させたい場合は、上記の同期 PUT と永続メッセージを使用し、トランザクション (同期点) 内で PUT と GET を実行して、コミット ポイントをアプリケーションで完全に制御できるようにします。

非常に信頼性の低いネットワークを使用していて、サーバーへのメッセージの取得に定期的に失敗することが予想され、クライアント側のメッセージ保護が必要なために定期的な再試行が必要になることが予想される場合、調査できるオプションの 1 つは MQ Telemetry です (たとえば、WebSphere MQ でV7.1) は、より広い MQ へのルートとして、低帯域幅および/または信頼性の低いネットワーク通信用に設計されています。

于 2012-05-02T16:09:47.900 に答える