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

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 サイトの他の関連記事を参照してください。