マスタースレーブレプリケーションの原理を知る必要があるRedisの高度な知識ポイント

記事の内容

Redis永続RDBとAOFの原理と選択をマスターする
Redisマスタースレーブレプリケーションの原理を理解する
Redisマスター/スレーブレプリケーションを構成できる

1つは、Redisの永続性

Redisはインメモリデータベースです。データの耐久性を確保するために、2つの永続化ソリューションが提供されています。

RDBモード（デフォルト）

RDBメソッドはスナップショットによって完了します。特定の条件が満たされると、Redisは自動的にメモリ内のデータのスナップショットを取得し、それをハードディスクに保持します。

スナップショットをトリガーするタイミング

カスタム構成のスナップショットルールredis.confに準拠する
saveまたはbgsaveコマンドを実行します
flushallコマンドを実行する
マスタースレーブコピー操作を初めて実行する

回路図

スナップショット保存ルールを設定する

秒単位で変更されたデータ量を保存する

「」を保存：RDBストレージは適用されません

900を保存1：少なくとも1つのキーが900秒以内に変更され、スナップショットが作成されることを示します。

save 300 10：スナップショットを取得するために、5分以内に少なくとも10個のキーが変更されたことを示します。

save 60 10000：10000キーが1分以内に変更された場合にスナップショットが作成されることを示します。

予防：

Redisはスナップショットプロセス中にRDBファイルを変更せず、スナップショットの終了後に古いスナップショットファイルを新しいものに置き換えるだけです。つまり、RDBファイルはいつでも完了します。
これにより、RDBファイルを定期的にバックアップすることでRedisデータベースをバックアップできます。RDBファイルはパススルーさ压缩的二进制文件れ、メモリ内のデータよりも少ないスペースを占めるため、転送が容易になります。

RDBの長所と短所

短所：永続化にはRDBメソッドを使用します。バックアップの原則を理解している場合、Redisが異常停止または再起動すると、最後のスナップショット以降のすべてのデータ変更が失われることが簡単にわかります。現時点では、特定のアプリケーションシナリオに従って自動スナップショット条件を組み合わせて設定することにより、データ損失の可能性を許容範囲内に制御する必要があります。データが比較的重要であり、損失を最小限にしたい場合は、永続化にAOFを使用できます。

利点： RDBはRedisのパフォーマンスを最大化します。RDBファイルを生成するためにスナップショットを保存するときに親プロセスが行う必要があるのは、子プロセスをフォークすることだけであり、この子プロセスは後続のすべてのファイル保存作業を処理し、親プロセスはディスクを実行する必要がありません。 I / O操作。同時に、これも欠点であり、データセットが比較的大きい場合、フォークに時間がかかり、サーバーが一定期間クライアント要求の処理を停止する可能性があります。

AOFメソッド

Redisは、デフォルトではAOF（ファイルのみ追加）モードでの永続化を有効にしません。

AOF永続性を有効にした後、Redis のデータを変更するコマンドが実行されるたびに、Redisはそのコマンドをハードディスク内のAOFファイルに書き込みます。このプロセスにより、Redisのパフォーマンスが明らかに低下しますが、ほとんどの場合、この影響はさらに、より高速なハードディスクを使用すると、AOFのパフォーマンスが向上します。

redis.confを構成する

appendonly yes

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

上記の3つのパラメーターは、AOF永続性の開始、および永続ファイルの名前とファイルが配置されているディレクトリを指定します。

原理

AOFの原理を学ぶ前に、まずRESP（Redisシリアル化プロトコル）を理解する必要があります

AOFファイルには、reidsコマンドが格納されています。

AOF同期とRDBは、フォークプロセスで処理されるという点で似ています。

ここに画像の説明を挿入

AOF書き換えの原理（AOFファイルの最適化）

set s1 11
set s1 22

上記の操作で、AOFファイルが以前に最適化されていない場合、これらの2つのコマンドはRESPに従ってシリアル化されて保存されます。最適化された場合、次のコマンドであるs1 22のみが保存されます。同じキーの値は上書きされて保存されます最終結果。

書き換えプロセスの分析

