RocketMQ --- 基本

1. MQ の概要

1.1. MQ を使用する理由

メッセージ キューは「先入れ先出し」のデータ構造であり、
ここに画像の説明を挿入
その適用シナリオには主に次の 3 つの側面が含まれます。

1.1.1. アプリケーションのデカップリング

システムの結合度が高くなるほど、耐障害性は低くなります。電子商取引アプリケーションを例にとると、ユーザーが注文を作成した後、在庫システム、物流システム、支払いシステムが結合されて呼び出されると、サブシステムに障害が発生したり、アップグレードなどにより一時的に使用できなくなったりした場合、異常な注文操作を引き起こし、ユーザーの使用体験に影響を与えます。
ここに画像の説明を挿入

メッセージキューの分離を使用すると、システムの結合が改善されます。例えば、物流システムが故障した場合、復旧には数分かかりますが、この間に物流システムが処理するデータはメッセージキューにキャッシュされ、ユーザーの注文操作は正常に完了します。物流システムが応答した後は、メッセージ キューに保存されている注文メッセージを補足して処理するだけでよく、端末システムは数分間物流システムの障害に気づきません。
ここに画像の説明を挿入

1.1.2. フローピーククリッピング

アプリケーション システムがシステム要求トラフィックの突然の急増に遭遇すると、システムが圧倒される可能性があります。メッセージ キューを使用すると、大量のリクエストをキャッシュして長期間にわたって処理できるため、システムの安定性とユーザー エクスペリエンスが大幅に向上します。
ここに画像の説明を挿入
一般に、システムの安定性を確保するために、システム負荷がしきい値を超えた場合、ユーザー リクエストはブロックされ、ユーザー エクスペリエンスに影響します。メッセージ キューを使用してリクエストをキャッシュし、システムが要求を待機するのを待つ場合は、処理が完了すると、注文が完了したことがユーザーに通知されます。注文できないよりはマシです。

経済的な目的のため

  • 通常時の業務システムの QPS が 1000 で、ピーク トラフィックが 10000 である場合、ピーク トラフィックに対処するために高性能サーバーを構成することは明らかに費用対効果が低く、このときメッセージ キューを使用できます。ピークトラフィックをカットするために

1.1.3. データの配布

ここに画像の説明を挿入
メッセージキューを介して、複数のシステム間でデータを循環させることができます。データ生成者はデータを誰が使用するかを気にする必要がなく、データをメッセージ キューに送信するだけでよく、データの使用者はメッセージ キュー内のデータを直接取得できます。
ここに画像の説明を挿入

1.2. MQ の長所と短所

利点: デカップリング、ピーククリッピング、データ分散

デメリットとしては以下のようなものが挙げられます。

  • システムの可用性の低下

    システムに導入される外部依存性が増えるほど、システムの安定性は悪化します。MQ がダウンすると、ビジネスに影響が及びます。

    MQ の高可用性を確保するにはどうすればよいですか?

  • システムの複雑さの増加

    MQ の追加により、システムの複雑さが大幅に増加しました。以前はシステム間で同期リモート呼び出しがありましたが、現在は MQ を介して非同期呼び出しが行われます。

    メッセージが繰り返し消費されないようにするにはどうすればよいでしょうか? メッセージ損失にどう対処するか? では、メッセージ配信の順序を確保するにはどうすればよいでしょうか?

  • 一貫性の問題

    A系は業務処理後、MQを通じてB、C、Dの3つの系にメッセージデータを送信し、B系とC系が正常に処理すると、D系は処理に失敗します。

    メッセージ データ処理の一貫性を確保するにはどうすればよいですか?

1.3. 各種 MQ 製品の比較

一般的な MQ 製品には、Kafka、ActiveMQ、RabbitMQ、RocketMQ などがあります。

ここに画像の説明を挿入

2.RocketMQ クイックスタート

RocketMQ は Alibaba の 2016 MQ ミドルウェアであり、Java 言語で開発されており、Alibaba 内部では、「ダブル 11」などの高度な同時実行シナリオでのメッセージ フローを引き受け、兆レベルのメッセージを処理できます。

2.1. 準備

2.1.1. RocketMQ をダウンロードする

ダウンロードアドレス: https: //dlcdn.apache.org/rocketmq/

2.2.2. 環境要件

  • Linux64ビットシステム

  • JDK1.8(64ビット)

  • ソースコードのインストールには Maven 3.2.x をインストールする必要があります

2.2. RocketMQ のインストール

2.2.1. インストール手順

  1. インストールパッケージを解凍します
  2. インストールディレクトリを入力してください

2.2.2. カタログの紹介

  • bin: シェル スクリプトや CMD スクリプトを含む起動スクリプト
  • conf: ブローカー構成ファイル、ログバック構成ファイルなどを含むインスタンス構成ファイル。
  • lib: Netty、commons-lang、FastJSON などの jar パッケージに依存します。

2.3. RocketMQ の起動

2.3.1. ネームサーバーの起動

# 1.启动NameServer
nohup sh bin/mqnamesrv &
# 2.查看启动日志
tail -f ~/logs/rocketmqlogs/namesrv.log

2.3.2. ブローカーの開始

# 1.启动Broker
nohup sh bin/mqbroker -n localhost:9876 &
# 2.查看启动日志
tail -f ~/logs/rocketmqlogs/broker.log 
  • 問題の説明:

    RocketMQ のデフォルトの仮想マシン メモリは比較的大きいため、メモリ不足により Broker の起動に失敗する場合は、次の 2 つの設定ファイルを編集して JVM メモリ サイズを変更する必要があります。

# 编辑runbroker.sh和runserver.sh修改默认JVM大小
vi runbroker.sh
vi runserver.sh
  • 参考設定:
JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m -XX:MetaspaceSize=128m  -XX:MaxMetaspaceSize=320m"

2.4. RocketMQ のテスト

2.4.1. メッセージの送信

# 1.设置环境变量
export NAMESRV_ADDR=localhost:9876
# 2.使用安装包的Demo发送消息
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer

2.4.2. メッセージの受信

# 1.设置环境变量
export NAMESRV_ADDR=localhost:9876
# 2.接收消息
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer

2.5. RocketMQ を閉じる

# 1.关闭NameServer
sh bin/mqshutdown namesrv
# 2.关闭Broker
sh bin/mqshutdown broker

3. RocketMQ クラスターの構築

3.1. 各役割の紹介

  • プロデューサ: メッセージの送信者、例: 送信者
  • コンシューマ: メッセージ受信者; 例: 受信者
  • ブローカー: メッセージの一時保管と送信、例: 郵便局
  • NameServer: 管理ブローカー、例: 各郵便局の管理組織
  • トピック: メッセージのタイプを区別します。送信者は 1 つ以上のトピックにメッセージを送信できます。メッセージの受信者は 1 つ以上のトピック メッセージを購読できます。
  • メッセージ キュー: トピック パーティションに相当し、メッセージを並行して送受信するために使用されます。

ここに画像の説明を挿入

3.2. クラスターの構築方法

