RocketMQ ソースコード解析——プロデューサー

メッセージ送信コードの実装

以下は、プロデューサーがメッセージを送信する(同期送信)デモです。

画像.png

主にいくつかのことを行いました。

  • プロデューサ (DefaultMQProducer) オブジェクトを初期化する
  • ネームサーバーのアドレスを設定します
  • プロデューサーを開始する
  • メッセージを送ります

メッセージ送信者がプロセスを開始します

画像.png

DefaultMQProducerImpl类start()

画像.png

構成を確認してください

DefaultMQProducerImpl

画像.png

MQ クライアント インスタンスを取得する

JVM 全体には MQClientManager インスタンスが 1 つだけあり、MQClientInstance キャッシュ テーブルが維持されます。DefaultMQProducerImpl クラス start()

画像.png

clientId は MQClientInstance を 1 つだけ作成します

画像.png

clientId 生成ルール: IP@インスタンス名@ユニット名

画像.png

RocketMQ では、メッセージ送信者とメッセージ消費者は両方とも「クライアント」です。各クライアントは MQClientInstance であり、各 ClientConfig はインスタンスに対応します。

異なるプロデューサとコンシューマが同じクライアント構成 (ClientConfig) を参照する場合、それらは MQClientInstance インスタンスを共有します。したがって、定義する際にはこの問題に注意する必要があります(プロデューサーとコンシューマーのグループ名が同じ場合、この問題が発生しやすくなります)。

画像.png

インスタンスを開始する

MQClientInstance クラス start()

画像.png

スケジュールされたタスク

MQClientInstance の startScheduledTask()

画像.png

プロデューサーメッセージ送信処理

プロデューサのケースのコードからわかるように、DefaultMQProducerImpl の sendDefaultImpl() は、プロデューサ メッセージを送信するためのコア メソッドです。

画像.png

画像.png

コア メソッドから、メッセージ送信は、メッセージの検証、ルートの検索、キューの選択、メッセージの送信の 4 つのステップで構成されていることがわかります。

画像.png

画像.png

キューの選択

デフォルトで選択されたキューポリシー

最も単純なポーリングアルゴリズムを採用しており、各 Queue キューへのメッセージ配信数ができるだけ均等になるという優れた特徴を持っています。このアルゴリズムは基本的に、メッセージ配信プロセス中に再試行が発生しない限り、各 Queue キュー内のメッセージ配信数が可能な限り均等になることを保証します。もちろん、最初の配信が失敗するなど、配信中に問題が発生した場合は、クラスター状態のブローカーがダウンしている可能性が高いため、配信を再試行して問題を回避します。この設定もより合理的です。

障害遅延メカニズム戦略*

この戦略を採用した後、RocketMQ は、ブローカーへの送信が成功または異常終了するたびに、ボーカーの利用可能時間を計算し (送信終了時間 - 送信開始時間、失敗は 30 秒として計算されます)、送信時のフィルタリングを容易にするために保存します。次回です。

画像.png

ブローカーがメッセージを送信する時間の長さを記録することに加えて、ブローカーが利用できない時間の長さを計算することも必要です。ここでは経験値が使用されています。

送信時間が550ms以内の場合、利用不可時間は0となります。

550msに到達、30秒間は利用不可

1000msに達すると、使用不可時間は60秒になります

2000msに達すると、使用不可時間は120秒になります

3000msに達すると、使用不可時間は180秒になります

15000ms に達しました。600S では使用できません

画像.png

画像.png

上記のブローカー回避情報を使用すると、メッセージの送信が非常に簡単になります。

障害遅延メカニズム戦略を有効にする手順は次のとおりです。

  1. メッセージキューリストに従ってローテーショントレーニングを実行する
  2. キューを選択してください
  3. キューが配置されているブローカーが利用可能かどうかを確認します。
  4. 使用可能な場合、キューが返され、キュー選択ロジックが終了します。
  5. 利用できない場合は、ステップ 2 に進みます。
  6. どちらも利用できない場合は、ランダムにどちらかを選択します

コードは以下のように表示されます。

画像.png

2 つの戦略の選択

この戦略から、デフォルトのキュー選択がポーリング戦略であるのに対し、障害遅延選択キューはメッセージ送信時間を優先するキューであることが明確にわかります。では、どうやって選べばいいのでしょうか?

まず第一に、RocketMQ にはデフォルトの送信失敗に対する再試行戦略があります。デフォルトは 2 です。つまり、別のブローカーへの送信が 3 回失敗すると、このメッセージの送信は失敗します。RocketMQ としては、確実に送信できるように最善を尽くす必要があります。メッセージが正常に送信されたことを示します。そこで、以下のような提案がなされます。

ネットワークが比較的良好な場合は、ネットワークの問題による送信失敗の可能性が比較的低いため、デフォルトの戦略をお勧めします。

ネットワークがあまり良好でない場合は、障害遅延メカニズムを推奨します。メッセージ キューを選択するとき、RocketMQ が一定期間内に利用できないと判断したブローカーを除外し、ダウンしたブローカーへのメッセージの継続的な送信を回避し、メッセージ送信を有効にします。 . 高可用性。

もちろん、上記が当てはまる条件は、トピックが 2 つ以上のブローカーに基づいて作成されることです。

テクノロジーのハイライト: ThreadLocal

画像.png

画像.png

画像.png

おすすめ

転載: blog.csdn.net/qq_28314431/article/details/133035661
おすすめ