Redis の 3 つのクラスターモードの概要と共有-Redis-php.cn

この記事では、Redis に関する関連知識をお届けします。Redis には 3 つのクラスターモードがあり、その中でマスター/スレーブが最も一般的なモードです。今日は、この記事を通じて、 Redis の 3 つのクラスターモード。興味のある方はぜひご覧ください。皆さんのお役に立てれば幸いです。

Redis の 3 つのクラスターモードの概要と共有

#推奨される学習:

Redis ビデオチュートリアル

3 つのクラスターモード

Sentinel Sentinel モードは、マスター/スレーブレプリケーションクラスター内のホストがダウンした後のマスター/スレーブ切り替えの複雑さを補うために進化しました。 Sentinel はその名のとおり監視に使用され、主な機能はマスター/スレーブクラスターを監視し、マスターとスレーブを自動的に切り替え、クラスターのフェールオーバーを完了することです。
クラスターモードは、redis が公式に提供するクラスターモードであり、シャーディングテクノロジを使用して、高可用性、読み取りと書き込みの分離を実現するだけでなく、真の分散ストレージも実現します。

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

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

1. reids マスター/スレーブモード

2. Redis レプリケーションの原則

Redis レプリケーションは、操作の同期 (SYNC) とコマンドの伝播 (コマンド伝播) の 2 つの部分に分かれています。

コマンド伝播 (コマンド伝播) は、マスターサーバーのデータが変更され、マスタースレーブが不整合になった後、スレーブサーバーとマスターサーバーの状態の一貫性を保つために、コマンドの伝播に使用されます。一般的な説明では、マスターサーバーがクライアントのデータ変更コマンドを受信した後、データベースデータが変更され、そのコマンドがキャッシュされ、キャッシュされたコマンドがスレーブサーバーに送信されます。スレーブサーバーは、ロードすることでマスターとスレーブのデータの一貫性を実現します。キャッシュされたコマンド。これをコマンドの伝播と呼びます。
同期とコマンド伝播の 2 つのレプリケーション操作がある理由: 同期操作のみがある場合、スレーブサーバーがマスターサーバーに SYNC コマンドを送信すると、マスターサーバーは RDB スナップショットの生成時にそれを受信します。ファイル。クライアントのコマンドによりデータのステータスが変更されます。データのこの部分がスレーブサーバーに通信できない場合、マスターとスレーブのデータは不整合になります。このときコマンド伝播が発生し、マスターサーバーはスレーブサーバーからSYNCコマンドを受信した後、RDBスナップショットファイルを生成し、その間に受信したコマンドをキャッシュし、コマンド伝播動作によりスレーブサーバーに送信します。。マスターとスレーブのデータの一貫性を実現するため。

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

Redis レプリケーションの 2 つの操作を上で紹介しましたが、Redis マスター/スレーブレプリケーションは公式には同期とコマンドの伝播に基づいて実現されます。次の 2 つの図は、redis レプリケーションプロセスを示しています:

##4. 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 監視クラスタープロセス:

パブリッシュおよびサブスクライブモードを通じて他のスレーブサーバーに通知します。

2.2. Sentinel フェイルオーバー

Sentinel フェイルオーバー:

3. それでは、客観的にオフラインになるのはいつでしょうか? Sentinel システム内の他のインスタンスは、クラスター内のインスタンススーパーバイザーがオフラインであることを確認する必要があります。
マスターサーバーが主観的にオフラインとしてマークされている場合、Sentinel システムでマスターを監視している Sentinel プロセスは、マスターがスーパーバイザオフライン状態に入ったかどうかを 1 秒に 1 回確認する必要があります。
4.マスターが監視オフライン状態に入ったことを確認するのに十分な Sentinel インスタンス (構成に応じて) がある場合、マスターは客観的にオフラインとしてマークされます。

3. Sentinel の長所と短所