3.2.1. クラスターの特徴

  • NameServer は、ノード間で情報を同期せずにクラスターにデプロイできる、ほぼステートレスなノードです。

  • ブローカーの導入は比較的複雑です。ブローカーはマスターとスレーブに分かれています。1 つのマスターは複数のスレーブに対応できますが、1 つのスレーブは 1 つのマスターにのみ対応できます。マスターとスレーブ間の対応関係は、同じ BrokerName と異なる BrokerId を指定することによって定義されます。 BrokerId が 0 の場合はマスターを示し、0 以外の場合はスレーブを示します。マスターは複数展開することもできます。各ブローカーは、ネームサーバー クラスター内のすべてのノードとの永続的な接続を確立し、トピック情報をすべてのネームサーバーに定期的に登録します。

  • プロデューサーは、ネームサーバー クラスター内のノードの 1 つ (ランダムに選択) との長い接続を確立し、ネームサーバーからトピック ルーティング情報を定期的に取得し、トピック サービスを提供するマスターへの長い接続を確立し、マスターに定期的にハートビートを送信します。プロデューサーは完全にステートレスであり、クラスターにデプロイできます。

  • コンシューマは、NameServer クラスタ内のいずれかのノード (ランダムに選択) との長期接続を確立し、定期的に NameServer からトピック ルーティング情報を取得し、トピック サービスを提供するマスターおよびスレーブへの長期接続を確立し、マスターおよびスレーブにハートビートを送信します。定期的に奴隷にする。コンシューマはマスターまたはスレーブからのメッセージをサブスクライブでき、サブスクリプション ルールはブローカー構成によって決定されます。

3.2.2、クラスターモード

3.2.2.1、シングルマスターモード

この方法には危険が伴い、ブローカーが再起動または停止すると、サービス全体が利用できなくなります。オンライン環境での使用は推奨されませんが、ローカル テストには使用できます。

3.2.2.2、マルチマスターモード

クラスターにはスレーブがなく、すべてマスター (2 マスターまたは 3 マスターなど) になります。このモードの長所と短所は次のとおりです。

  • 利点: シンプルな構成、単一マスターのダウンタイムまたは再起動メンテナンスはアプリケーションに影響を与えません。ディスクが RAID10 として構成されている場合、マシンのダウンタイムが回復不能な場合でも、RAID10 ディスクは非常に信頼性が高いため、メッセージは失われません (少量の非同期ブラッシングが失われたメッセージ、1 部分を失うことなくディスクを同期的にブラッシングする)、パフォーマンスは最高です。

  • 短所: 1 台のマシンがダウンすると、そのマシンが回復するまでそのマシン上の未使用のメッセージをサブスクライブできなくなり、メッセージのリアルタイム パフォーマンスが影響を受けます。

3.2.2.3、マルチマスター マルチスレーブ モード (非同期)

各マスターはスレーブを構成し、マスターとスレーブのペアが複数あります。HA は非同期レプリケーション モードを採用しており、マスターとバックアップのメッセージ遅延は短い (ミリ秒レベル)。このモードの長所と短所は次のとおりです。

  • 利点: ディスクが破損した場合でも、メッセージの損失は非常に少なく、メッセージのリアルタイム パフォーマンスには影響しません。同時に、マスターがダウンした後も、コンシューマはスレーブから消費できます。このプロセスはアプリケーションに対して透過的であり、手動介入は必要ありません。また、パフォーマンスは同じです。マスター モードもほぼ同じです。

  • 短所: マスターがダウンしており、ディスクが損傷すると少量のメッセージが失われます。

3.2.2.4、マルチマスター マルチスレーブ モード (同期)

各マスターはスレーブで構成され、マスターとスレーブのペアが複数あります。HA は同期二重書き込み方式を採用しています。つまり、マスターとバックアップの両方が正常に書き込まれた場合にのみ、アプリケーションに成功を返すことができます。 . このモードの長所と短所は次のとおりです。

  • 利点: データとサービスの両方に単一障害点が存在しないため、マスターがダウンしてもメッセージに遅延がなく、サービスの可用性とデータの可用性が非常に高くなります。

  • 欠点: 非同期レプリケーション モードよりもパフォーマンスが若干低く (約 10% 低い)、単一メッセージ送信の RT が若干高くなります。現バージョンでは、マスター ノードがダウンした後、スタンバイ マシンを自動的に切り替えることができません。マスターへ。

3.3. デュアルマスター/デュアルスレーブクラスター構成

3.3.1. 全体構造

メッセージ高可用性は2m-2s(同期二重書き込み)方式を採用
ここに画像の説明を挿入

ここに画像の説明を挿入

3.3.2. クラスターのワークフロー

  1. NameServer を起動します。NameServer が起動すると、ポートを監視し、Broker、Producer、Consumer が接続するのを待ちます。これはルーティング コントロール センターに相当します。

  2. ブローカーが起動し、すべてのネームサーバーとの長時間の接続を維持し、ハートビート パケットを定期的に送信します。ハートビート パケットには現在のブローカー情報 (IP+ポートなど) が含まれており、すべてのトピック情報が保存されます。登録が成功すると、NameServer クラスター内のトピックとブローカーの間にマッピング関係が確立されます。

  3. メッセージを送受信する前に、まずトピックを作成します。トピックを作成するときは、トピックを保存するブローカーを指定する必要があります。メッセージの送信時にトピックを自動的に作成することもできます。

  4. プロデューサーはメッセージを送信します。起動すると、最初にネームサーバー クラスターの 1 つとの長い接続を確立し、現在送信されているトピックが存在するブローカーをネームサーバーから取得し、ポーリングしてキュー リストからキューを選択し、キューが配置されているブローカーとキューを接続します。長い接続ではメッセージがブローカーに送信されます。

  5. Consumer はProducer に似ており、NameServer の 1 つとの長い接続を確立し、現在サブスクライブされているトピックがどの Broker に存在するかを取得し、Broker との接続チャネルを直接確立してメッセージの消費を開始します。

3.3.3. サーバー環境

シリアルナンバー IP 役割 建築パターン
1 192.168.25.135 ネームサーバー、ブローカーサーバー マスター1、スレーブ2
2 192.168.25.138 ネームサーバー、ブローカーサーバー マスター2、スレーブ1

3.3.4、ホスト追加情報

vim /etc/hosts

構成は次のとおりです。

# nameserver
192.168.25.135 rocketmq-nameserver1
192.168.25.138 rocketmq-nameserver2
# broker
192.168.25.135 rocketmq-master1
192.168.25.135 rocketmq-slave2
192.168.25.138 rocketmq-master2
192.168.25.138 rocketmq-slave1

設定が完了したら、ネットワークカードを再起動します。

systemctl restart network

3.3.5、ファイアウォール構成

ホストは、仮想マシンの rocketmq サービスと Web サービスにリモートでアクセスする必要があり、関連するポート番号を開く必要があります。単純かつ失礼な方法は、ファイアウォールを直接閉じることです。

# 关闭防火墙
systemctl stop firewalld.service 
# 查看防火墙的状态
firewall-cmd --state 
# 禁止firewall开机启动
systemctl disable firewalld.service

または、安全のため、特定のポート番号のみが開いており、RocketMQ はデフォルトで 3 つのポート (9876、10911、11011) を使用します。ファイアウォールが閉じられていない場合、ファイアウォールは次のポートを開く必要があります。

  • nameserverポート 9876 がデフォルトで使用されます
  • masterポート 10911 がデフォルトで使用されます
  • slaveポート 11011 がデフォルトで使用されます

次のコマンドを実行します。

# 开放name server默认端口
firewall-cmd --remove-port=9876/tcp --permanent
# 开放master默认端口
firewall-cmd --remove-port=10911/tcp --permanent
# 开放slave默认端口 (当前集群模式可不开启)
firewall-cmd --remove-port=11011/tcp --permanent 
# 重启防火墙
firewall-cmd --reload

