Redis でクラスタリングを実装する方法

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

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

• スレーブ サーバーはメイン サーバーに接続し、SYNC コマンドを送信します。

• メイン サーバーは SYNC ネーミングを受信した後、BGSAVE コマンドの実行を開始して RDB ファイルを生成しますそしてバッファを使用して、その後実行されるすべての書き込みコマンドを記録します。 ;

• マスター サーバー BGSAVE の実行後、スナップショット ファイルをすべてのスレーブ サーバーに送信し、その間に実行された書き込みコマンドを記録し続けます。送信期間;

• サーバーからスナップショット ファイルを受信した後、古いデータをすべて破棄し、受信したスナップショットをロードします;

• マスター後サーバー スナップショットが送信されると、バッファ内の書き込みコマンドのスレーブ サーバーへの送信を開始します。 ;

• スレーブ サーバーはスナップショットのロードを完了し、コマンド リクエストの受信を開始し、サーバーからの書き込みコマンドを実行します。マスターサーバーバッファ; (

  スレーブサーバーの初期化が完了しました)

• マスターサーバーは書き込みコマンドを実行するたびに、同じ書き込みコマンドをスレーブサーバーに送信します。スレーブ サーバーは、受信した書き込みコマンドを受信して​​実行します (

  スレーブ サーバーの初期化後の操作)

マスター/スレーブ レプリケーションの長所と短所:

#利点:

マスター/スレーブ レプリケーションをサポートし、ホストはデータをスレーブに自動的に同期し、読み取りと書き込みが可能です。

• #マスターの読み取り操作の負荷を軽減するために、スレーブ サーバーは、クライアントが読み取り専用の操作サービスを提供しますが、書き込みサービスはマスターによって完了する必要があります。

• スレーブは他のスレーブからの接続および同期リクエストを受け入れることもできるため、マスターの同期プレッシャーを効果的に軽減できます。

• マスター サーバーは、ノンブロッキングな方法でスレーブにサービスを提供します。したがって、マスターとスレーブの同期中も、クライアントはクエリまたは変更リクエストを送信できます。

• スレーブ サーバーは、ノンブロッキング方式でデータ同期も完了します。同期中にクライアントがクエリリクエストを送信すると、Redis は同期前にデータを返します。
欠点:

# # Redis には自動フォールト トレランスと回復機能がありません。ホスト マシンとスレーブ マシンのダウンタイムにより、一部のフロントエンドの読み取りおよび書き込みリクエストが失敗します。マシンが再起動するまで待つか、フロントエンド IP を手動で切り替える必要があります。回復する。

• ホスト マシンがダウンしました。マシンがダウンする前に、一部のデータをスレーブ マシンに同期できませんでした。IP を切り替えた後、データの不整合が発生し、システムの可用性。

• Redis はオンライン拡張に対応しにくく、クラスタ容量が上限に達するとオンライン拡張が非常に複雑になります。

• 2.
センチネル モード

マスター サーバーがサービスを中断した場合、スレーブ サーバーをマスター サーバーにアップグレードしてサービスを提供し続けることができますが、このプロセスには手動操作が必要です。この目的を達成するために、Redis 2.8 は、自動化されたシステム監視および障害回復機能を実装するためのセンチネル ツールを提供します。

センチネルの役割は、Redis システムの実行ステータスを監視することです。その機能としては以下の2つが挙げられます。

(1) マスタサーバおよびスレーブサーバが正常に稼働しているか監視します。
(2) メインサーバーに障害が発生した場合、スレーブサーバーからメインサーバーに自動的に切り替えられます。

センチネルの仕組み:

• 各センチネル プロセスは、クラスター全体のマスターに 1 秒に 1 回メッセージを送信します。サーバーおよび他の Sentinel プロセスからの PING コマンド。

• PING コマンドに対する最後の有効な応答からの時間が、down-after-milliseconds オプションで指定された値を超えた場合、インスタンスは Sentinel プロセスによってマークされます。主観的にオフライン ( SDOWN)

