からマスターコピー
マスタースレーブのレプリケーション：マスターノードは、ノードからのデータを書き込むための責任がある読み、Redisの高可用性を向上させる分離を達成するために、書き込み、データを読み取るための責任があります。
、我々はサーバーコピーするマスターノード（マスター）を呼び出すと、プライマリサーバの反復にサーバーがノード（スレーブ）から呼び出された、サーバーが別のサーバーに（複製）をコピーすることを許可します
下図のように：
コピーの主な特長：
図1は、スレーブマスタが複数存在してもよいです
2、スレーブは1つのマスタのみを持つことができます
図3に示すように、データ・フローは一方向であり、マスタースレーブ
コピーの主な役割：
図1に示すように、データのコピー：高可用性Redisのを確実にするために1つまたは複数の部分のデータの複数のコピー、
図2は、スケーラビリティ：単一Redisの性能が制限されているが、マスタは、スケール能力、等QPSとして、コピーすることができ
マスタースレーブレプリケーションの第二に、実装
クライアントコマンド：slaveof
構成：
新Redisの-6380.confは、追加配置します
＃1は、マスターノードが誰であるかを示す IP-あなた-あなたのマスターマスターポートslaveof ＃2 のみ一貫性と同期のマスターノードとスレーブノードの別々の読み取りを確実にするために、ノードからの操作を、データを読み書きするように。 スレーブ対応の専用はい
第三に、複製の全額と増分コピー
1. RUNID：Redisのあなたが起動するたびに、現在実行中のRedisをマークするために異なるIDを生成します。ノードが保存されますから、RUN_IDは、マスターノードをマーク
Redisのマスターノードの再起動が発生した場合、そのノードは、変更を見つけるマスターノードに接続されている（この変更RUN_IDマスタノードがIPとポート番号に基づいてマークを意味しますマスタノードが変更に大量のデータが発生する可能性があり）、
それは、マスタノード内のすべてのデータをコピーするために、すべてで、コピーの総量の原因となり、この場合になります。 @ f9eb2360ed36ルート：は/ usr / local / binの番号./redis-cli -p 6379 インフォサーバ ＃のサーバー redis_version： 4.0.14 redis_git_sha1： 00000000 redis_git_dirty： 0 redis_build_id：9ac979c18029eef1 redis_mode ：スタンドアロン OS ：Linuxの 3.10.0-514.26.2 。.el7 x86_64のx86_64での arch_bits： 64 multiplexing_api ：ファイルディスクリプタの atomicvar_api ：アトミック -builtin gcc_version： 6.3.0 process_idをする： 1 RUN_ID：49dbc223587cbdadd158adc21816979722b65ae1 TCP_PORT： 6379 uptime_in_seconds： 105 535 uptime_in_daysを： 1 ヘルツ： 10 lru_clock： 1086433 実行： /データ/ Redisの-サーバ CONFIG_FILE： 2.オフセット：マスターノード各時刻データCRUD 、マスタノードは、この変更の値が記録されている必要がありますマスターノードがデータを変更した場合、記録マークは、Redisのデータ変更をオフセットされ、
オフセットが対応する変化も発生するが、マスタノードデータの変更は、オフセット、同期にノードからのコマンドの比較があるかどうかを観察するために、マスターノードからのオフセットすることができるように、ノードからの矛盾の問題にマスターから送信されます。
./Redis-cli -p 6379を使用し、マスタノード情報の複製コマンドでマスターノードからのオフセットを表示します
複製の3.1全額
プロセス：
マスターノードに送信1. PSYNC、二つのパラメータがあり、最初のパラメータがRUNIDされ、第2のパラメータは、オフセット、最初の送信RUNIDマスターノードが知らないので、オフセット、スレーブノードを知りませんで送信しますか？-1
2.マスターノードはによると、メッセージを受信しますか？-1最初の複製を判定することができ、マスタノードは、に送信しRUNIDスレーブノードをオフセット
3.マスターノードのノードからの基本的な情報を保存します
4-5-6。マスタノードは、はるかRDBノードからファイル転送を生成するために、マスターノードまでデータを変更するためのコマンドが変更され、記録されたデータのその後の実行中に、スナップショットbgsaveを行います
書き込み操作の実行中にマスターノード、新しいマスターノードのデータは、バッファがからノードに送信されたレコードを変更します
前のノード7から8すべてのデータクリア、ロードRDBファイルの復元とデータが新しく変更されたデータに保存されています
説明：
- パフォーマンス・オーバーヘッド複製の合計量：... 1 bgsave時間は、ファイル5. 4.ロードRDB可能書き換えAOF、データの空時からRDB、ネットワークノード3との間のRDB 2ファイル転送時間を生成されたファイルを必要時間
- データ変更のためのコマンドバッファがrepl_back_buffer：Redisのは、フォークのLinuxで開かれた場合には（）関数は（そのようRDB bgsaveファイルを生成する場合、またはAOFファイルの実行bgrewriteaof主要なプロセスを生成したときに実行されるメインプロセスなど）その他の事項に対処するための子プロセスです、メイン処理（すなわち、クライアント・コマンドの処理手順）（空間が構成ファイルに配置することができるREPL-バックログサイズ1メガバイト）、その後の実行命令を一時領域に格納されているいくつかのデータ、および限られた空間領域内を変更します
3.2節コピー
一部の複製問題解決は：実際の環境では、マスタノードは、ノード間のネットワークから一部の変動であってもよいし、接続はノードとマスターノードとの間のネットワークから（Redisのマスターノードから閉鎖されていない）が失われています、再接続した場合は、ノードのデータから再実施マスター同期にコピーの全額を使用することができますが、複製の全額が問題パフォーマンスのオーバーヘッドを引き起こす可能性があり、かつノードからの大量のデータがプライマリノードで有することができる今までにもうありませんあなたは確かにいくつかの不要な廃棄物を持ち込まれ、レプリケーションの全額を使用した場合、再度データを同期させるために必要とされていません。だから、コピー機能の一部には、問題を解決することです。
プロセス：
マスターノードから1が直接接続され、切断され
前記マスタノードは、データ変更コマンドを実行するとrepl_back_bufferのバッファに記録され続けます
前記マスタノードからノードを再接続するとき、
4. 自动发出一条命令(psync offset run_id)，将从节点中存储的主节点的Redis运行时id和从节点中保存的偏移量发送给主节点
5. 主节点接收从节点发送的偏移量和id，对比此时主节点的偏移量和接收的偏移量，如果两个偏移量之差大于repl_back_buffer中的数据，那么就表示在断开连接期间从节点已经丢失了超出规定数量的数据，此时就需要进行全量复制了，否则就进行部分复制
6. 将主节点缓冲区中的数据同步更新到从节点中，这样就实现了部分数据的复制同步，降低了性能开销
四、主从节点的故障处理
- 故障发生时服务自动转移（自动故障转移）：即当某个节点发生故障导致停止服务时，该节点提供的服务会有另一个节点自动代替提供，这样就实现了一个高可用的效果
- 从节点故障：即如果某个从节点发生了故障，导致无法向在该节点上的客户端提供读服务，解决办法就是使该客户端转移到另一个可用从节点上，但是在转移时，应该考虑该从节点能承受几个客户端的压力
- 主节点故障：如果主节点发生故障，在使用主节点进行读写操作的客户端就无法使用了，而使用从节点只进行读操作的客户端还是可以继续使用的，解决办法就是从从节点中选一个节点更改为主节点，并且将原主节点的客户端连接到新的主节点上，然后通过该客户端将其他从节点连接到新的主节点中
- 主从复制确实可以解决故障问题，但是主从复制不能实现自动故障转移，其必须要通过一些手动操作，而且非常麻烦，所以要实现自动故障转移还需要另一个功能，Redis中提供了sentinel功能来实现自动故障转移。
五、主从节点的故障处理
1. 读写分离：即客户端发来的读写命令分开，写命令交给主节点执行，读命令交给从节点执行，不仅减少了主节点的压力，而且增强了读操作的能力；但也会造成一些问题
- 但是主从节点之间数据复制造成的阻塞延迟也可能会导致主从不一致的情况，也就是主节点先进行了写操作，但可能因为数据复制造成的阻塞延迟，导致在从节点上进行的读操作获取的数据与主节点不一致
- 读取过期数据：主从复制会将带有过期时间的数据一并复制到从节点中，但是从节点是没有删除数据的能力的，即使是过期数据，所以主节点中的已经删除了过期数据，但是因为主从复制的阻塞延迟问题导致从节点中的过期数据没有删除，此时客户端就会读到一个过期数据
2. 主从配置不一致：造成的问题有
- 比如配置中的maxmemory参数如果配置不一致，比如主节点2Gb，从节点1Gb，那么就可能会导致数据丢失；以及一些其他配置问题
3. 规避全量复制：全量复制的性能开销较大，所以要尽量避免全量复制，
- 在第一次建立主从节点关系式一定会发生全量复制；可以适当减小Redis的maxmemory参数，这样可以使得RDB更快，或者选择在客户端操作低峰期进行，比如深夜
- 从节点中保存的主节点run_id不一致时也一定会发生全量复制（比如主节点的重启）；可以通过故障转移来尽量避免，例如Redis Sentinel 与 Redis Cluster
- 当主从节点的偏移量之差大于命令缓冲区repl_back_buffer中对应数据的偏移差时，也会发生全量复制，也就是上面的部分复制的复制过程中所说的；可以适当增大配置文件中repl-backlog-size即数据缓冲区可尽量避免
4. 规避复制风暴：
- 单主节点导致的复制风暴，即当主节点重启后，要向其所有的从节点都进行一次全量复制，这非常消耗性能；可以更换主从节点的拓扑结构，更换为类似树形的结构，一个主节点只与少量的从节点建立主从关系，而而这些主节点又与其他从节点构成主从关系，
- 如图所示
- 单主节点机器复制风暴：即如果过一台机器专门用来部署多个主节点，然后其他机器部署从节点，那么一旦主节点机器宕机重启，就会引起所有的主从节点之间的全量复制，造成非常大的性能开销；可以采用多台机器，分散部署主节点，或者使用自动故障转移来将某个从节点变为主节点实现一个高可用
感谢支持，感谢观看。
参考：https://my.oschina.net/ProgramerLife/blog/2254321