Redisは新しいAOFファイルを作成するプロセスで、既存のAOFファイルにコマンドを追加し続けます。書き換えプロセス中にシャットダウンが発生しても、既存のAOFファイルは失われません。新しいAOFファイルが作成されると、Redisは古いAOFファイルから新しいAOFファイルに切り替え、新しいAOFファイルの追加を開始します。

トリガー条件を最適化します。

# 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准
auto-aof-rewrite-percentage 100
# 限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化
auto-aof-rewrite-min-size 64mb

RDBとAOFの選択方法

インメモリデータベース、データを失うことはありません：rdb（redisデータベース）+ aof
キャッシュサーバー：rdb
aofのみを使用することはお勧めしません（パフォーマンスが低い）
回復する場合：aofがある場合は、最初にaof回復を選択し、ない場合は、rdbファイルの回復を選択します。

2、Redisマスタースレーブレプリケーション

マスタースレーブレプリケーションとは何ですか？

要するに：

マスター外部スレーブ内部、マスター書き込み可能、書き込み不可
主は死んだ、決して主にならない

以下の図を参照して、理解を深めてください。

マスタースレーブ構成

次に、redisのマスター/スレーブアーキテクチャ構成を見てみましょう。

メインのredisは設定を必要としません
スレーブはredis.confファイル内の次の構成アイテムを変更する必要があります

port 6378  # 如果是使用的一台机器注意端口要与主机不同
# slaveof <masterip> <masterport>
# 表示当前【从服务器】对应的【主服务器】的IP是192.168.10.135，端口是6379。
slaveof 192.168.137.6 6379

実現原理

バージョン2.8以降、RedisはSYNCコマンドの代わりにPSYNCコマンドを使用して、レプリケーション中に同期操作を実行します。この記事では、現在のPSYNC同期の原理についてのみ説明しています。

完全同期（完全再同期）と部分同期（部分再同期）の2つのモードを持つPSYNCコマンド：

完全同期は、初期レプリケーション状況を処理するために使用されます。完全再同期の実行手順は、マスターサーバーにRDBファイルを作成および送信させ、バッファーに保存されている書き込みコマンドをスレーブサーバーに送信させることによって同期します。
部分同期は、切断後の再複製を処理するために使用されます。切断後にスレーブサーバーがマスターサーバーに再接続するとき、条件が許せば、マスターサーバーはマスタースレーブサーバーの切断中に実行された書き込みコマンドをスレーブサーバーに送信できます。、スレーブサーバーがこれらの書き込みコマンドを受信して実行する限り、マスターサーバーの現在の状態にデータベースを更新できます。

次の図は、部分再同期中のマスタースレーブサーバーの通信プロセスを示しています。

実際、私がこれを見たとき、私の心にはまだ疑問がありました：スレーブサーバーが長時間オフラインである場合、RDBファイルを介してSYNCコマンドを直接送信するよりも、そのような命令を1つの命令を送信する方が高速です。つまり、PSYNCを使用して操作を実行する場合、部分的に再同期する場合、および完全に再同期する場合はポリシーの問題です。もちろん、Redisがこの問題を解決するため、全員が0_0を見続けます。

部分同期

部分再同期機能は、次の3つの部分で構成されています。

オフセット複製マスターサーバー（複製オフセット）とスレーブ・サーバのオフセットレプリケーション。
プライマリサーバーのレプリケーションバックログ（レプリケーションバックログ）;
サーバーの実行ID（実行ID）。

オフセットをコピー

レプリケーションを実行する2つのパーティ（マスターサーバーとスレーブサーバー）はレプリケーションオフセットを維持します。

マスターサーバーがスレーブサーバーにNバイトのデータを送信するたびに、コピーオフセット値にNを追加します。
スレーブサーバーは、マスターサーバーから送信されたNバイトのデータを受信するたびに、自身のコピーオフセット値にNを追加します。

マスターサーバーとスレーブサーバーのレプリケーションオフセットを比較することにより、プログラムはマスターサーバーとスレーブサーバーが一貫した状態にあるかどうかを簡単に知ることができます。

マスターサーバーとスレーブサーバーが一貫した状態にある場合、マスターサーバーとスレーブサーバーのオフセットは常に同じです。
逆に、マスターサーバーとスレーブサーバーのオフセットが同じでない場合、マスターサーバーとスレーブサーバーは一貫した状態ではありません。

次のような状況：