• マスター サーバーが主観的にオフライン (SDOWN) としてマークされている場合、マスター サーバーを監視しているすべての Sentinel プロセスは、マスター サーバーが実際にオフライン状態に入ったことを 1 秒に 1 回確認する必要があります。主観的なオフライン状態

• 指定された環境に十分な数の Sentinel プロセス (設定ファイルで指定された値以上) が存在する場合、マスター サーバーが時間範囲内に主観的オフライン状態 (SDOWN) に入った場合、マスター サーバーは客観的にオフライン (ODOWN) としてマークされます

• 通常の状況では、各 Sentinel プロセスは INFO コマンドを送信します。クラスタ内のすべてのマスター サーバーとスレーブ サーバーを 10 秒ごとに実行します。

• マスター サーバーが Sentinel プロセスによって客観的にオフライン (ODOWN) としてマークされると、Sentinel プロセスはオフラインのマスター サーバーのすべてのスレーブ スレーブ サーバーにメッセージを送信します。 INFO コマンドは 10 秒に 1 回から 1 秒に 1 回に変更されます。

• マスター サーバーのオフラインに同意するのに十分な数の Sentinel プロセスがない場合、マスター サーバーの目的のオフライン ステータスは削除されます。マスター サーバーが Sentinel プロセスに PING コマンドを再度送信し、有効な応答を返すと、マスター サーバーの主観的なオフライン ステータスは削除されます。

Sentinel モードの長所と短所

利点:

• ## Sentinelこのモードはマスター/スレーブ モードに基づいており、センチネル モードにはマスター/スレーブ モードのすべての利点があります。

• マスターとスレーブを自動的に切り替えることができるため、システムの堅牢性と可用性が向上します。

欠点:

• Redis はオンライン拡張をサポートするのが難しく、クラスターの容量が上限に達するとオンラインで拡張されます。拡張は非常に複雑になります。

3.Redis-ClusterCluster

Redis のセンチネル モードは基本的に高可用性と読み取り/書き込み分離を実現できますが、このモードでは、各 Redis サーバーが同じデータを保存するため、メモリが無駄になるため、Redis 3.0 にクラスター モードが追加され、Redis の分散ストレージが実装されます。これは、各 Redis ノードが異なるコンテンツを保存することを意味します。

Redis-Cluster はセンターレス構造を採用しており、その特徴は次のとおりです:

• すべての Redis ノードが相互接続 (PING-PONG 機構) されており、バイナリプロトコルは、伝送速度と帯域幅を最適化するために内部で使用されます。

• ノードの障害は、クラスター内のノードの半分以上が障害を検出した場合にのみ有効になります。

• クライアントは、中間のプロキシ層を必要とせず、redis ノードに直接接続されます。クライアントはクラスター内のすべてのノードに接続する必要はなく、利用可能なノードに接続するだけです。クラスター内のノード。

作業方法:

redis の各ノードには 2 つのものがあり、1 つはスロットです。その値の範囲は次のとおりです: 0- 16383.もう 1 つはクラスターで、クラスター管理プラグインとして理解できます。アクセス キーが到着すると、redis は crc16 アルゴリズムに基づいて結果を取得し、結果の残りを 16384 まで計算します。これにより、各キーは 0 ～ 16383 の番号が付いたハッシュ スロットに対応します。この値は次の目的で使用されます。対応するスロットに対応するノードを見つけて、アクセス操作のために対応するノードに直接自動的にジャンプします。

高可用性を確保するために、redis-cluster クラスターではマスター/スレーブ モードが導入されています。1 つのマスター ノードは 1 つ以上のスレーブ ノードに対応します。マスター ノードがダウンすると、スレーブ ノードが有効になります。他のマスター ノードがマスター ノード A に ping を送信するときに、半数以上のマスター ノードと A の間の通信がタイムアウトになると、マスター ノード A はダウンしていると見なされます。マスター ノード A とそのスレーブ ノード A1 の両方がダウンすると、クラスターはサービスを提供できなくなります。

Redis 関連の技術記事の詳細については、Redis チュートリアル 列にアクセスして学習してください。

###

以上がRedis でクラスタリングを実装する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。