ActiveMQ メッセージ サービスを構築するための Docker 学習方法の手順

序文

ActiveMQ は、Apache が開発した最も人気があり強力なオープン ソース メッセージ バスです。 ActiveMQ は、JMS1.1 および J2EE 1.4 仕様を完全にサポートする JMS プロバイダー実装です。JMS 仕様は長い間導入されてきましたが、今日の J2EE アプリケーションでは JMS が依然として特別な役割を果たしています。

実稼働プロジェクトでは、分散システム間の通信にメッセージ ミドルウェアが必要になることがよくあります。低結合、信頼性の高い配信、ブロードキャスト、フロー制御、最終的な一貫性などの一連の機能を備えています。この記事では、主に ActiveMQ の概念とインストール手順を紹介します。その後、スパイク メッセージ キューを実装するための SpringBoot 統合に焦点を当てます。

コンセプト

JMS メッセージ モード

ポイントツーポイントまたはキューモード

メッセージ キュー (Queue)、送信者 (Sender)、受信者 (Receiver) の 3 つの役割が含まれます。各メッセージは特定のキューに送信され、受信者はキューからメッセージを取得します。キューは、メッセージが消費されるかタイムアウトになるまでメッセージを保持します。

• 各メッセージには 1 つのコンシューマーのみがあり、つまり、一度消費されると、メッセージはメッセージ キューに存在しなくなります。
• 送信者と受信者の間には時間依存性はありません。つまり、送信者がメッセージを送信する場合、受信者が実行中かどうかは、キューに送信されるメッセージには影響しません。
• メッセージを正常に受信した後、受信者はキューに正常に応答する必要があります。

パブリッシュ/サブスクライブ

トピック、パブリッシャー、サブスクライバーの 3 つのロールが含まれます。複数のパブリッシャーがトピックにメッセージを送信し、システムはこれらのメッセージを複数のサブスクライバーに配信します。

• 各メッセージには複数のコンシューマーが存在する可能性がある
• パブリッシャーとサブスクライバーの間には時間的な依存関係があります。トピックのサブスクライバーの場合、パブリッシャーのメッセージを使用する前にサブスクライバーを作成する必要があります。
• メッセージを消費するには、サブスクライバーが実行され続ける必要があります。

このような厳密な時間依存性を緩和するために、JMS ではサブスクライバーが永続サブスクリプションを作成できるようにしています。この方法では、サブスクライバーがアクティブ化されていない (実行されていない) 場合でも、パブリッシャーからメッセージを受信できます。

送信されたメッセージを一切処理しない、1 人の送信者のみによって処理する、または複数のコンシューマーによって処理する場合は、Pub/Sub モデルを使用できます。

JMSメッセージの基本コンポーネント

接続ファクトリー

Connection オブジェクトを作成するためのファクトリは 2 つあります。2 つの異なる JMS メッセージ モデル用の QueueConnectionFactory と TopicConnectionFactory です。 ConnectionFactory オブジェクトは JNDI を通じて見つかります。

行き先

宛先とは、メッセージ プロデューサーのメッセージの宛先、またはメッセージ コンシューマーのメッセージのソースを意味します。メッセージ プロデューサーの場合、その宛先はキューまたはトピックです。メッセージ コンシューマーの場合、その宛先もキューまたはトピック (つまり、メッセージのソース) です。

したがって、Destination は実際には Queue と Topic の 2 種類のオブジェクトです。Destination は JNDI を通じて見つけることができます。

繋がり

接続は、クライアントと JMS システム (TCP/IP ソケットのラッパー) の間に確立されたリンクを表します。接続は 1 つ以上のセッションを生成できます。 ConnectionFactory と同様に、Connection にも QueueConnection と TopicConnection の 2 つのタイプがあります。

セッション

セッションはメッセージを操作するためのインターフェースです。プロデューサー、コンシューマー、メッセージなどはセッションを通じて作成できます。セッションはトランザクション機能を提供します。セッションを使用して複数のメッセージを送受信する必要がある場合は、これらの送受信アクションをトランザクションに組み込むことができます。同様に、QueueSession と TopicSession にも分割されます。

メッセージのプロデューサー

メッセージ プロデューサーはセッションによって作成され、宛先にメッセージを送信するために使用されます。同様に、メッセージ プロデューサーには QueueSender と TopicPublisher の 2 種類があります。メッセージを送信するには、メッセージ プロデューサーのメソッド (send メソッドまたは publish メソッド) を呼び出すことができます。

メッセージコンシューマー

メッセージ コンシューマーは、宛先に送信されたメッセージを受信するためにセッションによって作成されます。 2 つのタイプ: QueueReceiver と TopicSubscriber。それぞれセッションの createReceiver(Queue) または createSubscriber(Topic) を通じて作成できます。もちろん、セッションの createDurableSubscriber メソッドを使用して永続サブスクライバーを作成することもできます。

メッセージリスナー

メッセージリスナー。メッセージ リスナーが登録されている場合、メッセージが到着すると、リスナーの onMessage メソッドが自動的に呼び出されます。 EJB の MDB (Message-Driven Bean) は MessageListener の一種です。

輸送

ActiveMQ は現在、VM トランスポート、TCP トランスポート、NIO トランスポート、SSL トランスポート、ピア トランスポート、UDP トランスポート、マルチキャスト トランスポート、HTTP および HTTPS トランスポート、WebSocket トランスポート、フェイルオーバー トランスポート、ファンアウト トランスポート、検出トランスポート、ZeroConf トランスポートなどのトランスポートをサポートしています。