3.3.6、環境変数の設定

vim /etc/profile

プロファイルファイルの最後に次のコマンドを追加します。

#set rocketmq
ROCKETMQ_HOME=/usr/local/rocketmq/rocketmq-all-4.4.0-bin-release
PATH=$PATH:$ROCKETMQ_HOME/bin
export ROCKETMQ_HOME PATH

「wq!」と入力して保存して終了し、構成をすぐに有効にします。

source /etc/profile

3.3.7. メッセージストレージパスの作成

mkdir /usr/local/rocketmq/store
mkdir /usr/local/rocketmq/store/commitlog
mkdir /usr/local/rocketmq/store/consumequeue
mkdir /usr/local/rocketmq/store/index

3.3.8、ブローカー設定ファイル

3.3.8.1、マスター1

サーバー: 192.168.25.135

vi /usr/soft/rocketmq/conf/2m-2s-sync/broker-a.properties

次のように構成を変更します。

#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字,注意此处不同的配置文件填写的不一样
brokerName=broker-a
#0 表示 Master,>0 表示 Slave
brokerId=0
#nameServer地址,分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在发送消息时,自动创建服务器不存在的topic,默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic,建议线下开启,线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组,建议线下开启,线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口
listenPort=10911
#删除文件时间点,默认凌晨 4点
deleteWhen=04
#文件保留时间,默认 48 小时
fileReservedTime=120
#commitLog每个文件的大小默认1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每个文件默认存30W条,根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/usr/local/rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SYNC_MASTER
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=SYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128

3.3.8.2、スレーブ2

サーバー: 192.168.25.135

vi /usr/soft/rocketmq/conf/2m-2s-sync/broker-b-s.properties

次のように構成を変更します。

#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字,注意此处不同的配置文件填写的不一样
brokerName=broker-b
#0 表示 Master,>0 表示 Slave
brokerId=1
#nameServer地址,分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在发送消息时,自动创建服务器不存在的topic,默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic,建议线下开启,线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组,建议线下开启,线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口
listenPort=11011
#删除文件时间点,默认凌晨 4点
deleteWhen=04
#文件保留时间,默认 48 小时
fileReservedTime=120
#commitLog每个文件的大小默认1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每个文件默认存30W条,根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/usr/local/rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SLAVE
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=ASYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128

3.3.8.3、マスター2

サーバー: 192.168.25.138

vi /usr/soft/rocketmq/conf/2m-2s-sync/broker-b.properties

次のように構成を変更します。

#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字,注意此处不同的配置文件填写的不一样
brokerName=broker-b
#0 表示 Master,>0 表示 Slave
brokerId=0
#nameServer地址,分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在发送消息时,自动创建服务器不存在的topic,默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic,建议线下开启,线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组,建议线下开启,线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口
listenPort=10911
#删除文件时间点,默认凌晨 4点
deleteWhen=04
#文件保留时间,默认 48 小时
fileReservedTime=120
#commitLog每个文件的大小默认1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每个文件默认存30W条,根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/usr/local/rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SYNC_MASTER
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=SYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128

3.3.8.4、スレーブ1

サーバー: 192.168.25.138

vi /usr/soft/rocketmq/conf/2m-2s-sync/broker-a-s.properties

次のように構成を変更します。

#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字,注意此处不同的配置文件填写的不一样
brokerName=broker-a
#0 表示 Master,>0 表示 Slave
brokerId=1
#nameServer地址,分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在发送消息时,自动创建服务器不存在的topic,默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic,建议线下开启,线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组,建议线下开启,线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口
listenPort=11011
#删除文件时间点,默认凌晨 4点
deleteWhen=04
#文件保留时间,默认 48 小时
fileReservedTime=120
#commitLog每个文件的大小默认1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每个文件默认存30W条,根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/usr/local/rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SLAVE
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=ASYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128

3.3.9、起動スクリプトファイルを変更する

3.3.9.1、runbroker.sh

vi /usr/local/rocketmq/bin/runbroker.sh

メモリ サイズに応じて JVM パラメータを適切に調整する必要があります。

# 开发环境配置 JVM Configuration
JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m"

3.3.9.2、runserver.sh

vim /usr/local/rocketmq/bin/runserver.sh
JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"

3.3.10. サービス開始

3.3.10.1、NameServe クラスターを開始します。

それぞれ 192.168.25.135 と 192.168.25.138 で NameServer を起動します。

cd /usr/local/rocketmq/bin
nohup sh mqnamesrv &

3.3.10.2、ブローカークラスターの開始

  • 192.168.25.135 でマスター 1 とスレーブ 2 を開始します。

マスター1:

cd /usr/local/rocketmq/bin
nohup sh mqbroker -c /usr/local/rocketmq/conf/2m-2s-syncbroker-a.properties &

スレーブ2:

cd /usr/local/rocketmq/bin
nohup sh mqbroker -c /usr/local/rocketmq/conf/2m-2s-sync/broker-b-s.properties &
  • 192.168.25.138 でマスター 2 とスレーブ 2 を起動します。

マスター2

cd /usr/local/rocketmq/bin
nohup sh mqbroker -c /usr/local/rocketmq/conf/2m-2s-sync/broker-b.properties &

スレーブ1

cd /usr/local/rocketmq/bin
nohup sh mqbroker -c /usr/local/rocketmq/conf/2m-2s-sync/broker-a-s.properties &

3.3.11. プロセスステータスの表示

起動後に JPS を通じて起動プロセスを表示する
ここに画像の説明を挿入

3.3.12. ログの表示

# 查看nameServer日志
tail -500f ~/logs/rocketmqlogs/namesrv.log
# 查看broker日志
tail -500f ~/logs/rocketmqlogs/broker.log

3.4、mqadmin管理ツール

3.4.1. 使用法

RocketMQ のインストール場所を入力し、bin ディレクトリで実行します。./mqadmin {command} {args}

3.4.2. コマンドの概要

3.4.2.1、トピック関連