スレーブサーバーAが切断直後にマスターサーバーに再接続して成功したとすると、スレーブサーバーはPSYNCコマンドをマスターサーバーに送信し、スレーブサーバーAの現在のレプリケーションオフセットが10107であることを報告し、次にマスターサーバーはスレーブサーバーの完全な再同期または部分的な再同期を実行する必要がありますか？部分的な再同期が実行された場合、マスターサーバーは、切断中にスレーブサーバーAによって失われたデータの一部をどのように補償しますか？上記の質問への回答はすべて、バックログバッファーのコピーに関連しています。

バックログバッファをコピー

レプリケーションバックログバッファーは、マスターサーバーによって維持される固定サイズの先入れ先出し（FIFO）キューであり、デフォルトのサイズは1MBです。

要素の増減に応じて長さを動的に調整する通常の先入れ先出しキューとは異なり、固定長の先入れ先出しキューの長さは固定されています。キュー内の要素の数がキューの長さより大きい場合、キュー内の最初の要素はポップすると、新しい要素がキューに入れられます。

図に示すように、マスターサーバーはコマンドの伝達を実行するときに、すべてのスレーブサーバーに書き込みコマンドを送信するだけでなく、書き込みバックログバッファーに書き込みコマンドをキューイングします。

したがって、プライマリサーバーのコピーバックログバッファーは、最近送信された書き込みコマンドの一部を格納し、コピーバックログバッファーは、次の表に示すように、キュー内の各バイトに対応するコピーオフセットを記録します：

スレーブサーバーがマスターサーバーに再接続すると、スレーブサーバーはPSYNCコマンドを介してそのレプリケーションオフセットオフセットをマスターサーバーに送信し、マスターサーバーはレプリケーションオフセットに従ってスレーブサーバーで実行する同期操作を決定します。

オフセットオフセットの後のデータ（つまり、オフセットoffset + 1から始まるデータ）がレプリケーションバックログバッファーにまだ存在する場合、マスターサーバーはスレーブサーバーで部分的な再同期操作を実行します。
逆に、オフセット後のデータがコピーバックログバッファーに存在しない場合、マスターサーバーはスレーブサーバーで完全な再同期操作を実行します。

必要に応じて、コピーバックログバッファーのサイズを調整します。

Redisがレプリケーションバックログバッファーに設定するデフォルトのサイズは1MBです。マスターサーバーが多数の書き込みコマンドを実行する必要がある場合、またはマスターサーバーとスレーブサーバーが切断された後、再接続に長い時間がかかる場合、このサイズは適切ではない可能性があります。コピーバックログバッファーのサイズが不適切に設定されている場合、PSYNCコマンドのコピー再同期モードは正常に機能しないため、コピーバックログバッファーのサイズを正しく見積もり、設定することは非常に重要です。

コピーバックログバッファーの最小サイズは、second * write_size_per_secondという式に従って推定できます。

ここで、secondは、スレーブサーバーが切断された後、マスターサーバーに再接続するのに必要な平均時間（秒単位）です。
また、write_size_per_secondは、メインサーバーによって生成される1秒あたりの平均書き込みコマンドデータボリュームです（プロトコル形式（RESPプロトコル）での書き込みコマンドの長さの合計）。

たとえば、マスターサーバーが1秒あたり平均1 MBの書き込みデータを生成し、スレーブサーバーが切断されてからマスターサーバーに再接続するのに平均5秒かかる場合、レプリケーションバックログバッファーのサイズは5 MB未満にはできません。

安全上の理由から、コピーバックログバッファーのサイズは2 *秒* write_size_per_secondに設定できるため、ほとんどの切断は部分的な同期で処理できます。

レプリケーションバックログのバッファーサイズの変更方法repl-backlog-sizeとして、オプションの説明については構成ファイルを参照してください。

サーバー実行ID

オフセットのコピーとバックログバッファーのコピーに加えて、サーバーの実行ID（実行ID）も部分的な再同期を実現するために必要です。

各Redisサーバーは、マスターサーバーでもスレーブサービスでも、独自の実行IDを持ちます。
実行中のIDはサーバーの起動時に自動的に生成され、53b9b28df8042fdc9ab5e3fcbbbabff1d5dce2b3などの40のランダムな16進文字で構成されます。