• VM トランスポート: クライアントとブローカーが VM 内で直接通信できるようにします。使用される接続はソケット接続ではなく、直接メソッド呼び出しであるため、ネットワーク転送のオーバーヘッドを回避できます。アプリケーション シナリオも、同じ JVM 環境内のブローカーとクライアントに限定されます。
• TCP トランスポート: クライアントは TCP ソケットを介してリモート ブローカーに接続します。設定構文:
• tcp://ホスト名:ポート?トランスポートオプション
• HTTP および HTTPS トランスポート: クライアントが REST または Ajax を使用して接続できるようにします。つまり、Javascript を使用して ActiveMQ にメッセージを直接送信することが可能になります。
• WebSocket トランスポート: クライアントが HTML5 標準の WebSocket を介してブローカーに接続できるようにします。
• フェールオーバー トランスポート: Qinglong System MQ はこの接続方法を使用します。この方法には自動再接続メカニズムがあり、他のトランスポート層上で動作して信頼性の高い伝送を確立します。任意の数の URI を構成することができ、メカニズムは自動的にそのうちの 1 つを選択して接続を試行します。設定構文:
• フェイルオーバー:(tcp://localhost:61616,tcp://localhost:61617,.....)?transportOptions
• ファンアウト トランスポート: 主に、プロダクション メッセージを複数のエージェントに送信するのに適しています。複数のブローカーにループがある場合、コンシューマーは重複したメッセージを受信する可能性があります。したがって、このプロトコルを使用する場合は、切断された複数のブローカーにメッセージを送信するのが最適です。

持続性

AMQ メッセージ ストア

ActiveMQ 5.0 のデフォルトの永続ストレージ方法。

カハ・パーシスタンス

これはメッセージの永続化に特化したソリューションです。一般的なメッセージング使用パターンに合わせて最適化されています。

JDBC 永続性

現在サポートされているデータベースは、Apache Derby、Axion、DB2、HSQL、Informix、MaxDB、MySQL、Oracle、Postgresql、SQLServer、Sybase です。

永続性を無効にする

永続ストレージは使用されません。

クラスターソリューション（マスター/スレーブ）

純粋なマスタースレーブ

• 単一障害点なし。
• 共有ファイルシステムや共有データベースに依存する必要はありません。永続ストレージには KahaDB を使用します。
• マスターはスレーブを 1 つだけ持つことができます。
• マスターの動作中、メッセージのステータスはスレーブに自動的に同期されます。
• マスターがクラッシュすると、スレーブが自動的にその作業を引き継ぎ、送信されてまだ消費されていないメッセージは引き続き有効になります。
• スレーブが引き継いだ後、スレーブを停止して以前のマスターを再起動する必要があります。

共有ファイルシステム マスター スレーブ

JDBC マスター スレーブ

• 構成上、マスターとスレーブの区別はありません。データ ソースを共有する複数のブローカーが JDBC マスター スレーブを構成します。
• 最初にリソース (データベース ロック) を取得したブローカーがマスターになり、他のブローカーは定期的にリソースを取得しようとします。
• マスターがクラッシュすると、他のブローカーがリソースを奪取し、そのうち 1 つだけが成功してすぐにマスターになります。以前のマスターが正常に再起動したとしても、スレーブとして待機することしかできません。

インストール手順

ここでのインストールには Docker が使用され、Docker イメージをクエリします。

docker 検索 activemq

Docker イメージをダウンロードします。

docker pull webcenter/activemq

ActiveMQ コンテナを作成して実行します。

docker run -d --name myactivemq -p 61617:61616 -p 8162:8161 webcenter/activemq

61616 は activemq コンテナが使用するポート (61617 にマップ)、8161 は Web ページ管理ポート (外部では 8162 にマップ)

作成されたコンテナを確認します。存在する場合、インストールは成功です。

ドッカーps

WEB管理ページを表示:

ブラウザに http://ip:8162 と入力し、「ActiveMQ ブローカーの管理」をクリックして、デフォルトのアカウント/パスワード: admin/admin を使用して表示します。

アクセスパスワードを設定する

Docker コンテナに入ります:

docker exec -it myactivemq /bin/bash

コンソール インターフェイスでユーザー名とパスワードを設定します。

# ルートディレクトリのconfディレクトリにあるvi jetty-realm.properties

# パスワードの変更# ユーザー名: パスワード [,ロール名 ...]
管理者: 管理者、管理者

接続パスワードを設定する

activemq.xml ファイルを編集し、shutdownHooks の下に配置します。

<!-- ActiveMQ にアクセスするためのアカウントとパスワードを追加します-->
<プラグイン>
  <シンプル認証プラグイン>
    <ユーザー>
      <authenticationUser ユーザー名="${activemq.username}" パスワード="${activemq.password}" グループ="users,admins"/>
    </ユーザー>
  </シンプル認証プラグイン>
</プラグイン>

パスワードを設定するには、conf 内の credentials.properties ファイルを変更します。

activemq.username=管理者
アクティブMQパスワード=123456
ゲストパスワード=123456

予防

クラウドサーバーの場合は、関連するポート（61617/8160）を開くことを忘れないでください。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。