名前 意味 コマンドオプション 説明する
トピックの更新 トピック構成の作成と更新 -b ブローカー アドレスはトピックが存在するブローカーを示し、単一のブローカーのみをサポートし、アドレスは ip:port です。
-c クラスター名。トピックが存在するクラスターを示します (クラスターは、clusterList を通じて照会できます)。
-h- ヘルプを印刷する
-n NameServer サービス アドレス、形式 ip:port
-p 新しいトピックの読み取りおよび書き込み権限を指定します ( W=2|R=4|WR=6 )
-r 読み取り可能なキューの数 (デフォルトは 8)
-w 書き込み可能なキューの数 (デフォルトでは 8)
-t トピック名 (名前には ^[a-zA-Z0-9_-]+$ の文字のみを使用できます)
トピックの削除 トピックの削除 -c クラスター名。クラスターの下のトピックを削除することを意味します (クラスターは、clusterList を通じて照会できます)。
-h ヘルプを印刷する
-n NameServer サービス アドレス、形式 ip:port
-t トピック名 (名前には ^[a-zA-Z0-9_-]+$ の文字のみを使用できます)
トピックリスト トピックリスト情報の表示 -h ヘルプを印刷する
-c -c が構成されていない場合は、トピック リストのみが返され、-c を追加すると、clusterName、トピック、consumerGroup 情報、つまり、トピックが属するクラスターとサブスクリプション関係がパラメーターなしで返されます。
-n NameServer サービス アドレス、形式 ip:port
トピックルート トピックルーティング情報の表示 -t トピック名
-h ヘルプを印刷する
-n NameServer サービス アドレス、形式 ip:port
トピックステータス トピックメッセージキューオフセットの表示 -t トピック名
-h ヘルプを印刷する
-n NameServer サービス アドレス、形式 ip:port
トピッククラスターリスト 查看 Topic 所在集群列表 -t topic 名称
-h 打印帮助
-n NameServer 服务地址,格式 ip:port
updateTopicPerm 更新 Topic 读写权限 -t topic 名称
-h 打印帮助
-n NameServer 服务地址,格式 ip:port
-b Broker 地址,表示 topic 所在 Broker,只支持单台Broker,地址为ip:port
-p 指定新 topic 的读写权限( W=2|R=4|WR=6 )
-c cluster 名称,表示 topic 所在集群(集群可通过 clusterList 查询),-b优先,如果没有-b,则对集群中所有Broker执行命令
updateOrderConf 从NameServer上创建、删除、获取特定命名空间的kv配置,目前还未启用 -h 打印帮助
-n NameServer 服务地址,格式 ip:port
-t topic,键
-v orderConf,值
-m method,可选get、put、delete
allocateMQ 以平均负载算法计算消费者列表负载消息队列的负载结果 -t topic 名称
-h 打印帮助
-n NameServer 服务地址,格式 ip:port
-i ipList,用逗号分隔,计算这些ip去负载Topic的消息队列
statsAll 打印Topic订阅关系、TPS、积累量、24h读写总量等信息 -h 打印帮助
-n NameServer 服务地址,格式 ip:port
-a 是否只打印活跃topic
-t 指定topic

3.4.2.2、集群相关

