ActiveMQの永続的サブスクリプション設定

クズども · 掲載地 2017/01/09 11:12:10

ActiveMQの永続的サブスクリプション設定
パブリッシャーのPERSISTENT Delivery Modeを設定することで、購読者に永続的なサブスクリプションを適用でき、Pub/Subプログラムがすべての公開メッセージを受け取ることを保証します。
メッセージサブスクリプションは非耐久サブスクリプションと耐久サブスクリプションに分けられ、非耐久サブスクリプションはクライアントがアクティブである場合にのみトピックに送信されたメッセージを受け取ります。つまり、クライアントがオフラインの間、この期間中に送信されたメッセージは失われ、受信されません。クライアントがオフラインのとき、ActiveMQは対象者に送られたすべてのメッセージをIDに従って保存し、クライアントが再びActiveMQに接続すると、オフライン中の対象者に送られたすべてのメッセージを受け取ります。永続的サブスクリプションはオーバーヘッドを増やし、永続的サブスクリプションには一度にアクティブユーザーが1人しかいない。永続的サブスクリプションを確立するための手順:
1. 接続用の顧客IDを設定すること;
2. 購読トピックのサブスクリプション名を指定する;
上記の組み合わせは一意でなければなりません。
コードは永続的なサブスクリプションを実装します

(1) キューを使う場合、つまりキューイング時には1つのメッセージにつき1つのコンシューマーしかいないため、永続化は非常に簡単で、データベースに保存するだけです

。その後、消費者はそれを拾って処分できます。消費者がしばらくオフにしても問題ありません。

(2) トピック、すなわち購読時に、各メッセージに複数の消費者が存在する可能性があり、これはより厄介です。

まず、消費者が一般消費者であると仮定すると、
------------------------
<1>activemqのローンチ後、news 1もリリースされましたが、残念ながら今は消費者が登録していません。つまり、登録した消費者はいません。だから

ニュースは放棄された。

<2> 消費者1が起動し、activemqに接続し、購読してメッセージを待った~~

activeMQはメッセージ2を投稿し、OK、コンシューマー1が受信し処理します。メッセージ放棄。

<3> Consumer 2も起動し、activemqに接続し、購読済みでメッセージを待っています~~

activeMQはメッセージ3、OK、消費者1、消費者2がすべて受信・処理されます。メッセージ放棄。

<4> コンシューマー1は電源が切れています。

activeMQはメッセージ4を投稿し、OK、コンシューマー2が受信し処理します。メッセージ放棄。

<5> 消費者1が再び起動しました。

activeMQはメッセージ5、OK、消費者1、消費者2をすべて受信し処理します。メッセージ放棄。
-----------------------------
まとめると：
ActiveMQは単に現在起動した消費者にメッセージを送信します。
電源を切った消費者は多くのメッセージを見逃し、再び受信できなくなります。

送信されたメッセージが重要なユーザー同期データで見逃された場合、そのユーザーデータは同期されていません。

では、消費者が再起動した際に不在メッセージを受け取るにはどうすればよいのでしょうか?

その答えは、持続的なサブスクリプションです。
-----------------------------

一般の定期購読者は、消費者を区別せず、会場に数人いれば蒸しパンを少し投げてくれます。
永続的なサブスクリプションの場合は、消費者の名前を記録する必要があります。
張三は言った。「私は張三。蒸しパンがある。取りに戻ってくる。」
リースは言った。「私はリース。蒸しパンがあるから、取りに戻ってくるよ。」
activeMQは張三と李思の名前を書き留めました。

そして蒸し饅頭を分けても、片方の頭が蒸し饅頭になります。
分裂後、張三が話さないのを見たのは、彼がいなかったということだから、一人残しておけ。
リー・スーが話したので、ここにいる必要はなかった。

張三は戻ってきて、activemqを探して確認した。これは張三じゃない、早く蒸し饅頭を持ってきて。
蒸し饅頭一つか、蒸し饅頭が100個かもしれない。張三がしばらく離れてからどれだけの蒸し饅頭を分けたかによる。

ActiveMQはクライアントIDと加入者名で消費者を区別します。
-----------------------------
つながりを作る
connection = connectionFactory.createConnection();
connection.setClientID("bbb"); 永続的なサブスクリプションにはこれを設定する必要があります。
connection.start();

セッションを作成する
Session session = connection.createSession(false,Session.AUTO_ACKNOWLEDGE);

目的地を作成する
トピックトピック = session.createTopic("userSyncTopic"); トピック名

MessageConsumer consumer = session.createConsumer(topic); 定期購読
MessageConsumer consumer = session.createDurableSubscriber(topic,"bbb"); 永続的サブスクリプション