スレーブサーバーが初めてマスターサーバーをコピーすると、マスターサーバーは実行中のIDをスレーブサーバーに送信し、スレーブサーバーは実行中のIDを保存します（スレーブサーバーはマスターサーバーのIDを保存することに注意してください）。

スレーブサーバーが切断してマスターサーバーに再接続すると、スレーブサーバーは以前に保存した実行IDを現在接続しているマスターサーバーに送信します。

スレーブサーバーによって保存された実行中のIDが現在接続されているマスターサーバーの実行中のIDと同じである場合、スレーブサーバーが切断される前に現在接続されているマスターサーバーがコピーされ、マスターサーバーは部分的な再同期操作を引き続き試行できます。
逆に、スレーブサーバーによって保存された実行IDが現在接続されているマスターサーバーの実行IDと同じでない場合、スレーブサーバーが切断される前に複製されたマスターサーバーは現在接続されているマスターサーバーではなく、マスターサーバーはスレーブサーバーで実行を実行します完全な再同期操作。

PSYNCコマンドの実装

PSYNCコマンドを呼び出す方法は2つあります。

スレーブサーバーが以前にマスターサーバーを複製したことがない場合、または以前にSLAVEOFのコマンドを実行していない場合、スレーブサーバーは新しい複製の開始時にPSYNC？-1コマンドをマスターサーバーに送信し、完全な再同期を実行するようマスターサーバーにアクティブに要求します（現在、部分的な再同期を実行することは不可能であるため）。
逆に、スレーブサーバーが特定のマスターサーバーを既に複製している場合、スレーブサーバーは新しい複製を開始するときにPSYNCコマンドをマスターサーバーに送信します。runidは前回複製されたマスターサーバーの実行IDで、オフセットはスレーブです。サーバーの現在のレプリケーションオフセット。このコマンドを受信するマスターサーバーは、これらの2つのパラメーターを使用して、スレーブサーバーで実行する同期操作を決定します。

状況に応じて、PSYNCコマンドを受信したマスターサーバーは、スレーブサーバーに次の3つの応答のいずれかを返します。

マスターサーバーが+ FULLRESYNC応答を返す場合、これはマスターサーバーがスレーブサーバーとの完全な再同期操作を実行することを意味します。runidはマスターサーバーの実行IDであり、スレーブサーバーはこのIDを保存し、次にPSYNCコマンドが送信されるときにそれを使用します。 offsetはマスターサーバーの現在のレプリケーションオフセットであり、スレーブサーバーはこの値を初期オフセットとして使用します。
マスターサーバーが+ CONTINUE応答を返した場合、マスターサーバーはスレーブサーバーとの部分的な再同期操作を実行し、スレーブサーバーはマスターサーバーがデータの欠落部分を送信するのを待つだけで済みます。
マスターサーバーが-ERR応答を返す場合は、マスターサーバーのバージョンがRedis 2.8よりも低く、PSYNCコマンドを認識できないことを意味します。スレーブサーバーはSYNCコマンドをマスターサーバーに送信し、マスターサーバーとの完全な同期操作を実行します。

上記では、redisマスター/スレーブ同期時に、最下層が完全同期または部分同期のどちらを使用するかを詳細に説明しました。増分同期と部分同期のプロセス全体を見てみましょう。

Redisの完全同期プロセスは、主に3つの段階に分かれています。

同期スナップショットステージ：マスターがスナップショットを作成してスレーブに送信し、スレーブがスナップショットを読み込んで解析します。マスターはまた、このステージで生成された新しい書き込みコマンドをバッファーに格納します。
同期書き込みバッファーフェーズ：マスターは、バッファーに保存されている書き込み操作コマンドをスレーブに同期します。
同期インクリメンタルフェーズ：マスターは書き込み操作コマンドをスレーブに同期します。

増分同期

Redis増分同期とは、主に、初期化の完了後の通常の操作の開始時の書き込み操作をSlave指します。スレーブ、マスターが偶然プロセスを同期しました。
通常、マスターは書き込みコマンドを実行するたびに、同じ書き込みコマンドをスレーブに送信し、スレーブはそれを受信して実行します。

参考資料：

https://www.cnblogs.com/lukexwang/p/4711977.html