NameServer、Zookeeper、違いが分からない

[[386520]]

この記事はWeChatの公開アカウント「大宇賢人」から転載したもので、著者は大宇です。この記事を転載する場合は、大悠仙人の公開アカウントにご連絡ください。

メッセージ キュー RocketMQ は、Apache RocketMQ をベースに Alibaba Cloud が構築した、低レイテンシ、高同時実行性、高可用性、高信頼性を備えた分散メッセージ ミドルウェアです。

RocketMQ はメッセージ キューであることはわかっています。このメッセージ キューは、ブローカー、プロデューサー、コンシューマーなどの複数のコンポーネントに分割されています。では、これらのコンポーネントはどのように相互に対話するのでしょうか。あるいは、どうやってお互いのステータスを取得するのでしょうか?

賢いあなたなら、それが登録センターによって管理されていることをすでに推測していると思います。実は、この記事を書く前に、RocketMQ で NameServer の位置をどのように呼び出すかで苦労していました。

頭脳とも言えますが、完全なコマンドセンターではなく、メッセージを保存することはありません（メッセージはブローカーに保存されます）。脳は、脳と呼ばれる資格を得るためには、これらのものを記憶していなければなりません。脳でなくても、何らかの指令機能を持っています。プロデューサーがメッセージを送信する場合、まずネームサーバーを介してブローカーとトピック間の通信を取得し、ブローカーのアドレス情報を取得してから、ブローカーとの長い接続を維持してメッセージを送信する必要があります。ブローカーとブローカーの間にはハートビート メカニズムもあり、ブローカーの生存状態を維持し、クラスター全体の安定性と可用性を維持します。

したがって、私はネームサーバーを Pseudo-Brain と名付けました。

なんてこった？偽りの脳。本当に脳は存在するのでしょうか？本当の脳とは何でしょうか?

あなたの好奇心が本当に好きです。あなたは学ぶことが大好きな若くて美しい中国人だと思います。はい、私はあなたを不安にさせています。実際、次の記事で説明するブローカーは RocketMQ の中核です。多くの論理制御 (タイミング遅延、セミメッセージ) がここで完了するほか、メッセージを保存するためのファイル、消費オフセットを保存するためのファイルなどもここで完了します。

ネームサーバー

ネームサーバーとは

事実とその背後にある理由を知った上で、ネームサーバーとは一体何なのでしょうか?

NameServer は非常にシンプルなトピック ルーティング登録センターであり、Dubbo の Zookeeper と同様の役割を果たし、ブローカーの動的な登録と検出をサポートします。 NameServer は、ノード間で情報を同期することなくクラスターに展開できる、ほぼステートレスなノードです。

NameServer はトピックとブローカー情報を保存し、Broker は起動時にすべての NameServer に登録します。メッセージを送信する前に、プロデューサーはまずネームサーバーからブローカー アドレス リストを取得し、負荷分散アルゴリズムに従ってリストからブローカー サーバーを選択してメッセージを送信します。

NameServer と Broker は長時間の接続を維持し、30 秒ごとに Broker が稼働しているかどうかを確認します。ブローカーがダウンすると、ルーティング レジストリから削除されます。ルーティングの変更はプロデューサーにすぐには通知されません。これにより、NameServer 実装の複雑さが軽減されます。プロデューサーは、フォールト トレランス メカニズムを使用して、メッセージ送信の高可用性を確保します。

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

コンシューマーは、ネーム サーバー クラスター内のノードの 1 つ (ランダムに選択) と永続的な接続を確立し、ネーム サーバーからトピック ルーティング情報を定期的に取得し、トピック サービスを提供するマスター ノードとスレーブ ノードと永続的な接続を確立し、マスター ノードとスレーブ ノードにハートビートを定期的に送信します。コンシューマーはマスターとスレーブの両方からのメッセージをサブスクライブできます。サブスクリプション ルールはブローカーの構成によって決まります。

ネームサーバー クラスター

RocketMQ クラスターは、オンラインで広く使用されているアーキテクチャです。これは、プロデューサー クラスター、コンシューマー クラスター、ネーム サーバー クラスター、ブローカー クラスターの 4 つの主要コンポーネントに分かれています。 NameServer クラスターはどのようになっているのでしょうか?これは非常に興味深く、他のクラスターとは異なります。その理由を見てみましょう。

