マスタ・スレーブ構成
マスター・スレーブ構成のプロセスについて、私たちはここで、具体的に詳細に説明していない、この記事を見て、それが良いです。
https://www.cnblogs.com/ysocean/p/9143118.html
マスタースレーブレプリケーションの第二に、原則
これが私たちの主な問題であり、私たちは見て
Redisの同期（シンク）へ機能とコマンドの伝播（コマンド伝搬）は、2つのコピー操作。
①、従来の同期
サーバーからのレプリケーションマスタサーバーを必要とSLAVEOFノードからコマンドを発行すると、コマンドは、マスターサーバーから送信されたSYNCを完了します。コマンド実行手順：
図1に示すように、サーバーからマスターサーバーにSYNCコマンドを送信します
2は、バックグラウンドでRDBファイルを生成し、最初から実行されたすべての書き込みコマンドを記録するために、バッファを使用して、マスターのSYNCコマンド実行BGSAVEコマンドを受信し
プライマリサーバBGSAVEコマンドが完了すると、サーバは、サーバから受信して、サーバはステータスファイルステータスレコードRDBを更新から3は、メインサーバは、RDB、RDBファイルに生成されたコマンドBGSAVEファイルを送信します。
図4は、書き込みコマンドから全てのバッファへのマスタサーバは、サーバからのコマンドを実行し、サーバーに送信されます。
②、コマンドの広がり
同期が完了すると、マスターサーバーは、適切な変更コマンドになり、この時間は、プライマリサーバの状態と一致し、サーバからではないでしょう。
一貫性のある状態を維持するために、メインサーバを取得し、サーバからのためには、マスタサーバがサーバから広がっコマンド操作を実行する必要がある、マスターが実行するサーバーから送信された、独自のコマンドを書き込みます。一貫性のある状態を維持するために、メインサーバからの対応するコマンドを実行した後、サーバーから。
要約：同期およびコマンド通信機能を介して、同じ特性の良好なマスターを確保することができます。
しかし、同期のマスターの間に、サーバーが、突然切断ならば、我々は問題を考えるが、今回は、書き込み操作の数のプライマリサーバは、この時間は、私たちが同期行った場合、それはメインである必要があり、サーバーから回復しますRDBは、新しいファイルサーバを生成し、サーバーからロードされるので、一貫性を確保することができていても、実際には状態から切断する前に、メインサーバは矛盾がサーバーから切断され、一貫性があり、かつ、サーバがメインの一部を実行しますただ、むしろそれの全体RDBスナップショットよりも、サーバーから切断することはできませんどのような接続復元するために、書き込みコマンドをコマンドを書くのか？
同期動作は、メインサーバー、実際に時間のかかる作業であるBGSAVE RDBコマンドでドキュメントを生成する必要があるし、サーバーからファイルを受け取った後、サーバーにファイルを送信する必要があり、そのファイルがロードされ、かつ負荷期間、サーバから他のコマンドを処理することができません。
この問題を解決するために、バージョン2.8の後からRedisのは、新しい同期コマンドを使用します。 PSYNCを 代わりにSYNCコマンドを実行します。複製、再接続の後の処理効率のために一部再同期コマンド。サーバーからマスターサーバーは、プライマリサーバーだけで、サーバから受信し、サーバーから送信された書き込みコマンドの後に切断され、休憩後に再接続して、マスターからの一貫性を維持するために書き込みコマンドを実行するときです。
第三に、からの複製の主な欠点
マスターノードからマスターコピーは、単一障害点の問題を解決するために、しかし、すべての書き込みは、マスターノードの操作にあり、そのノードをスレーブに同期するので、同期は一定の遅延、システムは非常に忙しい時間になりますが、遅延の問題はより深刻になり、むしろより厳しいスレーブノードとして増加します。