Redis マスター/スレーブ レプリケーションの原理の紹介 (画像とテキスト)

この記事では、Redis のマスター/スレーブ レプリケーションの原理 (写真とテキスト) を紹介します。一定の参考価値があります。必要な友人は参照できます。お役に立てれば幸いです。

直面している問題

1. マシンの故障。 Redis サーバーにデプロイしますが、マシンに障害が発生した場合は、別のサーバーに移行してデータが同期されていることを確認する必要があります。データが最も重要なので、気にしない場合は、基本的に Redis を使用しません。

2. 容量のボトルネック。 Redis メモリを 16G メモリから 64G メモリに拡張する必要がある場合、1 台のマシンでは間違いなくそれを満たすことができません。もちろん、新しい 128G マシンを購入することもできます。

解決策

分散データベースのストレージ容量を増やし、大量の同時アクセスに耐えるために、元の集中データベースのデータを他の複数のネットワークに個別に保存します。ノード。

この単一ノードの問題を解決するために、Redis はデータの複数のコピーを複製し、複製のために他のノードにデプロイして、Redis の高可用性とデータの冗長バックアップを実現してデータとサービスを保証します。 . 高可用性。

マスター スレーブ レプリケーション

マスター スレーブ レプリケーションとは

マスター スレーブ レプリケーションとは、Redis サーバーのデータをコピーすることを指します。他の Redis サーバーへ。前者をマスター ノード、後者をスレーブ ノードと呼びます。データのレプリケーションは一方向であり、マスター ノードからスレーブ ノードへのみ可能です。

デフォルトでは、各 Redis サーバーはマスター ノードであり、マスター ノードは複数のスレーブ ノードを持つことができます (またはスレーブ ノードがない) が、スレーブ ノードが持つことができるマスター ノードは 1 つだけです。

マスター スレーブ レプリケーションの役割

1. データ冗長性: マスター スレーブ レプリケーションは、永続化以外のデータ冗長化方法であるデータのホット バックアップを実装します。

2. 障害回復: マスター ノードで問題が発生した場合、スレーブ ノードは迅速な障害回復を実現するためのサービスを提供できます。これは実際には一種のサービス冗長です。

3. 負荷分散: マスター/スレーブ レプリケーションに基づいて、読み取り/書き込み分離と組み合わせることで、マスター ノードが書き込みサービスを提供し、スレーブ ノードが読み取りサービスを提供できます (つまり、書き込み時)。 Redis データの場合は接続マスター ノードを適用し、Redis データの読み取り時にはスレーブ ノードに接続します) を使用してサーバーの負荷を共有します。特に、書き込みが少なく読み取りが多いシナリオでは、複数のスレーブ ノードで読み取り負荷を共有すると、負荷が大幅に増加する可能性があります。 Redis サーバーの同時実行性。

4. 読み取りと書き込みの分離: 読み取りと書き込みの分離、メイン ライブラリの書き込み、スレーブ ライブラリの読み取りを実現するために使用できます。読み取りと書き込みの分離は、サーバーの負荷容量を向上させるだけではありません。スレーブ ライブラリの数を変更する;

5. 高可用性の基礎: 上記の機能に加えて、マスター/スレーブ レプリケーションも重要な機能です。センチネルとクラスターの実装の基礎となるため、マスター/スレーブ レプリケーションは Redis の高可用性の基礎となります。

マスター/スレーブ レプリケーションを有効にする

スレーブ ノードからマスター/スレーブ レプリケーションを有効にします。方法は 3 つあります:

1. 設定ファイル: サーバーの設定ファイルから追加します:slaveof

2. 開始コマンド:redis- の後に --slaveof を追加します。

3. クライアント コマンド: Redis サーバーの起動後、クライアント経由でコマンドを直接実行します:slaveof
   、次にRedis インスタンスがスレーブ ノードになります。

info replication コマンドを使用して、一部のレプリケーション情報を確認できます。

マスター/スレーブ レプリケーションの原理

マスター/スレーブ レプリケーション プロセスは大まかに分けることができます。接続確立フェーズ (つまり、準備フェーズ)、データ同期フェーズ、コマンド伝播フェーズの 3 つのステージに分かれています。

スレーブノードがslaveofコマンドを実行すると、レプリケーションプロセスが動作を開始します。大まかに以下の図がわかります。
この図から、レプリケーションプロセスは大きく6つのプロセスに分かれていることがわかります。

マスター/スレーブ構成後のログ記録でもこのプロセスを確認できます

1) マスターノード (マスター) の情報を保存します。
slaveof を実行した後、Redis は次のログを出力します:

2) スレーブ ノード (スレーブ) は、毎秒実行されるスケジュールされたタスクを通じてレプリケーション関連のロジックを維持します。スケジュールされたタスクが新しいマスター ノードの存在を検出した後、そのノードとのネットワーク接続を確立しようとします。

スレーブ ノードは、そのノードとのネットワーク接続を確立します。マスター ノード

スレーブ ノードはソケット ソケットを確立し、スレーブ ノードはポート 51234 でソケットを確立します。これは、マスター ノードによって送信されたレプリケーション コマンドを受け入れるために特別に使用されます。スレーブ ノードが正常に接続されると、次のログが出力されます:

スレーブ ノードが接続を確立できない場合、スケジュールされたタスクは接続が成功するまで無期限に再試行するか、slaveof no one を実行してレプリケーションをキャンセルします。

接続の失敗については、スレーブ ノードで実行できます。情報レプリケーションでは、マスター ノードへの接続が失敗したときのシステム時間を記録する master_link_down_since_seconds メトリックを表示します。スレーブ ノードがマスター ノードへの接続に失敗すると、問題の発見を容易にするために次のログが 1 秒ごとに出力されます:

# Error condition on socket for SYNC: {socket_error_reason}

3) ping コマンドを送信します。
接続が正常に確立された後、スレーブ ノードは最初の通信のために ping リクエストを送信します。ping リクエストの主な目的は次のとおりです:
·マスターとスレーブ間のネットワーク ソケットが利用可能かどうかを検出します。
·マスターノードが現在処理コマンドを受け入れることができるかどうかを検出します。
ping コマンドを送信した後、スレーブ ノードがマスター ノードからポン応答を受信しないか、ネットワークがタイムアウトになったり、マスター ノードがブロックされてコマンドに応答できないなどのタイムアウトが発生した場合、スレーブ ノードはレプリケーション接続を切断すると、次にスケジュールされたタスクが再接続を開始します。

ノードから送信された ping コマンドが正常に返され、Redis は次のログを出力し、後続のレプリケーション プロセスを続行します。

4) 権限の確認。 requirepass パラメータがマスター ノードに設定されている場合、パスワード検証が必要です。スレーブ ノードは、パスワードがマスター ノードと同じであることを確認して検証に合格するように masterauth パラメータを設定する必要があります。検証が失敗した場合、レプリケーションは終了すると、スレーブ ノードはレプリケーション プロセスを再開します。

5) データセットを同期します。マスターとスレーブのレプリケーション接続が正常に通信した後、初めてレプリケーションが確立されると、マスター ノードは保持しているすべてのデータをスレーブ ノードに送信します。この部分の操作は最も長いステップです。

6) コマンドは連続してコピーされます。マスターノードが現在のデータをスレーブノードに同期すると、レプリケーション確立プロセスが完了します。次に、マスター ノードは継続的に書き込みコマンドをスレーブ ノードに送信して、マスターとスレーブのデータの一貫性を確保します。

以上がRedis マスター/スレーブ レプリケーションの原理の紹介 (画像とテキスト)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。