名称 含义 命令选项 说明
clusterList 查看集群信息,集群、BrokerName、BrokerId、TPS等信息 -m 打印更多信息 (增加打印出如下信息 #InTotalYest, #OutTotalYest, #InTotalToday ,#OutTotalToday)
-h 打印帮助
-n NameServer 服务地址,格式 ip:port
-i 打印间隔,单位秒
clusterRT 发送消息检测集群各Broker RT。消息发往${BrokerName} Topic。 -a amount,每次探测的总数,RT = 总时间 / amount
-s 消息大小,单位B
-c 探测哪个集群
-p 是否打印格式化日志,以|分割,默认不打印
-h 打印帮助
-m 所属机房,打印使用
-i 发送间隔,单位秒
-n NameServer 服务地址,格式 ip:port

3.4.2.3、Broker相关

名称 含义 命令选项 说明
updateBrokerConfig 更新 Broker 配置文件,会修改Broker.conf -b Broker 地址,格式为ip:port
-c cluster 名称
-k key 值
-v value 值
-h 打印帮助
-n NameServer 服务地址,格式 ip:port
brokerStatus 查看 Broker 统计信息、运行状态(你想要的信息几乎都在里面) -b Broker 地址,地址为ip:port
-h 打印帮助
-n NameServer 服务地址,格式 ip:port
brokerConsumeStats Broker中各个消费者的消费情况,按Message Queue维度返回Consume Offset,Broker Offset,Diff,TImestamp等信息 -b Broker 地址,地址为ip:port
-t 请求超时时间
-l diff阈值,超过阈值才打印
-o 是否为顺序topic,一般为false
-h 打印帮助
-n NameServer 服务地址,格式 ip:port
getBrokerConfig 获取Broker配置 -b Broker 地址,地址为ip:port
-n NameServer 服务地址,格式 ip:port
wipeWritePerm 从NameServer上清除 Broker写权限 -b Broker 地址,地址为ip:port
-n NameServer 服务地址,格式 ip:port
-h 打印帮助
cleanExpiredCQ 清理Broker上过期的Consume Queue,如果手动减少对列数可能产生过期队列 -n NameServer 服务地址,格式 ip:port
-h 打印帮助
-b Broker 地址,地址为ip:port
-c 集群名称
cleanUnusedTopic 清理Broker上不使用的Topic,从内存中释放Topic的Consume Queue,如果手动删除Topic会产生不使用的Topic -n NameServer 服务地址,格式 ip:port
-h 打印帮助
-b Broker 地址,地址为ip:port
-c 集群名称
sendMsgStatus 向Broker发消息,返回发送状态和RT -n NameServer 服务地址,格式 ip:port
-h 打印帮助
-b BrokerName,注意不同于Broker地址
-s 消息大小,单位B
-c 发送次数

3.4.2.4、消息相关

名称 含义 命令选项 说明
queryMsgById 根据offsetMsgId查询msg,如果使用开源控制台,应使用offsetMsgId,此命令还有其他参数,具体作用请阅读QueryMsgByIdSubCommand。 -i msgId
-h 打印帮助
-n NameServer 服务地址,格式 ip:port
queryMsgByKey 根据消息 Key 查询消息 -k msgKey
-t Topic 名称
-h 打印帮助
-n NameServer 服务地址,格式 ip:port
queryMsgByOffset 根据 Offset 查询消息 -b Broker 名称,(这里需要注意 填写的是 Broker 的名称,不是 Broker 的地址,Broker 名称可以在 clusterList 查到)
-i query 队列 id
-o offset 值
-t topic 名称
-h 打印帮助
-n NameServer 服务地址,格式 ip:port
queryMsgByUniqueKey 根据msgId查询,msgId不同于offsetMsgId,区别详见常见运维问题。-g,-d配合使用,查到消息后尝试让特定的消费者消费消息并返回消费结果 -h 打印帮助
-n NameServer 服务地址,格式 ip:port
-i uniqe msg id
-g consumerGroup
-d clientId
-t topic名称
checkMsgSendRT 检测向topic发消息的RT,功能类似clusterRT -h 打印帮助
-n NameServer 服务地址,格式 ip:port
-t topic名称
-a 探测次数
-s 消息大小
sendMessage 发送一条消息,可以根据配置发往特定Message Queue,或普通发送。 -h 打印帮助
-n NameServer 服务地址,格式 ip:port
-t topic名称
-p body,消息体
-k keys
-c tags
-b BrokerName
-i queueId
consumeMessage 消费消息。可以根据offset、开始&结束时间戳、消息队列消费消息,配置不同执行不同消费逻辑,详见ConsumeMessageCommand。 -h 打印帮助
-n NameServer 服务地址,格式 ip:port
-t topic名称
-b BrokerName
-o 从offset开始消费
-i queueId
-g 消费者分组
-s 开始时间戳,格式详见-h
-d 结束时间戳
-c 消费多少条消息
printMsg 从Broker消费消息并打印,可选时间段 -h 打印帮助
-n NameServer 服务地址,格式 ip:port
-t topic名称
-c 字符集,例如UTF-8
-s subExpress,过滤表达式
-b 开始时间戳,格式参见-h
-e 结束时间戳
-d 是否打印消息体
printMsgByQueue 类似printMsg,但指定Message Queue -h 打印帮助
-n NameServer 服务地址,格式 ip:port
-t topic名称
-i queueId
-a BrokerName
-c 字符集,例如UTF-8
-s subExpress,过滤表达式
-b 开始时间戳,格式参见-h
-e 结束时间戳
-p 是否打印消息
-d 是否打印消息体
-f 是否统计tag数量并打印
resetOffsetByTime 按时间戳重置offset,Broker和consumer都会重置 -h 打印帮助
-n NameServer 服务地址,格式 ip:port
-g 消费者分组
-t topic名称
-s 重置为此时间戳对应的offset
-f 是否强制重置,如果false,只支持回溯offset,如果true,不管时间戳对应offset与consumeOffset关系
-c 是否重置c++客户端offset

3.4.2.5、消费者、消费组相关

名称 含义 命令选项 说明
consumerProgress 查看订阅组消费状态,可以查看具体的client IP的消息积累量 -g 消费者所属组名
-s 是否打印client IP
-h 打印帮助
-n NameServer 服务地址,格式 ip:port
consumerStatus 查看消费者状态,包括同一个分组中是否都是相同的订阅,分析Process Queue是否堆积,返回消费者jstack结果,内容较多,使用者参见ConsumerStatusSubCommand -h 打印帮助
-n NameServer 服务地址,格式 ip:port
-g consumer group
-i clientId
-s 是否执行jstack
getConsumerStatus 获取 Consumer 消费进度 -g 消费者所属组名
-t 查询主题
-i Consumer 客户端 ip
-n NameServer 服务地址,格式 ip:port
-h 打印帮助
updateSubGroup 更新或创建订阅关系 -n NameServer 服务地址,格式 ip:port
-h 打印帮助
-b Broker地址
-c 集群名称
-g 消费者分组名称
-s 分组是否允许消费
-m 是否从最小offset开始消费
-d 是否是广播模式
-q 重试队列数量
-r 最大重试次数
-i 当slaveReadEnable开启时有效,且还未达到从slave消费时建议从哪个BrokerId消费,可以配置备机id,主动从备机消费
-w 如果Broker建议从slave消费,配置决定从哪个slave消费,配置BrokerId,例如1
-a 当消费者数量变化时是否通知其他消费者负载均衡
deleteSubGroup 从Broker删除订阅关系 -n NameServer 服务地址,格式 ip:port
-h 打印帮助
-b Broker地址
-c 集群名称
-g 消费者分组名称
cloneGroupOffset 在目标群组中使用源群组的offset -n NameServer 服务地址,格式 ip:port
-h 打印帮助
-s 源消费者组
-d 目标消费者组
-t topic名称
-o 暂未使用

3.4.2.6、连接相关

名称 含义 命令选项 说明
consumerConnec tion 查询 Consumer 的网络连接 -g 消费者所属组名
-n NameServer 服务地址,格式 ip:port
-h 打印帮助
producerConnec tion 查询 Producer 的网络连接 -g 生产者所属组名
-t 主题名称
-n NameServer 服务地址,格式 ip:port
-h 打印帮助

3.4.2.7、NameServer相关

名称 含义 命令选项 说明
updateKvConfig 更新NameServer的kv配置,目前还未使用 -s 命名空间
-k key
-v value
-n NameServer 服务地址,格式 ip:port
-h 打印帮助
deleteKvConfig 删除NameServer的kv配置 -s 命名空间
-k key
-n NameServer 服务地址,格式 ip:port
-h 打印帮助
getNamesrvConfig 获取NameServer配置 -n NameServer 服务地址,格式 ip:port
-h 打印帮助
updateNamesrvConfig 修改NameServer配置 -n NameServer 服务地址,格式 ip:port
-h 打印帮助
-k key
-v value

3.2.4.8、其他

名称 含义 命令选项 说明
startMonitoring 开启监控进程,监控消息误删、重试队列消息数等 -n NameServer 服务地址,格式 ip:port
-h 打印帮助

3.4.3、注意事项

  • 几乎所有命令都需要配置-n表示NameServer地址,格式为ip:port

  • 几乎所有命令都可以通过-h获取帮助

  • 如果既有Broker地址(-b)配置项又有clusterName(-c)配置项,则优先以Broker地址执行命令;如果不配置Broker地址,则对集群中所有主机执行命令

3.5、集群监控平台搭建

3.5.1、概述

RocketMQ有一个对其扩展的开源项目incubator-rocketmq-externals,这个项目中有一个子模块叫rocketmq-console,这个便是管理控制台项目了,先将incubator-rocketmq-externals拉到本地,因为我们需要自己对rocketmq-console进行编译打包运行。

3.5.2、下载并编译打包

git clone https://github.com/apache/rocketmq-externals
cd rocketmq-console
mvn clean package -Dmaven.test.skip=true

注意:打包前在rocketmq-console中配置namesrv集群地址:

rocketmq.config.namesrvAddr=192.168.25.135:9876;192.168.25.138:9876

启动rocketmq-console:

java -jar rocketmq-console-ng-1.0.0.jar

启动成功后,我们就可以通过浏览器访问http://localhost:8080进入控制台界面了,如下图:
ここに画像の説明を挿入
集群状态:
ここに画像の説明を挿入

四、消息发送样例

  • 导入MQ客户端依赖
<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-client</artifactId>
    <version>4.4.0</version>
</dependency>
  • 消息发送者步骤分析
1.创建消息生产者producer,并制定生产者组名
2.指定Nameserver地址
3.启动producer
4.创建消息对象,指定主题Topic、Tag和消息体
5.发送消息
6.关闭生产者producer
  • 消息消费者步骤分析
1.创建消费者Consumer,制定消费者组名
2.指定Nameserver地址
3.订阅主题Topic和Tag
4.设置回调函数,处理消息
5.启动消费者consumer

4.1、基本样例

4.1.1、消息发送

4.1.1.1、发送同步消息

这种可靠性同步地发送方式使用的比较广泛,比如:重要的消息通知,短信通知。

public class SyncProducer {
    
    
	public static void main(String[] args) throws Exception {
    
    
    	// 实例化消息生产者Producer
        DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
    	// 设置NameServer的地址
    	producer.setNamesrvAddr("localhost:9876");
    	// 启动Producer实例
        producer.start();
    	for (int i = 0; i < 100; i++) {
    
    
    	    // 创建消息,并指定Topic,Tag和消息体
    	    Message msg = new Message("TopicTest" /* Topic */,
        	"TagA" /* Tag */,
        	("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */
        	);
        	// 发送消息到一个Broker
            SendResult sendResult = producer.send(msg);
            // 通过sendResult返回消息是否成功送达
            System.out.printf("%s%n", sendResult);
    	}
    	// 如果不再发送消息,关闭Producer实例。
    	producer.shutdown();
    }
}

4.1.1.2、发送异步消息

异步消息通常用在对响应时间敏感的业务场景,即发送端不能容忍长时间地等待Broker的响应。

public class AsyncProducer {
    
    
	public static void main(String[] args) throws Exception {
    
    
    	// 实例化消息生产者Producer
        DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
    	// 设置NameServer的地址
        producer.setNamesrvAddr("localhost:9876");
    	// 启动Producer实例
        producer.start();
        producer.setRetryTimesWhenSendAsyncFailed(0);
    	for (int i = 0; i < 100; i++) {
    
    
                final int index = i;
            	// 创建消息,并指定Topic,Tag和消息体
                Message msg = new Message("TopicTest",
                    "TagA",
                    "OrderID188",
                    "Hello world".getBytes(RemotingHelper.DEFAULT_CHARSET));
                // SendCallback接收异步返回结果的回调
                producer.send(msg, new SendCallback() {
    
    
                    @Override
                    public void onSuccess(SendResult sendResult) {
    
    
                        System.out.printf("%-10d OK %s %n", index,
                            sendResult.getMsgId());
                    }
                    @Override
                    public void onException(Throwable e) {
    
    
      	              System.out.printf("%-10d Exception %s %n", index, e);
      	              e.printStackTrace();
                    }
            	});
    	}
    	// 如果不再发送消息,关闭Producer实例。
    	producer.shutdown();
    }
}

4.1.1.3、单向发送消息

这种方式主要用在不特别关心发送结果的场景,例如日志发送。

public class OnewayProducer {
    
    
	public static void main(String[] args) throws Exception{
    
    
    	// 实例化消息生产者Producer
        DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
    	// 设置NameServer的地址
        producer.setNamesrvAddr("localhost:9876");
    	// 启动Producer实例
        producer.start();
    	for (int i = 0; i < 100; i++) {
    
    
        	// 创建消息,并指定Topic,Tag和消息体
        	Message msg = new Message("TopicTest" /* Topic */,
                "TagA" /* Tag */,
                ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */
        	);
        	// 发送单向消息,没有任何返回结果
        	producer.sendOneway(msg);

    	}
    	// 如果不再发送消息,关闭Producer实例。
    	producer.shutdown();
    }
}

4.1.2、消费消息

4.1.2.1、负载均衡模式

消费者采用负载均衡方式消费消息,多个消费者共同消费队列消息,每个消费者处理的消息不同

public static void main(String[] args) throws Exception {
    
    
    // 实例化消息生产者,指定组名
    DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("group1");
    // 指定Namesrv地址信息.
    consumer.setNamesrvAddr("localhost:9876");
    // 订阅Topic
    consumer.subscribe("Test", "*");
    //负载均衡模式消费
    consumer.setMessageModel(MessageModel.CLUSTERING);
    // 注册回调函数,处理消息
    consumer.registerMessageListener(new MessageListenerConcurrently() {
    
    
        @Override
        public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
                                                        ConsumeConcurrentlyContext context) {
    
    
            System.out.printf("%s Receive New Messages: %s %n", 
                              Thread.currentThread().getName(), msgs);
            return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
        }
    });
    //启动消息者
    consumer.start();
    System.out.printf("Consumer Started.%n");
}

4.1.2.2、广播模式

消费者采用广播的方式消费消息,每个消费者消费的消息都是相同的

public static void main(String[] args) throws Exception {
    
    
    // 实例化消息生产者,指定组名
    DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("group1");
    // 指定Namesrv地址信息.
    consumer.setNamesrvAddr("localhost:9876");
    // 订阅Topic
    consumer.subscribe("Test", "*");
    //广播模式消费
    consumer.setMessageModel(MessageModel.BROADCASTING);
    // 注册回调函数,处理消息
    consumer.registerMessageListener(new MessageListenerConcurrently() {
    
    
        @Override
        public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
                                                        ConsumeConcurrentlyContext context) {
    
    
            System.out.printf("%s Receive New Messages: %s %n", 
                              Thread.currentThread().getName(), msgs);
            return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
        }
    });
    //启动消息者
    consumer.start();
    System.out.printf("Consumer Started.%n");
}

