インタビューで Redis クラスターについて質問され、死ぬまで拷問されました...
- 咔咔オリジナル
- 2020-08-28 17:23:421892ブラウズ
❝Sentinel は主に、自動的に回復できない単一ノードの障害に対するソリューションです。クラスターは主に、単一ノードの容量、同時実行性の問題、および線形スケーラビリティに対するソリューションです。この記事では、公式の Redis クラスターが提供されます。記事の最後で、必要な SSH バックグラウンドを設定できます!
❞
#序文
❝カカはインタビューガイドを作成するためのロードマップをまとめ、そのロードマップに従って記事を書く準備をしました。ナレッジ ポイントが追加されていないことがわかりました。追加してください。パートナーの方々の追加協力も楽しみにしています。コメント エリアでお会いしましょう!
❞
メインコンテンツこの記事の内容 次の側面を中心にクラスターを紹介します。
クラスターの概要 -
クラスター機能 クラスターの構成 手動および自動フェイルオーバー フェイルオーバーの原則
##この記事の実装環境
- centos 7.3
- redis 4.0
- redis 作業ディレクトリ /usr/local/redis
- すべての操作は仮想マシン シミュレーションで実行されます
1. クラスターの概要
クラスターは、単一マシンのメモリ制限の問題を解決します。クラウド サービスのメモリが 256GB である場合、このメモリに達すると、Redis はサービスを提供できなくなります。同時に、データ量がこの点に達すると、その量は書き込まれるデータの量は非常に大きくなり、バッファ オーバーフローが容易に発生し、ノードからの無制限のフル コピーが発生する可能性があります。マスターとスレーブが正常に動作していません。
次に、単一マシンのマスター/スレーブを多対多モードに変更する必要があります。すべてのマスター ノード これらはすべて一緒に接続されており、相互に通信します。この方法では、単一マシンのメモリを共有できるだけでなく、リクエストを分散してシステムの可用性を向上させることもできます。
図に示すように、大量の書き込みリクエストがあった場合、単一のマスターノードに命令が送信されるのではなく、各マスターノードに命令が分散されてメモリを共有します。大量のリクエストを回避します。
それでは、命令はどのように迂回され、保存されるのでしょうか?クラスターのストレージ構造について詳しく知る必要があります。 
2. クラスタ機能
単一のストレージ容量を分散します。マシンを拡張しながら簡単に拡張することもできます。 単一マシンからのアクセス要求の分散 システムの可用性の向上
システムの可用性向上の考え方 可用性に関しては、下の図を見てください。master1 がダウンしても、システムへの影響はそれほど大きくなく、通常のサービスが提供されます。
この時点で、master1 がダウンしたときにクラスターはどのように動作するのかと尋ねる人がいるでしょう。この質問は、以下のフェイルオーバーで答えられます。この問題については、原則の章で詳しく説明します
#3. クラスターのストレージ構造
1. ストレージ構造
単一マシンのストレージでは、ユーザーがリクエストを開始した後、キーがそのマシン自体のメモリに直接保存されます。クラスターのストレージ構造はそれほど単純ではありません。まず、ユーザーがキー コマンドを開始したときに何を行う必要があるかです。 
- CRC16 (キー) を通じて値が計算されます。
- この値を 16384 で割った法を使用して値を取得します。最初は 28 であると考えられます。
- この値 28 は、キーが保存されるスペースの場所です。
16384 の部分に分割し、各ホストがその部分を保存します。
専門用語「ハッシュ スロット」) に相当することに注意してください。数値として理解できます。建物の内部にある建物は、redis の保管場所全体です。各家の数は保管場所に相当します。この保管場所には、モデルを取り込んだ後の位置ではなく、対応するキーを保存するための一定の領域があります。上の写真です。
この時点で、マシンを追加または削除した場合はどうすればよいかという疑問が生じます。写真を見て話してください。写真を使って説明できる場合は言葉を使わないようにしましょう。
新しいマシンを追加すると、他の 3 つのストレージ スペースから特定のスロットが新しいマシンに割り当てられます。ここで、新しいマシンに搭載するスロットの数を設定できます。
同様に、マシンを削減した後、削除されたスロットは他の既存のマシンに再割り当てされ、新しいノードを追加するのと同じように、スロットを受け取るノードを指定できます。
いわゆるノードの追加または削除は、スロットが格納されている場所を変更することを意味します。 
クラスターのストレージ構造を理解した後は、クラスター内の内部通信をどのように設計するかという別の質問について説明する必要があります。値が到着し、キーが取得され、データをどこで取得するかについては、以下で説明します。
#2. 通信設計
#クラスター内の各ノードは、一定期間内に他のノードに ping を送信します。メッセージが送信されると、他のノードは応答として pong を返します。一定の時間が経過すると、すべてのノードはクラスター内のすべてのノードのスロット情報を認識します。
下の図には 3 つのノードがあり、16384 個のハッシュ スロットは 3 つの部分に分割されます。
はそれぞれ 0 ～ 5500、5501 ～ 11000、11001 ～ 16384 です。
ユーザーがキー要求を開始すると、クラスターはその要求をどのように処理しますか?
下の図の黒いボックスは、クラスター内のすべてのノードのスロット情報を表しており、その中には他にも多くの情報が含まれています。 
図に示すように、ユーザーがキーのリクエストを開始すると、redis はそれを受信すると、キーのスロット位置を計算し、スロット位置に基づいて対応するノードを見つけます。
アクセスされたスロットがノード自体にある場合、キーに対応するデータが直接返されます。それ以外の場合は、移動リダイレクト エラーで応答し、正しいノードをクライアントに返します。
その後、キー コマンドを再送信します
4. クラスターの構成
##1. 構成ファイルの変更
クリックサークル内の構成情報にのみ注意する必要があります
cluster-enabled yes: クラスター モードを有効にする cluster-config-file names-6379.conf: クラスター設定ファイル clustre-node-timeout 10000: ノード タイムアウト。ここではテストの便宜のために 10 秒に設定されています
2. 6 つのノードの構成ファイルを構築し、すべてを開始します
提供してくださいファイルを簡単に置き換えることができるコマンド sed 's/6379/6380/g' 6379-redis.conf > 6380-redis.conf
このように作成します の設定ファイル6 つの異なるポート
任意の構成ファイルを開いて表示し、置換が成功したかどうかを確認します
ログ情報を表示しやすくするために、すべてがフォアグラウンドで開始されます。 ps -ef | grep redis
コマンドを実行して、サービスが正常に起動しているかどうかを確認します。起動後に追加のクラスター識別子があることがわかります。クラスター内のノード。 
すべてのノードが起動されました。クラスターの起動手順は Ruby に基づく必要があります (Kaka は Redis バージョン 4.0 を使用します)。次に、一緒にインストールします
3. Ruby のインストール
コマンド実行wget https://cache.ruby-lang.org/pub /ruby/2.7/ruby-2.7.1.tar.gz
解凍: tar -xvzf Ruby-2.7.1.tar.gz ダウンロードしたバージョンに応じて解凍します。
インストール:./configure | make | make installこれら 3 つの手順は一度で完了します。
Ruby と gem のバージョンを確認します: ruby -v
#4. クラスターを開始しますクラスターの実行コマンドは
/usr/local/redis/src/redis-trib.rb## を使用する必要がある場合に注意してください。 #redis-trib を直接使用します。rb
./redis-trib.rb メソッドを使用する必要があります。 手順通りに進めると、ここでエラーが表示されます実行
残念ながら、ここでもエラーが表示されます。 
その後、yum install zlib-devel と 
yum install openssl-devel をインストールする必要があります。
インストールが完了したら、/ruby-2.7.1/ext/openssl および /ruby-2.7.1/ext/zlib## にある ruby extconf.rb を実行します。 そして make | make install
gem install redis を実行すれば OK ですこの時点で、戻って、 
./redis -trib.rb create --replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384# を実行します。 ##「メッセージの解釈」
##クラスターを作成し、6 つのノードにハッシュ スロットを割り当てます。最後の 3 つのノードは、最初の 3 つのノードのスレーブ ノードとして構成されます。ハッシュを表示します。各ノードのスロット情報とノード ID。最後のステップで、
と入力して、データ ディレクトリ内の構成ファイルの変更を表示する必要があります。構成ファイルの主な情報は、各マスター ノードに割り当てられたスロットです。
「ホスト ポイントの実行ログを表示する」
ここに示される主な情報は、クラスターのステータスが変更されました: ok クラスターのステータスは正常です
##5. クラスターの設定とデータの取得
データを直接設定するとエラーとなり、ネームキー変換後のスロット位置は5798となり、IPアドレスとポート番号が与えられます。コマンドを使用する必要があります
redis-cli -c
次に、データがあれば自動的に切り替わります。 
1. クラスター スレーブ ノードオフライン#上記のクラスター起動情報によると、ポート 6383 が 6379 のスレーブ ノードであることがわかります。
次のステップでは、6383 をオフラインにして 6379 のログ情報を表示します。
6379 は、接続 6383 が失われたことを報告し、接続が使用できないことを示す失敗としてマークされます。現時点では、クラスターはまだ正常に動作しています。
「要約: スレーブ ノードからオフラインになってもクラスターには影響しません。」 
ポート 6383 がオンラインになると、すべてのノードが失敗マークをクリアします
2. クラスター マスター ノードがオフラインになります
#マスター ノード 6379 を手動でオフラインにし、スレーブのログ情報を確認しますノード 6383
この時点で、ノード 6383 は合計 10 回、6379 に接続し続けます。ではなぜ10倍なのか！
これは、構成したパラメータ cluster-node-timeout 10 に基づいて決定されます。ここで提供される情報は、時間が経過するまで
1 秒に 1 回接続し、その後フェイルオーバーを開始することです。
この時点で、6383 はフェイルオーバー選出に成功し、スレーブが切り替わってマスター ノードになりました。 
このとき、コマンド clusternodes でクラスターのノード情報を確認します。
ここには 4 つのマスター ノードがありますが、マスター ノードの 1 つがオフラインであることがわかります。
「6379 の元のマスター ノードがオンラインになります」
6379 以降オンラインになると、すべてのノードも障害情報をクリアします。
そしてノード情報も変わりますが、このとき6379が6383のスレーブノードに変わります。 
#3. 新しいマスター ノードを追加します##2 つの新しいポート 6385 と 6386 を追加します
実行新しいコマンド./redis-trib.rb add-node 127.0.0.1:6385 127.0.0.1:6379
、ここに送信されるのは Meet メッセージです add-node コマンドを実行します。最初のパラメータは新しいノードの IP ポートで、2 番目のパラメータはクラスタ内にすでに存在するノードです。以下の図によると、新しく追加されたノードがすでにクラスター内に存在していることがわかります。
次に、クラスター内の一部のハッシュ スロットをこの新しいノードに割り当てる必要があります。割り当てが完了すると、このノードが実際のマスター ノードになります
コマンドを実行します
は、転送するハッシュ スロットの数を要求し、受信ノードの
を入力します。最後のステップでは、転送するかどうかを尋ねます。すべてのノードから: Kaka は
を使用します<p data-tool="mdnice编辑器" style="padding-top: 8px; padding-bottom: 8px; line-height: 26px; margin-top: 10px; margin-bottom: 10px; font-size: 14px; word-spacing: 2px;">コマンドを使用します: <code style="overflow-wrap: break-word; margin: 0px 2px; font-family: " operator mono consolas monaco menlo monospace word-break: break-all color: rgb background: rgba padding: border-radius: height: line-height:>クラスター ノード ノード 6385 にすでに 3 つの範囲のハッシュ スロットがあることを確認します
「マスター ノードが追加されました。その後、次の操作を行う必要があります。」マスター ノード 6385" のスレーブ ノード 6386 を構成します。
コマンド: ./redis-trib.rb add-node --slave --master-id dcc0ec4d0c932ac5c35ae76af4f9c5d27a422d9f 127.0.0.1:6386 127.0 .0.1:6385
master-id は 6385 の ID です。最初のパラメータは新しいノードの IP ポート、2 番目のパラメータは指定されたマスター ノードの IP ポートです。
#4. 手動障害移行
#クラスター内のマスター ノードをアップグレードする場合は、手動で次の手順を実行できます。障害移行 クラスターの可用性への影響を避けるために、スレーブ ノードに移動します。 スレーブ ノードでコマンドを実行します:クラスター フェイルオーバー
「実行プロセス」
ノード情報を表示すると、 can see 6386 このノードはマスターポイントになりました。 クラスター フェイルオーバー コマンドがスレーブ ノードに送信されると、スレーブ ノードは CLUSTERMSG_TYPE_MFSTART パケットをマスター ノードに送信します。スレーブ ノードはマスター ノードにアクセスの停止を要求し、両者のデータ オフセットが一致するようにします。このとき、クライアントは削除されたマスター ノードに接続しません。同時に、マスター ノードはレプリケーション オフセットをスレーブ ノードに送信します。スレーブ ノードがレプリケーション オフセットを取得した後、フェイルオーバーが開始され、その後、クライアントが古いマスターでロックを解除され、新しいマスター ノードに再接続されると、マスター ノードに構成の切り替えを実行するように通知されます。 
6. フェイルオーバーの原則
上記では、フェイルオーバーをテストしました。スレーブ ノードがマスター ノードになる次に、このプロセスを分析します。
1. 障害の発見から確認まで
クラスター内の各ノードは、他のノードに定期的に ping メッセージを送信します。受信機はポンで応答します。
クラスターノードタイムアウト時間内に ping メッセージが失敗し続ける場合、受信ノードは pfail ステータス、つまり主観的にオフラインとしてマークされます。
このオフライン ステータスはよく知られていますか?はい、これは監視員がマスターノードに異常があるかどうかを判断するのと似ています。センチネルはマスター ノードの問題を検出すると、マスター ノードを客観的にオフライン (s_down) としてマークします。突然、話が逸れたことに気付きました。恥ずかしいです...
センチネルについて言及させてください。センチネルがマスター ノードが異常であると判断すると、主観的にオフラインとマークされます。しかし、他の人はどうすればよいでしょうか。番兵が同意しますか? 同意できません。言われたことは言われたことです。センチネルの半数以上がマスター ノードが異常であると判断した場合、客観的に見てマスター ノードを直接オフラインにします。
同様に、クラスターは、ノードのせいでステータスがオフラインであると判断するだけではありません。ノードはゴシップ メッセージを通じて直接伝播されます。クラスター内のノードは、障害のあるノードのオフライン フィードバックを継続的に収集し、保存します。ローカルの障害のあるノードの下にあります。クラスタ マスター ノードの半分以上が主観的にオフラインとしてマークされると、ステータスは客観的にオフラインに変わります。
最後に、障害メッセージがクラスターにブロードキャストされ、障害が発生したノードを客観的にオフラインとしてマークするようすべてのノードに通知されます。
例: ノード A はノード B に ping を送信し、通信異常後にノード B を pfail としてマークします。その後、ノード A はノード C に ping を送信し続け、ノード B の pfail 情報を伝えます。その後、ノード Cノード B の障害をオフラインで保存します。オフライン レポートの数がハッシュ スロットを持つマスター ノードの数の半分を超える場合、客観的にオフラインになろうとします。
2. 障害回復 (それ以降、スレーブ ノードが切り替わり、スレーブが歌います)
障害ノードが対象ノードとして定義されている場合 オフライン後、障害ノードのすべてのスレーブノードが障害回復の責任を負います。
障害回復は、スケジュールされたタスクを通じてホスト ポイントが客観的にオフラインであることをスレーブ ノードが検出した後に実行される障害回復プロセスです。
『1. 資格チェック』
すべてのスレーブ ノードはマスター ノードとの最後の接続時間を確認し、切断時間がクラスターノード時間よりも長いかを確認します。 *cluster -slave-validity-factor はフェイルオーバーの対象になりません。
『2. 選挙の準備期間』
まず、なぜ選挙には準備期間があるのかについてお話しましょう。
資格チェック後に複数のスレーブ ノードがある場合は、優先順位をサポートするために異なる遅延選出時間を使用する必要があります。ここでの優先順位は、 レプリケーション オフセットに基づくと、オフセットが大きいほど、障害が発生したマスター ノード間の遅延が小さくなり、マスター ノードを置き換える可能性が高くなります。
主な機能は、データの一貫性が最も優れているノードが最初に選挙を開始することを保証することです
「3. 選挙の投票」
投票メカニズムRedis クラスターのスレーブ ノードはリーダーの選出には使用されません。これをセントリーと混同しないように注意してください。クラスターの投票メカニズムは、スロットを保持するホスト ポイントに基づいています。
障害が発生したノードのスレーブ ノードは、投票を要求するスロットを保持しているすべてのマスター ノードに FAILOVER_AUTH_REQUEST パケットをブロードキャストします。
マスター ノードが FAILOVER_AUTH_ACK 投票に応答すると、NODE_TIMEOUT * 2
の期間中は他のスレーブ ノードに投票できません。スレーブ ノードが投票の半分以上を取得すると、障害回復フェーズに進みます。
『4. フェイルオーバー』
スレーブが正常に選出されました。ノードはレプリケーションの変更をキャンセルします。 マスター ノード
障害が発生したノードのスロットを削除し、障害が発生したノードのスロットを自分自身に委ねます
自身の pong メッセージをクラスターにブロードキャストし、ホストに通知します。障害が発生したノードのスロット情報を変更し、引き継ぎます。
必要な SSH 背景! ！ ！
完成までに 2 晩かかった redis センチネルの記事ですが、記事自体に焦点を当てていません。編集者は悲嘆に暮れています
皆の要望に応えるために、カカはしぶしぶ、明るい背景とブラインドの背景を設定する方法について話します。 
Kaka が使用するツールは xsheel です。
ツール選択オプションを開きます。
透明なウィンドウがあるかどうかを確認して、xsheel の透明度を設定できます。 ＃＃＃はい！おっしゃる通りです。これはデスクトップの背景です。設定を開始する準備はできていますか?設定して記事を読んでから戻ってみてはいかがでしょうか?カカ氏はまた、技術的なポイントを提供したり間違いを修正したりするために、あらゆる分野の専門家を必要としています。 
❝学習の継続、ブログの継続、共有の継続は、カカがそのキャリア以来常に支持してきた信念です。巨大なインターネット上のカカの記事がそうであることを願っています。助けてください。次号でお会いしましょう。❞
redis チュートリアル "
以上がインタビューで Redis クラスターについて質問され、死ぬまで拷問されました...の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。