Redis の 3 つのクラスター モードの概要と共有
- WBOY転載
- 2022-08-31 17:54:381933ブラウズ
- Redis には 3 つのクラスター モードがあります、そのうちマスター/スレーブが最も一般的なモードです。
- Sentinel Sentinel モードは、マスター/スレーブ レプリケーション クラスター内のホストがダウンした後のマスター/スレーブ切り替えの複雑さを補うために進化しました。 Sentinel はその名のとおり監視に使用され、主な機能はマスター/スレーブ クラスターを監視し、マスターとスレーブを自動的に切り替え、クラスターのフェールオーバーを完了することです。
- クラスター モードは、redis が公式に提供するクラスター モードであり、シャーディング テクノロジを使用して、高可用性、読み取りと書き込みの分離を実現するだけでなく、真の分散ストレージも実現します。
1. reids マスター/スレーブ モード
2. Redis レプリケーションの原則
Redis レプリケーションは、操作の同期 (SYNC) とコマンドの伝播 (コマンド伝播) の 2 つの部分に分かれています。
- 同期 (SYNC) は、マスター サーバーと一致するようにスレーブ サーバーのステータスを更新するために使用されます。俗に説明すると、メインサーバーのデータをサーバーから能動的に取得することになります。データの一貫性を保ちます。具体的な実装としては、SYNCコマンドを受信したマスターサーバーがRDBスナップショットファイルを生成し、スレーブサーバーに送信します。
- コマンド伝播 (コマンド伝播) は、マスター サーバーのデータが変更され、マスター スレーブが不整合になった後、スレーブ サーバーとマスター サーバーの状態の一貫性を保つために、コマンドの伝播に使用されます。一般的な説明では、マスター サーバーがクライアントのデータ変更コマンドを受信した後、データベース データが変更され、そのコマンドがキャッシュされ、キャッシュされたコマンドがスレーブ サーバーに送信されます。スレーブ サーバーは、ロードすることでマスターとスレーブのデータの一貫性を実現します。キャッシュされたコマンド。これをコマンドの伝播と呼びます。
- 同期とコマンド伝播の 2 つのレプリケーション操作がある理由: 同期操作のみがある場合、スレーブ サーバーがマスター サーバーに SYNC コマンドを送信すると、マスター サーバーは RDB スナップショットの生成時にそれを受信します。ファイル。クライアントのコマンドによりデータのステータスが変更されます。データのこの部分がスレーブ サーバーに通信できない場合、マスターとスレーブのデータは不整合になります。このときコマンド伝播が発生し、マスターサーバーはスレーブサーバーからSYNCコマンドを受信した後、RDBスナップショットファイルを生成し、その間に受信したコマンドをキャッシュし、コマンド伝播動作によりスレーブサーバーに送信します。 。マスターとスレーブのデータの一貫性を実現するため。
3. Redis マスター/スレーブ レプリケーションの原理
Redis レプリケーションの 2 つの操作を上で紹介しましたが、Redis マスター/スレーブ レプリケーションは公式には同期とコマンドの伝播に基づいて実現されます。次の 2 つの図は、redis レプリケーション プロセスを示しています:
利点:
1. 読み取りと書き込みの分離を実現し、可用性を向上させ、単一マシンの障害を解決します。 2. マスター/スレーブ レプリケーション中、マスターとスレーブは両方ともノンブロッキングであり、まだ利用可能です。
欠点:
1. マスターのダウンタイム中は手動でホストを切り替える必要があり、同時に一部のデータはスレーブ サーバーとの同期が間に合わず、データの不整合が発生します。 (手動介入が必要です)
2. スレーブがダウンし、複数のスレーブが復元された後、大量の SYNC 同期によりマスター IO 圧力が 2 倍になります (起動時間は手動で回避できます)
3. オンラインでの拡張は複雑です。
概要:
Redis マスター/スレーブ レプリケーションの利点は、主に可用性の向上です。 欠点
2. Sentinel Sentinel モード
Sentinel Sentinel Sentinel の概要
Sentinel Sentinel は本質的に特別なモードで実行される Redis インスタンスですが、初期化プロセスと作業は通常の Redis とは異なり、本質的には別のプロセスです。
Sentinel は Redis の高可用性ソリューションです: 1 つ以上の Sentinel インスタンス (インスタンス) で構成される Sentinel システム (システム) は、任意の数のマスター サーバーと、これらのマスター サーバーの下にあるすべてのスレーブ サーバーを監視できます。マスターサーバーがオフラインになったときに、スレーブサーバーからマスターサーバーに自動的に切り替えることができます。
1. Sentinel システム次の図は、単純な Sentinel システム アーキテクチャ図です。Sentinel システムはマスター/スレーブ クラスターを監視します。ここで、server1 は Redis マスター サーバーです。そして、server2 /3/4 は Redis スレーブ サーバーです。上記のマスター/スレーブ レプリケーションは、マスターとスレーブの間で使用され、マスター/スレーブの一貫性を実現します。 Sentinel システムは、マスター/スレーブ クラスター全体を監視します。
2. Sentinel フェイルオーバー
Sentinel システムは、Server1 のメイン サーバーがオフラインであることを検出すると、server2/ を終了します。 3/4コピー。
同時に、Sentinel はサーバー 2 をメイン サーバーにアップグレードし、サーバー 3/4 は新しいメイン サーバーから複製します。同時に、server1 が再びオンラインになるまで待ちます。
Sentinel システムは、メイン サービスをスレーブ サーバーにアクティブにダウングレードし、スレーブ サーバーをマスター サーバーにアップグレードすることもできます。
#2.1. Sentinel 監視プロセス
Sentinel 監視クラスター プロセス:
- Commandコマンドを送信して Redis サーバーを実行状態に戻す Sentinel。パブリッシュおよびサブスクライブ マスター サーバーのステータスが変化すると、Sentinel は
- パブリッシュおよびサブスクライブ モードを通じて他のスレーブ サーバーに通知します。
2.2. Sentinel フェイルオーバー
Sentinel フェイルオーバー:
- #1. Sentinel システム内の Sentinel インスタンスは、クラスターのような PING コマンドを 1 秒ごとに実行します。Sentinel インスタンスへのクラスター内のインスタンスの応答時間がミリ秒後のダウンを超えると、このインスタンスは PING コマンドを送信します。Sentinel インスタンスは次のとおりです。主観的にはダウンライン
- 3. それでは、客観的にオフラインになるのはいつでしょうか? Sentinel システム内の他のインスタンスは、クラスター内のインスタンス スーパーバイザーがオフラインであることを確認する必要があります。
- マスター サーバーが主観的にオフラインとしてマークされている場合、Sentinel システムでマスターを監視している Sentinel プロセスは、マスターがスーパーバイザ オフライン状態に入ったかどうかを 1 秒に 1 回確認する必要があります。
- 4.マスターが監視オフライン状態に入ったことを確認するのに十分な Sentinel インスタンス (構成に応じて) がある場合、マスターは客観的にオフラインとしてマークされます。
3. Sentinel の長所と短所
長所:
1. Sentinel モードはマスター/スレーブ レプリケーションに基づいているため、Sentinel にはマスター/スレーブ レプリケーションのすべての利点があります 2. Sentinel にはマスター/スレーブの切り替えとフェイルオーバーがあるため、クラスターの可用性が高くなります欠点:1. Redis はオンライン拡張をサポートするのが難しく、オンライン拡張はより複雑です。 概要: sentinel は主に、redis マスター/スレーブ クラスターを監視し、redis マスター/スレーブ クラスターの可用性を向上させるために使用されます。
3. クラスター モード
1. reids クラスター
Redis クラスターはサーバーの一種ですシャーディング テクノロジー、redis バージョン 3.0 が正式に利用可能になりました。
Sentinel は基本的に高可用性を実現していますが、各マシンが同じコンテンツを保存するためメモリを無駄に消費するため、Redis Cluster は分散ストレージを実装しています。異なるコンテンツが各マシン ノードに保存されます。
#2. Redis クラスターのデータ シャーディングの原則
redis データ シャーディングはハッシュ スロットを使用し、Redis クラスターには 16384 個のハッシュがあります各キーは CRC16 チェックに合格した後、モジュロ 16384 でチェックされ、どのスロットに配置するかを決定します。 redis キーにアクセスすると、redis は CRC16 アルゴリズムに基づいて結果を取得し、結果の剰余と 16384 を計算し、この値を使用して対応するノードからデータを取得します。
現時点では、アプリケーション クライアントは実際にはいずれかのノードに接続するだけでよく、Redis クラスター内の各ノードは他のノードのスロット情報を保存します。このようにして、アクセスキーがスロットを計算した後、スロット情報を保存することでコンフィギュレーションからノード情報を取得し、対応するノードを検索してデータを取得します。
3. Redis クラスターのレプリケーション原理
redis クラスター クラスターでは、マスター/スレーブ レプリケーション モデルが導入されており、1 つのマスター ノードが 1 つ以上のスレーブ ノードに対応します。マスターノードの場合 ノードがダウンすると、スレーブノードが有効になります。他のマスター ノードがマスター ノード A に ping を実行するときに、マスター ノードの半分以上が A との通信がタイムアウトになると、マスター ノード A はダウンしていると見なされます。マスター ノード A とそのスレーブ ノード A1 の両方がダウンしている場合、クラスターはサービスを提供できなくなります
推奨される学習:
Redis ビデオ チュートリアル以上がRedis の 3 つのクラスター モードの概要と共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。