4.2、顺序消息

消息有序指的是可以按照消息的发送顺序来消费(FIFO)。RocketMQ可以严格的保证消息有序,可以分为分区有序或者全局有序。

顺序消费的原理解析,在默认的情况下消息发送会采取Round Robin轮询方式把消息发送到不同的queue(分区队列);而消费消息的时候从多个queue上拉取消息,这种情况发送和消费是不能保证顺序。但是如果控制发送的顺序消息只依次发送到同一个queue中,消费的时候只从这个queue上依次拉取,则就保证了顺序。当发送和消费参与的queue只有一个,则是全局有序;如果多个queue参与,则为分区有序,即相对每个queue,消息都是有序的。

下面用订单进行分区有序的示例。一个订单的顺序流程是:创建、付款、推送、完成。订单号相同的消息会被先后发送到同一个队列中,消费时,同一个OrderId获取到的肯定是同一个队列。

4.2.1、顺序消息生产

/**
* Producer,发送顺序消息
*/
public class Producer {
    
    

   public static void main(String[] args) throws Exception {
    
    
       DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");

       producer.setNamesrvAddr("127.0.0.1:9876");

       producer.start();

       String[] tags = new String[]{
    
    "TagA", "TagC", "TagD"};

       // 订单列表
       List<OrderStep> orderList = new Producer().buildOrders();

       Date date = new Date();
       SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
       String dateStr = sdf.format(date);
       for (int i = 0; i < 10; i++) {
    
    
           // 加个时间前缀
           String body = dateStr + " Hello RocketMQ " + orderList.get(i);
           Message msg = new Message("TopicTest", tags[i % tags.length], "KEY" + i, body.getBytes());

           SendResult sendResult = producer.send(msg, new MessageQueueSelector() {
    
    
               @Override
               public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
    
    
                   Long id = (Long) arg;  //根据订单id选择发送queue
                   long index = id % mqs.size();
                   return mqs.get((int) index);
               }
           }, orderList.get(i).getOrderId());//订单id

           System.out.println(String.format("SendResult status:%s, queueId:%d, body:%s",
               sendResult.getSendStatus(),
               sendResult.getMessageQueue().getQueueId(),
               body));
       }

       producer.shutdown();
   }

   /**
    * 订单的步骤
    */
   private static class OrderStep {
    
    
       private long orderId;
       private String desc;

       public long getOrderId() {
    
    
           return orderId;
       }

       public void setOrderId(long orderId) {
    
    
           this.orderId = orderId;
       }

       public String getDesc() {
    
    
           return desc;
       }

       public void setDesc(String desc) {
    
    
           this.desc = desc;
       }

       @Override
       public String toString() {
    
    
           return "OrderStep{" +
               "orderId=" + orderId +
               ", desc='" + desc + '\'' +
               '}';
       }
   }

   /**
    * 生成模拟订单数据
    */
   private List<OrderStep> buildOrders() {
    
    
       List<OrderStep> orderList = new ArrayList<OrderStep>();

       OrderStep orderDemo = new OrderStep();
       orderDemo.setOrderId(15103111039L);
       orderDemo.setDesc("创建");
       orderList.add(orderDemo);

       orderDemo = new OrderStep();
       orderDemo.setOrderId(15103111065L);
       orderDemo.setDesc("创建");
       orderList.add(orderDemo);

       orderDemo = new OrderStep();
       orderDemo.setOrderId(15103111039L);
       orderDemo.setDesc("付款");
       orderList.add(orderDemo);

       orderDemo = new OrderStep();
       orderDemo.setOrderId(15103117235L);
       orderDemo.setDesc("创建");
       orderList.add(orderDemo);

       orderDemo = new OrderStep();
       orderDemo.setOrderId(15103111065L);
       orderDemo.setDesc("付款");
       orderList.add(orderDemo);

       orderDemo = new OrderStep();
       orderDemo.setOrderId(15103117235L);
       orderDemo.setDesc("付款");
       orderList.add(orderDemo);

       orderDemo = new OrderStep();
       orderDemo.setOrderId(15103111065L);
       orderDemo.setDesc("完成");
       orderList.add(orderDemo);

       orderDemo = new OrderStep();
       orderDemo.setOrderId(15103111039L);
       orderDemo.setDesc("推送");
       orderList.add(orderDemo);

       orderDemo = new OrderStep();
       orderDemo.setOrderId(15103117235L);
       orderDemo.setDesc("完成");
       orderList.add(orderDemo);

       orderDemo = new OrderStep();
       orderDemo.setOrderId(15103111039L);
       orderDemo.setDesc("完成");
       orderList.add(orderDemo);

       return orderList;
   }
}

