制御できない外部システムからメッセージを受信する MQ Queue が 1 つあります。着信メッセージを処理する当社のシステムは重要であり、何があっても 27 時間 365 日稼働している必要があります。
着信メッセージが処理される順序も交渉可能ではありません。つまり、メッセージが到着した順序で正確に処理する必要があります。
システムが 100% 利用可能であることを確認するために、これらのメッセージを処理できる多数の物理マシンにシステムを展開しました。
メッセージがシステムに到達すると、並列処理の結果としてパフォーマンスがいくらか向上すると同時に、メッセージ処理が順不同にならないようにするメカニズムを導入しました。私たちにとってパフォーマンスの向上は良いことですが、私たちの主な目標は適切な処理順序を保証しながら高可用性を実現することであるため、むしろ副作用です。
私の考えでは、受信メッセージを処理できる MDB をすべてのマシンに配置し、一度にアクティブなコンシューマーを 1 つだけ持つことを考えました。
JMS プロバイダーとして Webshere MQ を使用し、アプリケーションをデプロイするために Webshere Application Server 8.5 を使用しています。
複数のコンシューマーが同じキューをリッスンしているという問題は、メッセージが大量に到着すると、すべてのコンシューマーにラウンドロビンで渡され、これがどのように発生するかを制御する方法がないため、実行可能な解決策ではないようです。簡単に順番が狂います。
すべてのリスナーを手動で停止すると、明らかにメッセージが順番に処理されました。ただし、そのようなリスナーを手動でシャットダウンして起動することは、HA ソリューションではありません。
システムの健全性をチェックし、必要に応じてシステムをシャットダウンまたは起動する監視プロセスを導入することもできますが、それでも私には弱すぎるように見えます。実際に必要なのは、すべてのリスナーを稼働させ、メッセージを受信するのは 1 つだけにすることです。その 1 つが何らかの理由でダウンした場合、そこに座っている別の 1 つがアクティブになり、メッセージの処理を開始します。
最初はキューではなくトピックを使用することを検討しましたが、これには次のような他の問題が伴います。
- メッセージの発信元を制御することはできません
- 私たちが持っているメッセージの量が多いと、サブスクライバーがダウンするという問題が発生します。サブスクライバーは耐久性が必要であり、戻ってきたときに多くの保留中のメッセージを処理する必要があります。
- 入力キューはすでにクラスターの一部であり、すべてのインフラストラクチャーを変更するには多くの作業が必要になります。
とにかく、私の見解では、このような状況に対応するには既存のパターンでなければなりません。どんな助け、提案も大歓迎です。
ソリューションは特定の MQ である必要はありません。どんなアイデアでも大歓迎です。
前もって感謝します