私たちが知っているクラスターは、一般的に互いに助け合い、高可用性の役割を果たしています。ほとんどのクラスターはこのようになるはずですが、NameServer クラスターはこのようではありません。率直に言うと、NameServer クラスターは実際には疑似クラスターです。なぜそんなことを言うのですか？

NameServer クラスター内の複数のノードは相互に対話しないため、NameServer クラスターに複数の独立した NameServer マシンを展開するのと同じです。各マシンは独立してクラスターの操作をサポートできます。複数のマシンの役割は、実際にはバックアップの役割です。

ネームサーバー クラスターを展開する方法

NameServer は、クラスター全体のルーティング センターです。これがないと、プロデューサーはどのブローカーにメッセージを配信すればよいかわかりません。それがないと、非常に面倒になります！

高可用性を確保するには、NameServer は複数のデプロイメントをサポートする必要があります。 NameServer が 1 台のマシンにのみ導入されている場合、そのマシンがダウンすると、RocketMQ 全体が停止します。

したがって、複数のマシンを展開すると、いずれかのネームサーバーに障害が発生した場合でも、他のマシン上のネームサーバーが外部に引き続きサービスを提供できるようになります。

NameServer クラスター内のマシンの 1 つがクラッシュした場合はどうなるでしょうか?クラスターへの影響は何ですか?

これは RocketMQ クラスター全体にとって大きな問題ではありません。適切に設計された RocketMQ クラスターでは、NameServer マシンの障害によってクラスター全体が影響を受けたり、クラスターが使用できなくなったりすることはありません。通常、ネームサーバーマシンの障害を報告するための警報システムがあり、対応する運用保守担当者が対応します。

ネームサーバーの役割

NameServer は非常にシンプルなトピック ルーティング登録センターであり、Dubbo の Zookeeper と同様の役割を果たし、ブローカーの動的な登録と検出をサポートします。 NameServer は、ノード間で情報を同期することなくクラスターに展開できる、ほぼステートレスなノードです。

NameServer は、RocketMQ クラスターの登録センターと同様の役割を果たします。まず、NameServer のソース コード アーキテクチャを見てみましょう。

実際、構造は非常にシンプルで複雑ではありません。勉強することに興味があるなら、時間をかけて勉強することができます。ソースコードのアドレスは次のとおりです:

https://github.com/rocketmq

RocketMQ における NameServer の役割は、Dayu によってルート管理、ルート検出、ルート削除という 3 つのカテゴリに大別されており、これもわかりやすいです。さあ、簡単に説明しましょう。

• ルーティング管理は、ブローカーのアクティブリストとトピック間の関係を保存することです。
• ルーティング登録と検出は、トピックに対応するブローカー情報が変更されたときに更新されます（非リアルタイム）
• ルート削除とは、ブローカー マシンがダウンまたはシャットダウンしたときに、対応するルートを自動的に削除することを意味します。

ブローカーとネームサーバーの関係は非常に密接であることがわかっています。単一のブローカーがすべてのネームサーバーとの長い接続を維持します。ブローカーが起動すると、すべてのネームサーバーをポーリングして登録します。

ブローカーは 30 秒ごとにすべてのネームサーバーにハートビートを送信します (この時間は変更できないので覚えておいてください)。ハートビートにはすべてのトピック情報が含まれます。

このことから、ブローカーに含まれるトピックが多すぎてハートビート情報が大きすぎると、ネットワーク転送が遅くなる可能性があることがわかります。

ネームサーバーは、10 秒ごとにすべての存続ブローカーをスキャンします。この時間は変更できません。接続が 2 分以内にハートビート データを送信しない場合 (現在の時刻と最終更新時刻の差が 2 分を超える場合、この時間は変更できません)、接続は切断されます。接続が切断されると、ネームサーバーはそれを感知しますが、感知には若干の遅延が生じます。なぜ遅れるのか説明する必要はないですよね？

次のステップは、topc とキュー間の対応を更新することですが、プロデューサーとコンシューマーには通知されません。

ルーティング管理: ブローカーのアクティブリストとトピックに対応するキューリストを保存します。

NameServer は、マスターとスレーブを含むアクティブなブローカーのリストを保存します。 NameServer は、すべてのトピックとトピックに対応するすべてのキューのリストを保存します。 NameServer はすべてのブローカーのフィルター リストを保存します。

これらはすべてRouteInfoManagerクラスにあります

各属性の名前はその意味を明確に示しています。スレッドセーフでない HashMap を使用できる理由は、HashMap の変更を保護するための読み取り/書き込みロックがあるためです。

