9

オブジェクトの集団に発生するイベントについて複数の消費者に通知するシステムについて考えています。すべてのサブスクライバーは、0 個以上のオブジェクトで発生するイベントをサブスクライブできる必要があり、複数のサブスクライバーは、単一のオブジェクトで発生するイベントに関する情報を受信できる必要があります。

この場合、何らかのメッセージ キューイング システムが適していると思いますが、何百万ものオブジェクトが存在するという事実をどのように処理すればよいかわかりません。オブジェクトごとに個別のトピックを使用するのは適切ではありません [または大丈夫？

私が取るべきアプローチと、合理的なオープンソースのメッセージキューイングシステムを提案していただけますか?

詳細:

  • 何千人もの購読者がいるだろう [多くはないという意味],
  • サブスクライバーは、それぞれ数十または数百のオブジェクトをサブスクライブします。
  • 約500万から2000万のオブジェクトがあり、
  • イベント自体がメッセージを伝える必要はありません。そのオブジェクトが変更されたという情報だけで十分です。
  • オブジェクトの大部分は決してサブスクライブされません。
  • イベントは毎秒数百の最大レートで発生します。
  • 理想的には、サーバーは Linux で実行され、http long-poll [node js を使用して? 桟橋の下の継続？

フィードバックをお寄せいただきありがとうございます。漠然とした質問で申し訳ありません。

4

5 に答える 5

7

RabbitMQを強くお勧めします。私はこれまでにいくつかのプロジェクトで使用してきましたが、私の経験から、非常に信頼性が高く、幅広い構成を提供していると思います。基本的に、RabbitMQ はAdvanced Message Queuing Protocol (AMQP)標準を実装するオープンソース(Mozilla Public License (MPL) ) メッセージ ブローカーです。

RabbitMQ Web サイトに記載されているとおり:

RabbitMQ は、組み込みシステムからマルチコア クラスターやクラウドベースのサーバーまで、Erlang がサポートするあらゆるプラットフォームで実行できる可能性があります。

... Linux のようなオペレーティング システムがサポートされていることを意味します。

ここに node.js のライブラリがあります: https://github.com/squaremo/rabbit.js

コマンドラインツールとブラウザベースのユーザーインターフェースを含むRabbitMQサーバーの管理と監視のためのHTTPベースのAPIが付属しています - http://www.rabbitmq.com/management.htmlを参照してください。

私が取り組んできたプロジェクトでは、C# と 2 つの異なるラッパー、EasyNetQとBurrow.NETを使用して RabbitMQ と通信しました。どちらも RabbitMQ の優れたラッパーですが、Burrow.NET のほうが操作が簡単でわかりやすいので (フードの下で多くの魔法を実行しません)、ロガー、シリアライザー、等

私は、あなたが作業しようとしているオブジェクトの量を扱ったことはありません - 私は何千もの (数百万ではありません) を扱ってきました。しかし、どれだけ多くのオブジェクトをいじっても、RabbitMQ は常に非常に安定して動作し、システムのエラーの原因になったことはありません。

要約すると、RabbitMQ は使いやすく、セットアップも簡単で、AMQP をサポートし、HTTP 経由で管理できます。私が最も気に入っているのは、堅実な製品です。

于 2012-09-06T00:15:32.487 に答える
4

トピックを分割して、たとえば「オブジェクト更新トピック」「オブジェクト削除」などの特定のイベントを実行します。したがって、クライアントは、関心のあるイベントベースのトピックの「有限番号」にサブスクライブするだけで済みます。

メッセージを公開するときにヘッダーをメッセージに挿入し、クライアントにインテリジェンスを配置して、これらのヘッダーをメッセージセレクターとして使用します。たとえば、クライアントは関心のあるオブジェクトのリストを知っており、オブジェクトを「id」で識別すると言います。IDはヘッダーにすることができ、クライアントは「idヘッダー」を使用して関心があるかどうかを判断します。メッセージ。

必要かどうかによっては、メッセージがオフラインになって後で戻ってきた場合でもクライアントがメッセージを確実に受信できるように、確実な配信を確保することを検討することもできます。

頭のてっぺんにおすすめするオプションは、ActiveMQ、RabbitMQ、Redis PUB SUBです（Haventは実際にredis pub-subに取り組んでいます、十分な注意を払ってください）

最後に、 RabbitMQとRedisのパフォーマンスベンチマークをいくつか示します。

1秒あたり100メッセージしかプッシュされないことを確認しました。これはactivemqにとって大したことではありません。私は、毎秒240メッセージを処理するシステムでAmqを使用しており、問題なく動作します。ワーカーのスレッドプールを使用して、メッセージを非同期的に処理します。javaランドにいる場合は、akkaのようなフレームワークを見てください。そうでない場合は、nodejsとその周りのクールなEcoシステムに固執してください。

于 2012-09-05T23:30:20.903 に答える
2

オープンソースである必要がある場合は、ActiveMQと、トピックの JMS 機能を提供するアプリケーション サーバーを使用します。また、Ajax サポートがあるため、クライアントからそれらにアクセスできます。

したがって、JMS インフラストラクチャを使用してオブジェクトのトピックを公開し、必要に応じてトピックを作成できます。

さらに、Java アプリケーション サーバーを使用することで、クラスタリング、負荷分散、およびその他の高可用性機能を利用できる場合があります (明らかに選択した製品に基づきます)。

それが役立つことを願っています!!!

于 2012-09-04T15:29:21.680 に答える
2

メッセージが非常に小さいため、小型デバイス用に設計された MQTT を検討することをお勧めしますが、強力なデバイスでも問題なく動作します。重要な考慮事項は、オーバーヘッドが低いことです。基本的に、小さなメッセージの場合は 2 バイトのヘッダーです。ボリュームのために、おそらくシンプルまたはオープンソースの MQTT サーバーを使用することはできません。ボリュームを処理するには、おそらく MessageSight のような頑丈な専用アプライアンスが必要です。

あなたのアプリケーションに関するいくつかの詳細は確かに役立ちます。また、セキュリティについてはまったく言及していません。私はあなたがこの分野でいくつかのニーズを持っているに違いないと思います.

于 2014-05-15T17:41:42.483 に答える
1

あなたの作業環境についてはわかりませんが、ここに私のビットがあります。システム内の一意の ID で各オブジェクトを識別できますか。その場合は、イベントの種類ごとにトピックを作成できます。たとえば、オブジェクトの削除イベント、オブジェクトの更新イベントなどを追跡したい場合です。そのため、イベントの種類ごとにトピックを設定できます。これらのトピックは、対応するイベントがオブジェクトに発生するたびに、オブジェクトの ID とともに公開されます。これにより、必要なトピックの数が制限されます。問題の 2 番目の部分は、さまざまなサブスクライバーがさまざまなオブジェクトにサブスクライブしたいということです。したがって、すべてのサブスクライバーがすべてのオブジェクトのイベントを知ることに関心があるわけではありません。この問題ステートメントは、メッセージング フレームワークによって提供されるメッセージ セレクター (フィルタリング) メカニズムに限定されています。したがって、基本的には、サブスクライバーが特定のオブジェクトに関心を持っている基準を探す必要があります。メッセージフィルタリングメカニズムとしてその基礎を持っています。オブジェクトの種類、オブジェクトの状態など、何でもかまいません。したがって、最終的にシステムは、イベントの種類ごとに 1 つのトピックで構成され、誰かがイベント メッセージを公開します: {object-type:object-id} 情報。サブスクライバーは、フィルタリング条件を使用して、任意のトピックをサブスクライブできます。

上記のソリューションが満たされる場合、任意のメッセージング ソリューションを使用できます: activeMQ、WMQ、RabbitMQ。

于 2012-09-06T07:25:05.497 に答える