レプリケーションの概要
非リレーショナルデータベースであるRedisは、リレーショナルデータベース（MySQL）と同じレプリケーション機能を備えており、実現原理が異なります。Redisのレプリケーション機能は、他のメモリデータベース（memcached）にも固有のものです。
Redisレプリケーション機能の主な役割は、クラスタリングおよびシャーディング機能を実現するための基盤です。また、単一マシンの同時実行の問題、データセキュリティ、その他の問題の解決など、Redisが高可用性を実現するための戦略でもあります。
サービス紹介
この記事の環境デモンストレーションでは、ホストがあり、2つのRedisの例が開始されています。
実現する方法
Redisレプリケーションは、次の3つの方法で実装できます。
1.サービスの開始時刻を構成します
このメソッドは、コマンドラインパラメーターを使用して、Redisサービスの開始時にマスター/スレーブレプリケーション機能を開始します。この方法の欠点は、構成の永続性を実現できないことです。サービスを停止してサービスを開始するときに、同じコマンドパラメータを追加する必要があります。
1.1マスターサーバーは事前にredis.confgにrequirepassアイテムを追加します。
requirepass 6379
1.2スレーブサーバーを起動します。
redis-server --port 6380 --replicaof 192.168.2.102 6379
2.コマンドライン構成
このメソッドは、redis-cliを使用して、構成用の操作ラインインターフェイスに入ります。この方法の欠点は、構成の永続性を実現できないことです。サービスを停止すると、同じコマンドを実行してサービスを開始する必要があります。
2.1マスターサーバーが実行されます。
127.0.0.1:6379> config set requirepass 6379OK
2.2サーバーから実行します。
127.0.0.1:6380>192.168.2.102のレプリカ6379OK127.0.0.1：6380> config set masterauth 6379OK
3.構成ファイルの構成
この方法は、redis.conf構成ファイルを介して設定されます。これは、構成の永続性を実現できるため、推奨される方法です。
3.1メインサーバーredis.configを構成します。
requirepass 6379
3.2スレーブサーバーredis.configを構成します。
masterauth 6379replicaof 192.168.2.102 6379
4.構成手順
1. masterauth：この値が設定されている場合は、redis.confi接続パスワードを設定します。他のクライアントがサーバーに接続するときは、アクセスする前にパスワードを追加する必要があります。
2. requirepass：マスターサーバーの接続パスワードを設定します。これは1のmasterauthと一致します。
3. Replicaof：サーバーからサーバーのIPアドレス+ポート番号に接続します。
効果テスト
1.メインサーバーにデータを追加します。
2.サーバーからデータを取得します。
実現原理
// uml figure @startumlスレーブサーバー->マスターサーバー：1。構成の保存 スレーブサーバー->マスターサーバー：2。ソケット接続の確立 スレーブサーバー->マスターサーバー：3。 サーバーからpingコマンドを送信->マスターサーバー：4。承認の検証 スレーブサーバー->マスターサーバー：5。データの同期 スレーブサーバー->マスターサーバー：6。データのコピーを続行@enduml
マスタースレーブレプリケーションの主な実装プロセスは、上の図に示すとおりです。
1.最初のステップで、スレーブサーバーはマスターサーバーの構成情報を保存します。保存後、スレーブサーバー内のタイマーが実行されると、レプリケーションプロセスがトリガーされます。
2. 2番目のステップでは、スレーブサーバーは最初にマスタースレーブ通信のためにマスターサーバーとのソケットソケット接続を確立します。その後、マスターサーバーはこのバイトセットを介してスレーブサーバーにデータを送信します。
3. 3番目のステップでは、ソケットソケットが正常に接続された後、authentication pingコマンドが送信されます。通常の状況では、メインサーバーは対応する応答を送信します。pingコマンドの機能は、ソケットソケットバイトを使用できるかどうかを確認し、メインサーバーが操作コマンドを受け入れるかどうかを確認することです。
4. 4番目のステップとそれに続く認証検証は、スレーブノードによって構成されたマスターノード接続パスワードが正しいかどうかを判別することです。
5.第五步，鉴权成功之后，就可以开始复制数据了。主服务器此时会进行全量复制，将主服务的数据全部发给从服务器，从服务器保存主服务器发送的数据。
6.接下来就是持续复制操作。主服务器会进行异步复制，一边将写的数据写入自身，同时会将新的写命令发送给从服务器。
实现策略
Redis主从复制主要分为三种弄策略方式，不同的策略方式都是针对不同的场景下进行使用。三种场景方式分别如下:
1.全量复制。全量复制用在主从复制刚建立时或者从切主服务器时，从服务器没有主服务器的数据，主服务器会将自身的数据通过rdb文件方式发送给从服务器，从服务器会清空自身数据，接着将主服务器发送的数据加载到自身中。
// uml图@startuml从服务器->主服务器: 1.psync ? -1主服务器->从服务器: 2.fullsync runid offset 从服务器: 3.保存 runid offset 主服务器: 4.执行bgsave生成rdb 主服务器->从服务器: 5.发送rdb 从服务器: 6.清空自身老数据 从服务器: 7.加载主服务器数据@enduml
2.部分复制。部分复制用在一些异常情况下，例如主从延迟、从服务宕机之后重新启动接收主服务器发送的部分数据。
部分复制的实现主要依赖于复制缓存区、主服务的runid、主从服务器各自的复制偏移量(offset)。
复制缓存区：主服务在接收写命令时，会将命令写入缓存区，以便从服务器在异常情况下，减少数据的丢失。当从服务器正常连接之后，主服务器会将缓存区内的数据发送给从服务器。这里的缓存区是一个长队列。
メインサーバーのrunid：メインサーバーは、サービスが開始されるたびに、独自のIDとして一意のIDを生成します。スレーブサーバーは識別子を保存し、いくつかのコピーコマンドを送信するときにrunidを使用します。
psyncrunidオフセット
マスタースレーブレプリケーションのそれぞれのオフセット：マスタースレーブサービスがレプリケーションを確立した後、独自のオフセットがあります。スレーブノードは、毎秒独自のレプリケーションオフセットをスレーブノードに送信します。マスターノードが書き込みコマンドを送信した後、スレーブノードも独自のレプリケーションオフセットを増やします。マスターノードは、各書き込みコマンドの後に独自のオフセットも増やします。ここでのオフセットは、コマンドのバイト長を累積することによって計算されます。
3.非同期レプリケーション。非同期レプリケーションとは、マスターとスレーブ間のレプリケーション関係の確立を指し、マスターサーバーとスレーブサーバーは引き続きレプリケーション関係を維持します。
シーンの問題
1.データセキュリティ。
//サーバーから読み取り専用レプリカ読み取り専用はい//サーバー接続パスワードからmasterauth
2.データの遅延。
デフォルトでは、マスターノードに新しいデータがある場合、そのデータはすぐにスレーブサーバーに送信されません。オンになっている場合、マスターノードはすぐにスレーブサーバーに送信されます。Linuxカーネルでは、デフォルトの時刻は拒否されます。
//レプリケーション遅延repl-disable-tcp-nodelayyes
3.マスターノードとスレーブノードの接続ステータス。
マスタースレーブノードが接続を確立すると、相手のクライアントを定期的に模倣して、相手のサービスステータスを検出します。マスターノードは、repl-ping-replica-period構成パラメーターを設定することで設定できます。デフォルトの頻度は10秒です。
スレーブノードがreplconfack {offsetid}を実行すると、スレーブノードは独自のレプリケーションオフセットもマスターサーバーに送信し、マスターサーバーはオフセットに基づいてデータ遅延を決定します。データ遅延がある場合、対応するデータがコピーバックログバッファのデータシンクからスレーブノードに再発行されます。