ブローカーを保存するためのマップが 2 つあることに気付きました。つまり、brokerAddrTable はすべてのブローカー リストを保存するために使用され、brokerLiveTable は現在アクティブなブローカー リストを保存するために使用されます。一方、BrokerData はブローカーの主な追加を保存するために使用され、BrokerLiveInfo は最後の更新 (ハートビート) 時刻を保存するためにのみ使用されます。

トピックがどのキューを持っているか、これらのキューがどのブローカー上にあるかなど、トピックに関するほぼすべての情報をネーム サーバーで取得できます。

DefaultRequestProcessor は NameServer のデフォルトのリクエスト プロセッサです。これは、ブローカーの登録、ブローカーの登録解除、トピック ルーティングの取得、トピックの削除、ブローカーのトピック権限の取得、NameServer のすべてのトピックの取得など、rocketmq-common モジュールの RequestCode で定義されたいくつかのリクエストを処理します。

ルーティング登録と検出: ブローカーの起動登録とトピック関係の変更

ブローカーは起動時にすべてのネームサーバーにハートビート ステートメントを送信し、30 秒ごとにすべてのネームサーバーにハートビート パケットを送信します。ネームサーバーはハートビート パケットを受信した後、キャッシュを更新します。 NameServer は 10 秒ごとに brokerLiveTable をスキャンします。 120 秒連続してハートビート パケットが受信されない場合、ネーム サーバーはブローカーのルーティング情報を削除し、ソケット接続を閉じます。

ブローカーが起動するとルーティング登録がトリガーされます。ブローカーが起動すると、すべてのネームサーバーとのハートビート接続が作成され、ブローカー関連の情報がネームサーバーに送信されます。 NameServer は、RouteInfoManager クラスでブローカー関連情報のキャッシュを維持し、更新アクションを実行します。更新中は読み取り/書き込みロックが使用され、非常に高い同時実行シナリオでの読み取り効率が保証されるだけでなく、キャッシュの同時変更も回避されます。

ルーティング検出: RocketMQ のルーティング検出はリアルタイムではありません。トピックに対応するルーティング情報が変更された場合、ネームサーバーはクライアントに通知しません。代わりに、クライアントはトピックに対応する最新のルートを定期的にプルします。非リアルタイムのルート検出によって発生する問題はクライアントによって解決され、ネームサーバー ロジックのシンプルさが保証されます。クライアントは、対応する情報を取得するために、定期的にネームサーバーにGET_ROUTEINFO_BY_TOPICのリクエストを送信します。

ルート削除: ブローカーがダウンまたはシャットダウンした場合、対応するルート情報は自動的に削除されます。

ルート削除のトリガー ポイントは 2 つあります。

• NameServer の起動時に開始されるスケジュールされたタスクは、brokerLiveTable を 10 秒ごとにスキャンして、最後のハートビート パケットと現在のシステム時刻の間の時間差を検出します。時間差が 120 秒を超える場合、ブローカー関連の情報は削除されます。
• ブローカーが正常にシャットダウンされると、ネームサーバーに UNREGISTER_BROKER メッセージが送信されます。

実際、RocketMQ は初期の頃、登録センターとして Zookeeper を使用していました。なぜ後から自社開発のネームサーバーに変更したのでしょうか？

この質問についてはあまり多くを語りたくありません。 Zookeeper を理解する必要があるかもしれません。あなたが理解できないなら、私が言ってもあまり意味がありません。

まず、Zookeeper の最も重要な機能はマスターの選出ですが、これは RocketMQ には適していません。考えてみてください。RocketMQ のマスターにはすべてのトピック情報が保存されているわけではないので、マスターを選択しても意味がありません。

第二に、RocketMQ の場合、この登録センターの役割は、関連情報 (ブローカーのアクティブ リスト、トピックの対応情報など) を保存するだけでなく、10 秒ごとにアクティブなブローカーを検出してリストを更新するなど、対応するデータを処理するためのロジックも必要です。これらのロジックを Zookeeper クライアントで処理すると、非常に面倒になります。

したがって、Zookeeper は RocketMQ の重量級の登録センターなので、それを実装するにはシンプルな登録センターを作成する方がよいでしょう。上記のクラスターと同様に、NameServer クラスターは疑似クラスターです。ノード間に対応する相互作用はありません。バックアップの役割のみを果たすため、RocketMQ クラスターの柔軟性が向上します。