RocketMQクラスタ構築のチュートリアル

一、RocketMQクラスタ構築

クラスタ計画

名前
brokerロール
IP&port
nameSer-1
サービスセンターの登録
UATコンテナクラスタ-02:9876
nameSer-2
サービスセンターの登録
UATコンテナクラスタ-04:9876
broker-a-0
master
UATコンテナクラスタ-01:10911 broker-a.properties
broker-a-1
slave
UATコンテナクラスタ-04:10911 broker-a-s.properties
broker-b-0
master
UATコンテナクラスタ-03:10911 broker-b.properties
broker-b-1
slave
UATコンテナクラスタ-02:10911 broker-b-s.properties

ソフトウェアパッケージをダウンロードし、対応するディレクトリに解凍します.ダウンロード先:https://github.com/apache/rocketmq/archive/rocketmq-all-4.6.0.tar.gz

起動スクリプト構成のデフォルトbrokerのJVMメモリを8 G、nameSerのJVMメモリを4 Gに変更します.テスト環境にはちょっと贅沢です.したがって,nameSerを1 G,brokerを2 Gに変更する.

[admin@iZbp150aqw850jwlm06qhcZ bin]$ cat runbroker.sh | grep Xms
JAVA_OPT="${JAVA_OPT} -server -Xms2g -Xmx2g -Xmn1g"
[admin@iZbp150aqw850jwlm06qhcZ bin]$ cat runserver.sh | grep Xms
JAVA_OPT="${JAVA_OPT} -server -Xms1g -Xmx1g -Xmn512m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"

broker構成を変更confディレクトリの下にあるbroker-a.properties、broker-a-s.properties、broker-b.properties、broker-b-s.propertiesの4つのファイルに、次の構成を追加します.

[admin@iZbp150aqw850jwlm06qhcZ 2m-2s-async]$ cat broker-a.properties  | grep namesrvAddr
namesrvAddr=UAT    -02:9876;UAT    -04:9876

は、構成を他の3台の機器

にコピーする.

nameSrvおよびbrokerサービス起動nameSrv

# UAT    -02
[admin@iZbp15v1c0o8malwswsdm5Z bin]$ nohup sh mqnamesrv 2>&1 &
# UAT    -04
[admin@iZbp13d7te8727w5phtiskZ bin]$ nohup sh mqnamesrv 2>&1 &

brokerの起動

# UAT    -01
[admin@iZbp150aqw850jwlm06qhcZ bin]nohup sh mqbroker -c /mnt/rocketmq-all-4.6.0-bin-release/conf/2m-2s-async/broker-a.properties 2>&1 &
# UAT    -03
[admin@iZbp13d7te8727w5phtisjZ bin]$ nohup sh mqbroker -c /mnt/rocketmq-all-4.6.0-bin-release/conf/2m-2s-async/broker-b.properties 2>&1 &
# UAT    -02
[admin@iZbp13d7te8727w5phtiskZ bin]$ nohup sh mqbroker -c /mnt/rocketmq-all-4.6.0-bin-release/conf/2m-2s-async/broker-a-s.properties 2>&1 &
# UAT    -04
[admin@iZbp13d7te8727w5phtiskZ bin]$ nohup sh mqbroker -c /mnt/rocketmq-all-4.6.0-bin-release/conf/2m-2s-async/broker-b-s.properties 2>&1 &

では、クラスタが正常に動作しているかどうかをログで確認できます.

tail -f ~/logs/rocketmqlogs/namesrv.log
tail -f ~/logs/rocketmqlogs/broker.log

これでrocketmqクラスタ構築が完了しました.

二、メッセージが失われないことをどのように保証するか

Producerの配達成功を保証します.1.1. デフォルトでは、同期によってブロックされた送信、check SendStatus、ステータスOK、メッセージがBrokerに正常に送信されたことを示し、ステータスがタイムアウトまたは失敗すると、デフォルトの2回の再試行がトリガーされます.このメソッドの送信結果は、Brokerストレージが成功したか、失敗した可能性があります.1.2. トランザクションメッセージの配信方式では,メッセージ100%の配信がBrokerに成功する保証はないが,メッセージ送信Ackが失敗すると,このメッセージはCommitLogに格納されるが,ConsumerQueueには見えない.この異常なメッセージはログに表示することができ、厳密には完全に失われていない(トランザクション・メッセージのコストが非常に高い).RocketMQはqueryMessageを通じて、Brokerストレージが成功したかどうかを問い合わせる

Brokerデータが失われないことを保証します.2.1. メッセージサポートはCommitlogに永続化され、ダウンタイム後に再起動しても未消費のメッセージはロードできる2.2.Broker自身は同期ディスク、非同期ディスクの戦略をサポートし、受信メッセージが必ずローカルのメモリに保存されることを保証する(同期ディスクのコストは非常に高い).Brokerクラスタは1マスタNスレーブのポリシーをサポートし、同期レプリケーションと非同期レプリケーションの方式をサポートし、同期レプリケーションはMasterディスクがクラッシュしてもメッセージが失われないことを保証する(同期ポリシーでは自動マスタスレーブ切り替えができない)

Consumerメッセージが失われないことを保証します.3.1. Consumer自身は持続的なoffset(MessageQueueの中のmin offsetに対応)を維持し、タグが消費に成功したか、brokerに返信したメッセージの下に3.2.Consumerの消費に失敗した場合は、ConsumeConcurrentlyStatusを通過します.RECONSUME_LATERは再試行3.3を行う.Consumerの消費に失敗し、brokerに返信すると、brokerがオフになると、Consumerはこの操作3.4をタイミングよく再試行する.ConsumerとBrokerが一緒に停止した場合、メッセージも失われません.Consumerのoffsetはタイミング的に永続化されているため、再起動後、offsetの前のメッセージをローカル

に引き出し続けます.
Mark他の人の経験:RocketMQ-アーキテクチャ原理RocketMQチュートリアルRocketMQ性能最適化【実戦ノート】なぜRocketMQを選んだのか