調べたところ、2 つのシステム間でメッセージを送信していました。
しかし、なぜ?を使用しないのはなぜDatabase
ですか?持っていない
機能があるはずですか?ActiveMQ
Databases
8 に答える
2 つの分散プロセス間で確実に通信するために使用されます。
はい、メッセージをデータベースに保存して 2 つのプロセス間で通信することはできますが、メッセージを受信するとすぐにメッセージを取得する必要がDELETE
あります。つまり、行INSERT
とDELETE
メッセージごとに。1 秒あたり数千のメッセージの通信をスケール
アップ
しようとすると、データベースは失敗する傾向があります。
一方、メッセージ指向のミドルウェア [MOM] はActiveMQ
、これらのユース ケースを処理するように構築されています。
彼らは、正常なシステムのメッセージは非常に迅速に削除され、オーバーヘッドを回避するために最適化を行うことができると想定しています。
コンシューマーが SQL クエリを実行して新しいメッセージをポーリングする代わりに、メッセージをコンシューマーにプッシュすることもできます。
これにより、システムに送信される新しいメッセージの処理に伴う待ち時間がさらに短縮されます。
ActiveMQ
、または一般に、すべてのメッセージ指向ミドルウェア (MOM) 実装は、2 つのアプリケーション間、または 1 つのアプリケーション内の 2 つのコンポーネント間でメッセージを送信する目的で設計されています。
基本的に、MOM とデータベースは、読み取りと書き込みが可能なトランザクションおよび永続的なデータ ストレージを提供するという点で、共通の基盤を共有しています。
大きな違いは、使用パターンです。データベースは非常に一般的で、複数のテーブルに対する複雑な検索用に最適化されています。MOM は、FIFO のような方法 [キュー] で一度に 1 つずつメッセージを読み取るように最適化されています。
JMS
は、ActiveMQ が実装する API であり、Java エンタープライズ アプリケーションの重要な土台です。これにより、メッセージはかなり一般的な形式とセマンティックを共有するようになり、異なるアプリケーション間の統合が容易になります。
OpenWire
もちろん、ActiveMQ だけにあるより詳細な機能がたくさんありSTOMP
ます。
これらのトピックはかなり大きいため、興味がある場合は、これらのトピックについて少し読んでおく必要があります。MQTT
JMS
EIP
ActiveMQ
には優れたスケジューラサポートがあります。つまり、特定の時間に配信されるようにメッセージの送信をスケジュールできます。
この機能を使用して、医療シナリオで薬の詳細をアップロードしている患者に薬のリマインダーを送信しました。
ウィキペディアより
Apache ActiveMQ は、完全な Java Message Service (JMS) クライアントとともに Java で記述されたオープン ソースのメッセージ ブローカーです。この場合、複数のクライアントまたはサーバーからの通信を促進することを意味する「エンタープライズ機能」を提供します
お問い合わせについて:
なぜデータベースを使用しないのですか?
一時データではなく、永続データにデータベースを使用する必要があります。Sender から Receiver にメッセージを送信する必要があるとします。メッセージを受信すると、Receiver は 1 つの操作 ( receive 、 process 、および forget ) を実行します。そのメッセージを処理した後は、そのメッセージはまったく必要ありません。この場合、メッセージを永続データベースに保存することは適切な解決策ではありません。
メッセージングシステムの代わりにデータベースを使用する場合、データベースへのメッセージの挿入と削除に関する@Hiram Chirinoの回答に完全に同意します。
- エンタープライズ統合: 異なる言語および異なるオペレーティング システムで構築されたアプリケーションを相互に統合できるようにする
- 場所の透過性: クライアント アプリケーションは、サービス アプリケーションの場所を知る必要はありません。
- 信頼できる通信– メッセージのプロデューサー/コンシューマーが同時に利用可能である必要はありません
- スケーリング– サービスを追加することで水平方向にスケーリングできます
- 非同期通信– クライアントは、サービスが応答を送信するまでブロックするのではなく、メッセージを送信して他の処理を続行できます。
- カップリングの減少- 前の 5 つの利点の結果として、クライアントとサービスによってなされる仮定が大幅に減少します。サービスは、クライアントに影響を与えたり中断したりすることなく、場所、プロトコル、可用性など、それ自体に関する詳細を変更できます。
ActiveMQ には、データベースにはない機能が必要ですか?
沢山あります。詳細については、ドキュメントページを参照してください。ユースケースもご覧ください。
このプレゼンテーションを見て、ActiveMQ の内部を理解してください。
次のことを強調したいと思います。
Decoupled : システムは接続されていなくても通信できます。キューはシステム間にあります。通信はキューを介して行われるため、1 つのシステム障害が他のシステムに影響を与えることはありません。システムは、稼働中も引き続き機能します。
回復サポート: Queues 自体のメッセージは永続化されました。Queue が失敗した場合、メッセージは後で復元できます。
信頼できる通信: クライアントの要求を処理するシステムを考えてみましょう。通常、システムは 1 分あたり 100 件のリクエストを受け取ります。このシステムは、リクエスト数が平均を超えると信頼できなくなります。このような場合、キューはリクエストを管理でき、システムのスループットに基づいてメッセージを中断することなく定期的にプッシュできます。
Asynchronous : クライアント サーバー通信はノンブロッキングです。クライアントがサーバーに要求を送信すると、応答を待たずに他の操作を実行できます。応答が受信されると、クライアントはいつでもそれを処理できます。
次の一般的なユーザー シナリオを検討してください。
ユーザーシナリオ
- 顧客がテキスト ドキュメントをアップロードする
- アプリケーションがテキスト ドキュメントを PDF に変換する
- アプリケーションは PDF を電子メールで顧客に送り返します
キューベースのシステム用のデータベース このような状況では、PDF ジョブ ラインにデータベースを採用することを検討してください。通常は、PDF 要求に対応するレコードを含む行を含むデータベース テーブルを作成します。その時点で、割り当てがどの状態にあるか、用事が完了したかどうかについて話しているテーブルに雹を置きます。
INSERT INTO pdf_job_queue (name, status, email) VALUES ("White paper", "NEW", "myemail@example.com");
SELECT * FROM pdf_job_queue WHERE queue = 'resize_queue' AND handled = false ORDER BY date_recived limit 1;
新しいリクエストをデータベースに挿入するコードを記述する必要があります。データベースから入力を受け取り、ステータス列を " NEW
" や " "などの値で変更するPROCESSING
コード、リクエストを処理するコード、データベースのステータス フィールドを " FINISHED
" に再度更新するコード、およびステータス列を削除するコードキューからのリクエスト。
update pdf_job_queue set Status="FINISHED" where Id = 'SomeId';
効果的に運用するには、データベースを迅速かつ頻繁にポーリングする必要がある場合があります。もちろん、これはデータベースとアプリケーションにかなりの負荷を加えます。
メッセージ キュー メッセージ キュー を使用して同じことを達成しようとする場合。
PUSHED IN REAL-TIME メッセージ行からのメッセージは、時々データベースから調査されるのではなく、リアルタイムでプッシュされます。メッセージ行を上手に使用することで、より大量の同時メッセージを維持することができます。メッセージ行のメッセージは、取得後に自然にクリーンアップされます。
ACKNOWLEDGMENT 特定のメッセージが受信および処理されたこと、およびメッセージ キューが自由に削除できることをメッセージ キューに通知するために、ワーカーから承認が返されます。確認応答を送信せずにワーカーが停止した場合、メッセージ キューはメッセージが完全に処理されていないことを認識し、メッセージをキューと別のワーカーに再配信します。そうすれば、メッセージが失われないことを確認できます。
メッセージ キュー システムの場合は、インストールと構成が簡単で、スケーリングが非常に簡単なActiveMQを常にお勧めします。