1

AMQP と JMS API のいくつかの実装に基づいて、永続的なメッセージ キューを用意する予定です。メッセージを何時間もキューに入れておくことが (アーキテクチャの観点から) 問題ないかどうかを知りたいです。1日が上限です。

基本的にはメッセージブローカを別の永続層として利用する予定です。これは実行可能ですか？

私が評価しているテクノロジーは、ActiveMQ、RabbitMQ、または qupid です。

4

2 に答える 2

2

基本的にはメッセージブローカを別の永続層として利用する予定です。これは実行可能ですか？

メッセージを保持するためのブローカの永続化メカニズムは、通常、ファイルベースまたは JDBC です。どちらかが機能します。それは実行可能ですか？確かに、それはブローカーの機能であり、一時的なメッセージの保持が目標であると仮定すると、意図した目的で使用することに問題はありません。1日は大したことではありません。

ただし、メッセージを 1 日またはそれ以上保持する予定がある場合は、メッセージの平均サイズと 1 日あたりのメッセージの合計数に基づいて計算を行うことをお勧めします。デフォルトでは、通常、キューの深さは 10Mb などの低い数値であり、これを超えると、ブローカはおそらく後続のメッセージをドロップします。これが起こらないようにしたい。ベンダーはこれを異なる方法で処理するため、仕様と深さを制御するために使用される構成パラメーターについては、RabbitMq と ActiveMQ を確認してください。SonicMq には「DeadMessage」キューと呼ばれるものがあり、これは期限切れまたは配信不能メッセージの送信先です。他の製品にも同様のものがあるかもしれません。

于 2013-09-25T21:23:15.700 に答える
1

永続的なキューを持つことは問題ありません。また、メッセージがキューに滞留している場合も問題ありません。クライアントは、更新やネットワークの問題などにより切断される可能性があります。これは、送信者を受信者から分離するキューの利点の 1 つであり、キューはバッファです。ただし、これらの使用例は通常の操作モードではなく、むしろ例外的な状況です。

メッセージング ブローカーを「別の永続化レイヤー」として使用することは技術的には可能ですが、この場合、迅速なメッセージ配信/メッセージングと長期ストレージ/データベースは異なるツール/シナリオであるため、おそらくデータベースの方が適しています。ですから、自問自答してください。それはまだメッセージングを行っているのか、それともすでにデータベースになっているのか?

通常のメッセージ遅延 (= 送信と受信の間の期間) が常に 1 時間を超えるユース ケースの場合、データベースの方が優れている可能性があります。JMS セレクターは通常、 where 句を使用したデータベース クエリよりも遅く、快適ではないからです。

もう 1 つの側面があります。特に HA クラスター モードでは、JMS プロバイダーでのメッセージのオンライン バックアップの必要性を検討してください。データベースを使用してこれを行う方が簡単かもしれません。

于 2013-09-25T16:11:46.553 に答える