4.2.2、顺序消费消息

/**
* 顺序消息消费,带事务方式(应用可控制Offset什么时候提交)
*/
public class ConsumerInOrder {
    
    

   public static void main(String[] args) throws Exception {
    
    
       DefaultMQPushConsumer consumer = new 
           DefaultMQPushConsumer("please_rename_unique_group_name_3");
       consumer.setNamesrvAddr("127.0.0.1:9876");
       /**
        * 设置Consumer第一次启动是从队列头部开始消费还是队列尾部开始消费<br>
        * 如果非第一次启动,那么按照上次消费的位置继续消费
        */
       consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);

       consumer.subscribe("TopicTest", "TagA || TagC || TagD");

       consumer.registerMessageListener(new MessageListenerOrderly() {
    
    

           Random random = new Random();

           @Override
           public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs, ConsumeOrderlyContext context) {
    
    
               context.setAutoCommit(true);
               for (MessageExt msg : msgs) {
    
    
                   // 可以看到每个queue有唯一的consume线程来消费, 订单对每个queue(分区)有序
                   System.out.println("consumeThread=" + Thread.currentThread().getName() + "queueId=" + msg.getQueueId() + ", content:" + new String(msg.getBody()));
               }

               try {
    
    
                   //模拟业务逻辑处理中...
                   TimeUnit.SECONDS.sleep(random.nextInt(10));
               } catch (Exception e) {
    
    
                   e.printStackTrace();
               }
               return ConsumeOrderlyStatus.SUCCESS;
           }
       });

       consumer.start();

       System.out.println("Consumer Started.");
   }
}

4.3、延时消息

比如电商里,提交了一个订单就可以发送一个延时消息,1h后去检查这个订单的状态,如果还是未付款就取消订单释放库存。

4.3.1、启动消息消费者

public class ScheduledMessageConsumer {
    
    
   public static void main(String[] args) throws Exception {
    
    
      // 实例化消费者
      DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("ExampleConsumer");
      // 订阅Topics
      consumer.subscribe("TestTopic", "*");
      // 注册消息监听者
      consumer.registerMessageListener(new MessageListenerConcurrently() {
    
    
          @Override
          public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> messages, ConsumeConcurrentlyContext context) {
    
    
              for (MessageExt message : messages) {
    
    
                  // Print approximate delay time period
                  System.out.println("Receive message[msgId=" + message.getMsgId() + "] " + (System.currentTimeMillis() - message.getStoreTimestamp()) + "ms later");
              }
              return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
          }
      });
      // 启动消费者
      consumer.start();
  }
}

4.3.2、发送延时消息

public class ScheduledMessageProducer {
    
    
   public static void main(String[] args) throws Exception {
    
    
      // 实例化一个生产者来产生延时消息
      DefaultMQProducer producer = new DefaultMQProducer("ExampleProducerGroup");
      // 启动生产者
      producer.start();
      int totalMessagesToSend = 100;
      for (int i = 0; i < totalMessagesToSend; i++) {
    
    
          Message message = new Message("TestTopic", ("Hello scheduled message " + i).getBytes());
          // 设置延时等级3,这个消息将在10s之后发送(现在只支持固定的几个时间,详看delayTimeLevel)
          message.setDelayTimeLevel(3);
          // 发送消息
          producer.send(message);
      }
       // 关闭生产者
      producer.shutdown();
  }
}

4.3.3、验证

您将会看到消息的消费比存储时间晚10秒

4.3.4、使用限制

// org/apache/rocketmq/store/config/MessageStoreConfig.java
private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";

现在RocketMq并不支持任意时间的延时,需要设置几个固定的延时等级,从1s到2h分别对应着等级1到18

4.4、批量消息

批量发送消息能显著提高传递小消息的性能。限制是这些批量消息应该有相同的topic,相同的waitStoreMsgOK,而且不能是延时消息。此外,这一批消息的总大小不应超过4MB。

4.4.1、发送批量消息

如果您每次只发送不超过4MB的消息,则很容易使用批处理,样例如下:

String topic = "BatchTest";
List<Message> messages = new ArrayList<>();
messages.add(new Message(topic, "TagA", "OrderID001", "Hello world 0".getBytes()));
messages.add(new Message(topic, "TagA", "OrderID002", "Hello world 1".getBytes()));
messages.add(new Message(topic, "TagA", "OrderID003", "Hello world 2".getBytes()));
try {
    
    
   producer.send(messages);
} catch (Exception e) {
    
    
   e.printStackTrace();
   //处理error
}

如果消息的总长度可能大于4MB时,这时候最好把消息进行分割

public class ListSplitter implements Iterator<List<Message>> {
    
    
   private final int SIZE_LIMIT = 1024 * 1024 * 4;
   private final List<Message> messages;
   private int currIndex;
   public ListSplitter(List<Message> messages) {
    
    
           this.messages = messages;
   }
    @Override 
    public boolean hasNext() {
    
    
       return currIndex < messages.size();
   }
   	@Override 
    public List<Message> next() {
    
    
       int nextIndex = currIndex;
       int totalSize = 0;
       for (; nextIndex < messages.size(); nextIndex++) {
    
    
           Message message = messages.get(nextIndex);
           int tmpSize = message.getTopic().length() + message.getBody().length;
           Map<String, String> properties = message.getProperties();
           for (Map.Entry<String, String> entry : properties.entrySet()) {
    
    
               tmpSize += entry.getKey().length() + entry.getValue().length();
           }
           tmpSize = tmpSize + 20; // 增加日志的开销20字节
           if (tmpSize > SIZE_LIMIT) {
    
    
               //单个消息超过了最大的限制
               //忽略,否则会阻塞分裂的进程
               if (nextIndex - currIndex == 0) {
    
    
                  //假如下一个子列表没有元素,则添加这个子列表然后退出循环,否则只是退出循环
                  nextIndex++;
               }
               break;
           }
           if (tmpSize + totalSize > SIZE_LIMIT) {
    
    
               break;
           } else {
    
    
               totalSize += tmpSize;
           }

       }
       List<Message> subList = messages.subList(currIndex, nextIndex);
       currIndex = nextIndex;
       return subList;
   }
}
//把大的消息分裂成若干个小的消息
ListSplitter splitter = new ListSplitter(messages);
while (splitter.hasNext()) {
    
    
  try {
    
    
      List<Message>  listItem = splitter.next();
      producer.send(listItem);
  } catch (Exception e) {
    
    
      e.printStackTrace();
      //处理error
  }
}

4.5、过滤消息

在大多数情况下,TAG是一个简单而有用的设计,其可以来选择您想要的消息。例如:

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("CID_EXAMPLE");
consumer.subscribe("TOPIC", "TAGA || TAGB || TAGC");

消费者将接收包含TAGA或TAGB或TAGC的消息。但是限制是一个消息只能有一个标签,这对于复杂的场景可能不起作用。在这种情况下,可以使用SQL表达式筛选消息。SQL特性可以通过发送消息时的属性来进行计算。在RocketMQ定义的语法下,可以实现一些简单的逻辑。下面是一个例子:

