職場では、PHP アプリケーションにメッセージ キューを実装するかどうかについて話し合っています。現在、Apache の ActiveMQ を検討しています。完全に明確ではないことの 1 つは、キューに到着したメッセージに基づいてプロセスをトリガーできるかどうかです。
これまでに見つけた文献は、メッセージ キューがプル ベースのメカニズムであることを示しているようです。プロセスは定期的に (デーモンまたは cron として) 実行され、受信メッセージをキューからプルします。これをプッシュ機構に変えることは可能ですか？つまり、メッセージが到着したときにメッセージ キューが実際に HTTP 要求 (またはプロセス) を開始する方法はありますか? 私たちが見つけた 1 つのオプションはパブリッシュ/サブスクライブ モデルですが、これには、PHP アプリを無限ループで実行して、ActiveMQ インスタンスへのオープン (TCP) 接続を維持する必要があり、少し手間がかかります。
任意の入力をいただければ幸いです。
キューを監視するアプリの設計コンセプトは、外部アプリケーションの実行をトリガーする業界の方法です。IBM Websphere "Trigger Monitor Applications" をご覧ください。それらの実装では、キュー内のメッセージを処理するアプリを開始するための複数のトリガー モニターを使用できるため、トリガー モニターがアプリがインストールされているサーバー上で実行されるため、非常にうまくスケーリングされます (スケーラビリティを設計する場合は、必要に応じて複数のアプリ サーバーを用意します)。
キュー (JMS コンポーネント) からメッセージをプルし、HTTP エンドポイント (HTTP コンポーネント) に転送する Camel ルートを作成することを検討してください。Camel ルートを ActiveMQ ブローカー プロセスでホストすることもできます。つまり、一種のインテリジェントなルーティング ブローカーを作成します。ActiveMQ は、Camel Core ライブラリを ActiveMQ ディストリビューションにバンドルすることで、これを容易にします。
最近の関連/関連投稿は次のとおりです。
明らかな解決策は、発行者がメッセージを保存した直後に HTTP 要求を開始できるようにすることですが、これには疑問が生じます。なぜメッセージ キューを使用しているのでしょうか。
一連のコンシューマーがキューをリッスンし、メッセージが来ると仕事をするのは面倒なことではなく、優れたスケーラブルな設計です。(ただし、PHP プロセスを無限ループで実行することには短所があることに同意します。)
メッセージを格納するデータベースではなく、なぜメッセージ キューを選択したのでしょうか。「プロデューサー」はメッセージをテーブルの行として保存し、メッセージの PK で「コンシューマー」をトリガーできます。