ローカル環境を使用するため、ローカルのRedisクラスターが構築されます。この記事では、Redisマスタースレーブレプリケーションクラスターの確立について説明します。使用されるプラットフォームはWindowsであり、構築の考え方は基本的に同じです。 Linux！
（この記事を集中的に読むには15分、ざっと読むには約5分かかる場合があります）
Redisマスタースレーブレプリケーションの簡単な紹介
一部のノードがオフラインであるか、クラスター内のほとんどのノードと通信できない場合でもクラスターを正常に機能させるために、Redisクラスターはノードのマスタースレーブレプリケーション機能を使用します。クラスター内のノード1からNのレプリカがあり、そのうちの1つはマスターであり、残りのN-1のレプリカはスレーブです。[Redisクラスターのマスタースレーブレプリケーションから]
つまり、上記はマスタースレーブレプリケーションです。簡単に言えば、マスターノードマスターは1つ以上のスレーブノードを持つことができ、スレーブは複数のスレーブを持つことができます。このようにして、強力なマルチレベルサーバークラスターアーキテクチャが形成されます。
その中で、マスターノードは主に書き込み（書き込み可能または読み取り）であり、スレーブノードは読み取りのみが可能で書き込みはできません！[読み取り/書き込み分離シナリオ]
マスターノードによって書き込まれたデータは（準リアルタイムではなく）Salveに同期されるため、マスターノードに障害が発生してデータが失われた場合でも、Salveを介してデータを復元できます。[災害復旧シナリオ、注：データはリアルタイムで同期されないため、Salveからデータを復旧した後にデータ損失の問題が発生する可能性があります]
要約：redisマスタースレーブレプリケーションのいくつかの機能は次のとおりです
。1。マスターは複数のスレーブを持つことができます
。2。同じマスターに接続された複数のスレーブに加えて、スレーブは他のスレーブに接続してグラフ構造を形成することもできます
3。マスタースレーブレプリケーションはマスターをブロックしません。つまり、1つ以上のスレーブとマスターが初めてデータを同期するときに、マスターはクライアントから送信された要求を処理し続けることができます。逆に、スレーブが初めてデータを同期するとき、処理できないクライアントからの要求をブロックします。
4.マスタースレーブレプリケーションを使用して、システムのスケーラビリティを向上させることができます。クライアントの読み取り要求専用に複数のスレーブを使用できます。たとえば、ソート操作はスレーブで処理できます。単純なデータの冗長性にも使用できます
。5 。マスターでデータの永続性を無効にし、マスター構成ファイルのすべての保存構成をコメントアウトして、スレーブでのみデータの永続性を構成できます。
6.読み取りと書き込みの分離とディザスタリカバリに使用できます。
Redisマスタースレーブレプリケーションで一般的に使用されるいくつかの方法
1つのマスターと2つのサーバントA（B、C）、1つのマスターと2つのスレーブ
（分散型）A-B-C、Bは両方ともマスターノード（Cのマスターノード）です。スレーブノード（Aのスレーブノード）から
ゲスト指向（マスターノードがダウンした後、スレーブノードをマスターノードに手動でアップグレード）およびセンチネルモード（マスターノードがダウンした後、スレーブノードは自動的にマスターにアップグレードされます） node）
今回は主に1人を紹介します。マスターとセカンドサーヴァント、そして反ゲスト志向の操作は紹介せずに受け継がれています。歩哨モードの後に特別な紹介を書いてください！
Redisマスター/スレーブレプリケーションの構築（1つのマスターと2つのサーバント）
1。Windows環境のRedisインストールパッケージをダウンロードし、Baiduからダウンロードします。
2.ダウンロードが完了したら、
次の図に示すように、解凍したディレクトリを解凍し
ます
。3 。関連する設定操作（1）3つのコピーをコピーした後、解凍後にRedis
の名前をローカルで変更すると、コピー後のフォルダ名が表示されます。次のように：
Redis-x64-3.2.100-6379
Redis-x64-3.2.100-6380
Redis-x64-3.2.100-6381
（2）変更
せずにredis.windows.conf 6379フォルダーを変更してください！
6380フォルダー、次のように修正：
port 6380
# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6379
6381フォルダー、次のように修正：
port 6381
slaveof 127.0.0.1 6379
誰もがredis.xx.confの関連する構成を知っていると思います！わからない場合は、Redisの学習-redis.conf構成ファイルの概要を参照してください。
（3）クイックスタートを容易にするために、簡単なウィンドウスクリプトを追加してください！
対応するredisフォルダーの下に新しいものを作成します
startRedisServer.bat
スクリプトの内容は次のとおりです。
@echo off
redis-server.exe redis.windows.conf
@pause
次に、redisフォルダーと同じレベルに新しいディレクトリを作成します
start6379.cmd
@echo off
cd Redis-x64-3.2.100-6379
startRedisServer.bat
次に、6380と6381は上記の操作と同じです。操作が完了すると、次の図が表示されます
。4。テスト
開始ルールを開始します。最初にマスターノードを開始し、次にスレーブノードを開始します。
（1）コマンドを使用して開始できます
対応するフォルダーディレクトリを入力し、開始コマンドを使用します。
（2）スクリプトを使用して開始
します。上の図に示すように、start6379.cmd、
start6380.cmd、およびstart6381.cmdを実行します。それぞれ。
（3）上記の方法でこのマシンで3つのredisを同時に開始できない場合は、こちらをご覧ください
最初にマスターを起動します。クライアントを使用してログインし、図に示すように情報を表示します。
次に、6380と6381を起動すると
、図に示すように、次のように表示されます。図に示すように、6378のマスタースレーブレプリケーション情報をここに表示
します。 。6380および6381のクライアントで、ノード情報を確認してください。図に示すように、
テスト読み出しおよび書き込み、[マスターノードが読み書きできる、スレーブノードのみ読み書きできず]、同図に示すように以下：
マスターノードがシャットダウンされた後、スレーブノードのステータスをテストします[スレーブノードは読み取り可能であり、スレーブノードはマスターノードにアップグレードされません]：
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:15
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381>
127.0.0.1:6381> get hello
"world"
マスターノードの再起動後にスレーブノードのステータスをテストします[スレーブノードは引き続きマスターノードに接続できます]：
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=43,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=43,lag=0
master_repl_offset:43
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:42
127.0.0.1:6379>
エピソード[反顧客志向]
マスターノードがシャットダウンされたときにテストし、誰のスレーブも使用しないでください。はい、6380がマスターノードになりますが、スレーブノードがないマスターノードのみです。：図のように
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:155
master_link_down_since_seconds:jd
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381>
127.0.0.1:6381>
127.0.0.1:6381> slave no one
(error) ERR unknown command 'slave'
127.0.0.1:6381> slaveof no one
OK
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381> set test 11
OK
127.0.0.1:6381> get test
"11"
127.0.0.1:6381>
詳細については、Redisマスタースレーブレプリケーションのコンテンツを参照してください。
Redisマスタースレーブレプリケーションの原理
最初の紹介
スレーブサーバーがセットアップされると、スレーブはマスターとの接続を確立してから、syncコマンドを送信します。
マスターは、バックグラウンド保存プロセスを開始するコマンドを受信すると同時に、データセットを変更するために受信したすべてのコマンドを収集します。バックグラウンドプロセスが実行された後、マスターはデータファイル全体をスレーブに送信して完了します。同期。
フルコピー：スレーブサービスはデータベースファイルデータを受信した後、それを保存してメモリにロードします。（最初の全量）
インクリメンタルレプリケーション：マスターは、同期を完了するために、新しく収集されたすべての変更コマンドをスレーブに順番に渡し続けます。（その後インクリメント）
ただし、マスターが再接続されている限り、完全同期（フルレプリケーション）が自動的に実行されます。
スレーブサーバーがセットアップされると、スレーブはマスターとの接続を確立してから、syncコマンドを送信します。初めて確立された接続であろうと、接続が切断された後の再接続であろうと、マスターはデータベーススナップショットをファイルに保存するためのバックグラウンドプロセスを開始し、マスターマスタープロセスは新しい書き込みコマンドの収集とキャッシュを開始します。バックグラウンドプロセスがファイルの書き込みを終了した後、マスターはファイルをスレーブに送信し、スレーブはファイルをディスクに保存してからメモリにロードして、データベーススナップショットをスレーブに復元します。次に、マスターはキャッシュされたコマンドをスレーブに転送します。そして、マスターが受信した後続の書き込みコマンドは、最初に確立された接続を介してスレーブに送信されます。マスターからスレーブにデータを同期するコマンドとクライアントから送信されるコマンドは、同じプロトコル形式を使用します。マスターとスレーブ間の接続が切断されると、スレーブは自動的に接続を再確立できます。マスターが複数のスレーブから同時に接続コマンドを受信した場合、マスターはデータベースミラーリングを書き込むプロセスを開始するだけで、それをすべてのスレーブに送信します。
2番目の紹介：
画像コンテンツのソースネットワーク：
3番目の紹介：
Redisマスタースレーブ同期には、完全同期と部分同期の2つの方法（または2つの段階）があります。
マスターとスレーブが接続されたばかりの場合は、完全同期を実行します。完全同期が終了したら、部分同期を実行します。もちろん、必要に応じて、スレーブはいつでも完全同期を開始できます。いずれの場合も、Redis戦略では、最初に部分同期を実行しようとします。失敗した場合、スレーブは完全同期を実行してBGSAVEを開始する必要があります... BGSAVEが終了すると、RDBファイルが転送されます。成功した場合、スレーブは部分的な同期を実行し、バックログスペースでデータを転送することができます。
Redisマスタースレーブレプリケーション（1マスター、2スレーブ/ 1マスター、複数スレーブ）分析
IOが急増します。
スレーブが切断され（アクティブに切断されるかネットワーク障害が発生する）、マスターに接続されるたびに、すべてのマスターがRDBからダンプする必要があります。aofでは、同期プロセスを再度実行する必要があります。したがって、複数のスレーブを一度に開始しないでください。そうしないと、マスターがIOを急激に増加させる可能性があります（間隔1〜2分）。
レプリケーションの遅延
すべての書き込み操作は最初にマスターで実行され、次にスレーブに同期されるため、マスターからスレーブマシンへの同期には一定の遅延があります。システムが非常にビジーの場合、遅延の問題はより深刻になります。スレーブマシンの数増加により、この問題はさらに深刻になります。
可用性が低い
マスターノードで異常な状況が発生すると、書き込みができなくなり、ビジネスエラーが発生します。[解決策は、Redis-Sentinelモードを使用することです。詳細については、シリーズの2番目の記事を参照してください]
注：
Redisクラスターは強力なデータ整合性を保証しません（強力な整合性）Redisクラスターの整合性保証（保証）：特定の条件下では、Redisクラスターは実行された書き込みコマンドを失う可能性があります。
————————————————
著作権表示：この記事は、CSDNブロガー「Afeiyun」の元の記事であり、CC 4.0BY-SA著作権表示に準拠しています。元のソースを添付してくださいリンクとこれを再印刷します。ステートメント。
元のリンク：https：//blog.csdn.net/u010648555/article/details/79427606