------------
| message  |
|----------|  a > 5 AND b = 'abc'
| a = 10   |  --------------------> Gotten
| b = 'abc'|
| c = true |
------------
------------
| message  |
|----------|   a > 5 AND b = 'abc'
| a = 1    |  --------------------> Missed
| b = 'abc'|
| c = true |
------------

4.5.1、SQL基本语法

RocketMQ只定义了一些基本语法来支持这个特性。你也可以很容易地扩展它。

  • 数值比较,比如:>,>=,<,<=,BETWEEN,=;
  • 字符比较,比如:=,<>,IN;
  • IS NULL 或者 IS NOT NULL;
  • 逻辑符号 AND,OR,NOT;

常量支持类型为:

  • 数值,比如:123,3.1415;
  • 字符,比如:‘abc’,必须用单引号包裹起来;
  • NULL,特殊的常量
  • 布尔值,TRUEFALSE

只有使用push模式的消费者才能用使用SQL92标准的sql语句,接口如下:

public void subscribe(finalString topic, final MessageSelector messageSelector)

4.5.2、消息生产者

发送消息时,你能通过putUserProperty来设置消息的属性

DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
producer.start();
Message msg = new Message("TopicTest",
   tag,
   ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET)
);
// 设置一些属性
msg.putUserProperty("a", String.valueOf(i));
SendResult sendResult = producer.send(msg);

producer.shutdown();

4.5.3、消息消费者

用MessageSelector.bySql来使用sql筛选消息

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name_4");
// 只有订阅的消息有这个属性a, a >=0 and a <= 3
consumer.subscribe("TopicTest", MessageSelector.bySql("a between 0 and 3");
consumer.registerMessageListener(new MessageListenerConcurrently() {
    
    
   @Override
   public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
    
    
       return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
   }
});
consumer.start();

4.6、事务消息

4.6.1、流程分析

ここに画像の説明を挿入

上图说明了事务消息的大致方案,其中分为两个流程:正常事务消息的发送及提交、事务消息的补偿流程。

4.6.1.1、事务消息发送及提交

(1) 发送消息(half消息)。

(2) 服务端响应消息写入结果。

(3) 根据发送结果执行本地事务(如果写入失败,此时half消息对业务不可见,本地逻辑不执行)。

(4) 根据本地事务状态执行Commit或者Rollback(Commit操作生成消息索引,消息对消费者可见)

4.6.1.2、事务补偿

(1) 对没有Commit/Rollback的事务消息(pending状态的消息),从服务端发起一次“回查”

(2) Producer收到回查消息,检查回查消息对应的本地事务的状态

(3) 根据本地事务状态,重新Commit或者Rollback

其中,补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。

4.6.1.3、事务消息状态

事务消息共有三种状态,提交状态、回滚状态、中间状态:

  • TransactionStatus.CommitTransaction: 提交事务,它允许消费者消费此消息。
  • TransactionStatus.RollbackTransaction: 回滚事务,它代表该消息将被删除,不允许被消费。
  • TransactionStatus.Unknown: 中间状态,它代表需要检查消息队列来确定状态。

4.6.2、发送事务消息

4.6.2.1、创建事务性生产者

使用 TransactionMQProducer类创建生产者,并指定唯一的 ProducerGroup,就可以设置自定义线程池来处理这些检查请求。执行本地事务后、需要根据执行结果对消息队列进行回复。回传的事务状态在请参考前一节。

public class Producer {
    
    
    public static void main(String[] args) throws MQClientException, InterruptedException {
    
    
        //创建事务监听器
        TransactionListener transactionListener = new TransactionListenerImpl();
        //创建消息生产者
        TransactionMQProducer producer = new TransactionMQProducer("group6");
        producer.setNamesrvAddr("192.168.25.135:9876;192.168.25.138:9876");
        //生产者这是监听器
        producer.setTransactionListener(transactionListener);
        //启动消息生产者
        producer.start();
        String[] tags = new String[]{
    
    "TagA", "TagB", "TagC"};
        for (int i = 0; i < 3; i++) {
    
    
            try {
    
    
                Message msg = new Message("TransactionTopic", tags[i % tags.length], "KEY" + i,
                        ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET));
                SendResult sendResult = producer.sendMessageInTransaction(msg, null);
                System.out.printf("%s%n", sendResult);
                TimeUnit.SECONDS.sleep(1);
            } catch (MQClientException | UnsupportedEncodingException e) {
    
    
                e.printStackTrace();
            }
        }
        //producer.shutdown();
    }
}

4.6.2.2、实现事务的监听接口

当发送半消息成功时,我们使用 executeLocalTransaction 方法来执行本地事务。它返回前一节中提到的三个事务状态之一。checkLocalTranscation 方法用于检查本地事务状态,并回应消息队列的检查请求。它也是返回前一节中提到的三个事务状态之一。

public class TransactionListenerImpl implements TransactionListener {
    
    

    @Override
    public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
    
    
        System.out.println("执行本地事务");
        if (StringUtils.equals("TagA", msg.getTags())) {
    
    
            return LocalTransactionState.COMMIT_MESSAGE;
        } else if (StringUtils.equals("TagB", msg.getTags())) {
    
    
            return LocalTransactionState.ROLLBACK_MESSAGE;
        } else {
    
    
            return LocalTransactionState.UNKNOW;
        }

    }

    @Override
    public LocalTransactionState checkLocalTransaction(MessageExt msg) {
    
    
        System.out.println("MQ检查消息Tag【"+msg.getTags()+"】的本地事务执行结果");
        return LocalTransactionState.COMMIT_MESSAGE;
    }
}

4.6.3、使用限制

  1. 事务消息不支持延时消息和批量消息。

  2. 1 つのメッセージが何度もチェックされることによって引き起こされるセミキュー メッセージの蓄積を避けるために、デフォルトでは 1 つのメッセージのチェック回数を 15 回に制限していますが、ユーザーはブローカーのパラメータを通じてこの制限を変更できます。設定ファイルtransactionCheckMaxメッセージが N 回 (N = transactionCheckMax) を超えてチェックされた場合、デフォルトでは、ブローカーはメッセージを破棄し、同時にエラー ログを出力します。ユーザーはAbstractTransactionCheckListenerクラスをオーバーライドすることでこの動作を変更できます。

  3. トランザクション メッセージは、ブローカー構成ファイル内のパラメータtransactionMsgTimeoutなどの一定の時間が経過した後にチェックされます。トランザクション メッセージを送信するとき、ユーザーはユーザー属性 CHECK_IMMUNITY_TIME_IN_SECONDS を設定することによってこの制限を変更することもできます。これはパラメーターよりも優先されますtransactionMsgTimeout

  4. トランザクション メッセージは複数回検査または消費される場合があります。

  5. ユーザーのターゲット トピックへのメッセージの送信は失敗する可能性があり、現在はログに記録されています。その高可用性は、RocketMQ 独自の高可用性メカニズムによって保証されています。トランザクション メッセージが失われないようにし、トランザクションの整合性を保証したい場合は、同期二重書き込みメカニズムを使用することをお勧めします。

  6. トランザクション メッセージのプロデューサー ID は、他の種類のメッセージのプロデューサー ID と共有できません。他のタイプのメッセージとは異なり、トランザクション メッセージでは逆クエリが可能であり、MQ サーバーはプロデューサ ID を介してコンシューマにクエリを実行できます。

おすすめ

転載: blog.csdn.net/shuai_h/article/details/130895199