もう一つのポイントは、メッセージの生成者がメッセージ送信時に永続モードを使用していることです
MessageProducer プロデューサー = ...;
producer.setDeliveryMode(DeliveryMode.PERSISTENT);
そうでなければ、デフォルトで永続的です

(5) 同じ「clientID」が使用されている場合、それは同一のコンシューマーとみなされます。もし2つのプログラムが同じ「clientID」を使う場合、同時に1つだけがactivemqに接続でき、もう1つの接続はエラーを報告します。

(6) activemqの設定はconf/activemq.xmlにあり、デフォルトのメッセージはdata/kahadbに保存され、activemqを再起動してもメッセージは失われません。

現在のキュー情報、トピック、継続購読者の情報の閲覧、メッセージ送信など、http://localhost:8161/admin/index.jsp にアクセスできます。

activemq-jdbc.xmlの内容をコピーして修正でき、他のデータベースに保存することもできます。

クズども · 掲載地 2017/01/09 13:41:53

1 キューとトピックの技術的特徴の比較

名前	テーマ	キュー
概要	メッセージを公開購読メッセージを公開	ポイントツーポイント
国家というものは存在しません	トピックデータはデフォルトでステートレスです。	キューデータはデフォルトでMQサーバーにファイルとして保存されます。例えば、Active MQは通常$AMQ_HOME\data\kr-store\dataの下に保存されます。 DBストアとしても設定可能です。
完全性保証	出版社が公開したすべてのデータが購読者に受け入れられる保証はありません。	キューは受信側がすべてのデータを受信できることを保証します。
メッセージが失われるかどうか	一般的に、出版社がトピックにメッセージを公開すると、そのトピックアドレスを聞いているサブだけがメッセージを受け取ることができます。もしサブが聞いていなければ、その話題は失われます。	送信者はターゲットキューにメッセージを送信し、受信者はこのキューで非同期にメッセージを受け取ることができます。受信者がいなくても、キュー上のメッセージは失われません。
メッセージリリース受容ポリシー	1対多のメッセージ公開・受信ポリシーでは、同じトピックアドレスを複数のサブが受信することで、パブリッシャーから送信されるメッセージを受け取ることができます。サブはMQサーバーへの通知を受け取ります	1対1のメッセージ公開・受信ポリシーでは、送信側から送信されたメッセージは1人の受信者のみが受信可能です。受信者が受信した後、MQサーバーは受信を通知し、MQサーバーはキュー内のメッセージを削除または他の処理を行います。

クズども · 掲載地 2017/01/09 13:42:15

トピックとキューの最大の違いは、トピックがブロードキャストの形で、すべてのオンラインリスニングクライアントに新しいメッセージが届いたことを通知し、監視されていないクライアントはメッセージを受け取らないことです。一方、キューは複数のリスニングクライアントのいずれかにピアツーピア方式で通知します。

2 トピックメソッドとキューメソッド間のメッセージ処理効率の比較

リスニングクライアントの同時実行数を増やすことで、リスニングクライアントの同時実行数の増加によってトピックのメッセージプッシュが大幅に減少するかどうかを確認します。

測定された結果から、1人のサブスクライバーと100人のサブスクライバーを前提にトピックメソッドで送信されるメッセージの送受信効率に有意な差はありませんが、500人のサブスクライバー(スレッド)の同時実行を前提とすると効率差は明らかです(500スレッドの同時実行により、私のマシンのCPU使用率は70〜90%に達しているため、ローカルテストによるパフォーマンスボトルネックなのか、トピックメッセージ送信方式のパフォーマンスボトルネックなのか確認できません)。その結果、効率が大幅に低下します。

1人のサブスクライバーと100人のサブスクライバーの前提下では、トピックメソッドとキューモードで送信されるメッセージの送受信効率に有意な差はありませんが、500人の加入者同時進行を前提とすると、トピックモードの効率はキューよりも有意に劣ります。

キュー方式で送信されるメッセージの送受信効率は、1人の加入者、100人の加入者、500人の加入者という前提下でも大きく変わりません。

トピック測定データ:

	送信者が送信したメッセージの総数	すべての加入者が受信したメッセージの総数	メッセージの送受信にかかる平均時間
シングルサブスクライバー	100	100	101ms
100人の加入者	100	10000	103ms
500人の加入者	100	50000	14162ms

キュー測定データ:

	送信者が送信したメッセージの総数	すべての加入者が受信したメッセージの総数	メッセージの送受信にかかる平均時間
シングルサブスクライバー	100	100	96ms
100人の加入者	100	100	96ms
500人の加入者	100	100	100ms

ActiveMQの永続的サブスクリプション設定

関連記事

閲覧したセクション