2017-07-25 11 views
0

ActiveMQのドキュメントでは、ワイルドカードを使用してサブトピックを作成することができます。私は、その後のいずれかのトピックのいずれか、またはすべてに登録することができActiveMQでワイルドカードを使用して階層トピックを作成する

  • physicalEnvironmet.Conditions
  • physicalEnvironmet.Infrastructure
  • physicalEnvironmet.Location

:だから、例えば私は、トピックを作成することができます(physicalEnvironmet。>)

しかし、より複雑な構造の場合は、どうすればこのように機能しますか:

enter image description here

ちらつきのためのトピックが呼び出されます:

  • physicalEnvironmet.Conditions.Light.Flickering

そしてだけで考えられて話題に加入しているように、私はまだ、正確な選択をしている可能性があり光:

  • physicalEnvironmet.Conditions.Light>

サブトピックのレベル制限がある場合や階層的なトピックオーダーを作成するより簡単な方法がある場合は、基本的に私は尋ねています。

+0

合計トピック数はいくつありますか?予想されるクライアント数は?予想されるメッセージ数/時間は何ですか?予想されるメッセージサイズは何バイトですか? –

+0

トピックの完全な構造はまだ未定ですが、私が推測しなければならないのは、Idは約30-50です。クライアントのためには、pub/subは自己適応型システムのためには言い難いので、非常に多くなる可能性があります。 (容易に100以上)。センサーが関与しているので、数秒ごとにメッセージが送信される可能性があります。限られた情報を含むJSONオブジェクトなので、メッセージのサイズはかなり小さいです。 –

答えて

1

私の10年以上のメッセージングでは、すべての階層的トピック構造が置き換えられ、分類学は決してうまくいかない。あなたの全体的なメッセージパターンは適度な総ボリュームを示唆しているので、フィールドを使用してトピック名との差異を定義する柔軟なイベントモデルを提案します。eventType = "Environmental" sensorType = "Light"これにより、新しいものを追加し、ブローカを煩わせることなくクライアントが望むものとしたくないものを除外することができます。

もう1つの方法は、JMSヘッダーを使用して同じことを行うことです。これにより、セレクタを使用してブローカ側のフィルタ処理を行うことができます。

関連する問題