2017-08-11 3 views
0

マイクロサービスアーキテクチャに基づいたアプリケーションを開発したいと考えています。 さまざまなサービス間で非同期で通信するために、メッセージキュー(RabbitMQ、ActiveMQ、JMSなど)を使用する予定です。プロセス間通信を実現するためにメッセージキュー以外のアプローチはありますか?メッセージキューのないプロセス間(サービス)通信

ありがとうございました。

答えて

1

キューを使用して、リアルタイムで完了する必要のないタスクを処理する必要があります。

タスクをキューに追加し、部屋がある場合、プロセッサはキューからタスクを受け取り、&を処理してキューから削除します。

例:画像を使用してアプリケーションの取引を想定し

  1. 、ユーザーは非常に多くの画像をアップロードしています。イメージを圧縮するためにタスクをキューにアップロードします。また、プロセッサが空いているときは、キューに入れられたイメージを圧縮します。

  2. システムのログを書きたいときは、そのログをキューに入れて、あるプロセスがキューからログを取り出してディスクに書き込みます。したがって、メインプロセスはI/O操作の時間を無駄にしません。

提案:

あなたは、リアルタイム応答をしたい場合は、キューを使用しないでください。あなたは、入力を読むためにキューを絶えずpingする必要があります。それは悪い習慣です。キューがあなたの仕事を直ちに処理するという保証はありません。

だから、解決策は以下のとおりです。

  1. Redisのキャッシュ - あなたはキャッシュにあなたのメッセージを置くことができますし、他のプロセスがそのメッセージを読み込みます。 Redisは「In Memoryデータ構造」です。非常に速く、使いやすいです。オープンソースのように、インターネット上で利用可能なライブラリとリソースが多すぎます。 Read more about Redis.しかしここでも、利用可能なメッセージがあるかどうかチェックし、利用可能であればそれを読んで、処理して回答を与える必要があります。しかし、レディスから読むには、あまりコストがかかりません。 Redisでは、メモリ管理について心配する必要はなく、オープンソースコミュニティーによってうまく管理されます。

  2. ソケットを使用。ソケットは非常に高速ですが、イベントベースのため、軽量(必要な場合)にすることができます。 1つのプロセスがポート上でpingを実行し、他のプロセスが応答を聞き、応答します。しかし、あなたはメモリを管理する必要があります。バッファされたメモリがいっぱいになると、ここにメッセージを追加することはできません。非常に多くのユーザーがメッセージを作成している場合は、応答する相手を管理する必要があります。

あなたは一つの通信への一対一の通信や多くのを作りたいん?、常にメッセージを読みたいんようなので、それは、あなたの条件に依存?

+0

ありがとうございました。さまざまなセンサーがインストールされており、これらのセンサーは定期的にデータを送信します(イベントやユーザーの要求にも基づいています)。我々は、データを取得し、処理し、持続させ、操作することを望む。これに対処するには、よりスケーラブルで効率的で疎結合のソリューションが必要です。 – JavaUser

+0

それは多対1です。 この手順をリアルタイムで実行する必要がありますか?ソケットを使用すると、リアルタイムで処理できます(センサーはソケット上でリクエストを行い、他のプロセスではリクエストを処理して完了します)。データをキャッシュに入れておくことができます。それからデータをフェッチして使用するため、フェッチは速くなり、適時にDBに格納されます。どちらもスケーラビリティがあります。私はより速いアクセスのためにFB好きを保存するためにキャッシュを使うことができます。ソケットを使ってプロセスを非同期にすることができます。 –

+0

@Ujjaval Moradiya「あなたは非常に重要ではないタスク(..)を処理するためにキューを使うべきです。」の背後にある推論について詳しく説明できますか?私の目では、待ち行列は直接通信(RESTやソケットベースなど)よりもはるかに信頼性が高いです。いくつかの製品でpub-subを実行することもでき、頻繁にプーリングする必要はありません。 –