永続性: 永続性は最も単純な高可用性方法です (高可用性方法として分類されていない場合もあります)。その主な機能はデータのバックアップ、つまり、プロセスによってデータが失われないようにデータをハードディスクに保存することです。出口。

マスター/スレーブレプリケーション: マスター/スレーブレプリケーションは高可用性 Redis の基礎であり、Sentinel とクラスターは高可用性を実現するためにマスター/スレーブレプリケーションに基づいています。マスター/スレーブレプリケーションでは、主にデータのマルチマシンバックアップ、読み取り操作の負荷分散、および単純な障害回復が実装されます。欠点: 障害回復は自動化できません。書き込み操作の負荷分散はできません。ストレージ容量は 1 台のマシンによって制限されます。

Sentinel: Sentinel は、マスター/スレーブレプリケーションに基づいて、自動障害回復を実装します。欠点: 書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。

クラスター: Redis はクラスター化を通じて、書き込み操作の負荷分散ができず、ストレージ容量が単一マシンによって制限されるという問題を解決し、比較的完全な高可用性手法を実現します。

2. Rdies の永続性

2.1 永続化機能

Redis はインメモリデータベースであり、データはメモリ上に保存されますが、サーバーの電源障害などの理由で Redis プロセスが異常終了した後、データが永久に失われることを避けるために、定期的にデータをメモリ上に保存する必要があります。 Redis をメモリから何らかの形式 (データまたはコマンド) でハードディスクに保存します。次回 Redis を再起動するときに、永続ファイルを使用してデータを回復します。さらに、永続ファイルは、災害時バックアップの目的でリモートの場所にコピーできます。

2.2 Redis は永続化のための 2 つの方法を提供します

RDB 永続性 (Redis データベース): 原則は、メモリ内の Reid データベースレコードを定期的にディスクに保存することです。

AOF 永続性 (追加のみのファイル): 原理は、MySQL の binlog と同様に、Reid の操作ログを追加の方法でファイルに書き込むことです。

概要: AOF 永続化のリアルタイムパフォーマンスが優れているため、つまり、プロセスが予期せず終了した場合に失われるデータが少ないため、現在 AOF が主流の永続化方法ですが、RDB 永続化も依然としてその地位を占めています。

3. RDB の永続化

RDB 永続化とは、メモリ上の現在のプロセスのデータのスナップショットを指定された時間間隔でハードディスクに保存することを指し (そのため、スナップショット永続化とも呼ばれます)、バイナリ圧縮で保存され、保存されたファイルのサフィックスは rdb です。 ; Redis が再起動すると、スナップショットファイルを読み取ってデータを復元できます。

3.1 トリガー条件

RDB永続化のトリガーは手動トリガーと自動トリガーに分かれます。

3.1.1 手動トリガー

save コマンドと bgsave コマンドの両方で RDB ファイルを生成できます。

save コマンドは、RDB ファイルが作成されるまで Redis サーバープロセスをブロックします。Redis サーバーのブロック中、サーバーはコマンドリクエストを処理できません。

bgsave コマンドは子プロセスを作成し、子プロセスが RDB ファイルの作成を担当します。一方、親プロセス (つまり、Redis メインプロセス) はリクエストの処理を続行します。

bgsave コマンドの実行中、fork 子プロセスのみがサーバーをブロックしますが、save コマンドの場合はプロセス全体がサーバーをブロックするため、save は基本的に放棄されており、save の使用は必須です。オンライン環境では防止されます

3.1.2 自動トリガー

RDB 永続化を自動的にトリガーする場合、Redis は永続化のために保存する代わりに bgsave を選択します。
自動トリガーの最も一般的なケースは、構成ファイルで save mn を渡し、m 秒以内に n 回の変更が発生したときに bgsave がトリガーされるように指定することです。

vim /etc/redis/6379.conf
#---------219行以下三个save条件满足任意一个时，都会引起bgsave的调用-----
save 900 1 ：当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10 ：当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 ：当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave
#---------242行是否开启RDB文件压缩---------------------------------------
rdbcompression yes
#---------254行指定RDB文件名----------------------------------------------
dbfilename dump.rdb
#---------264行指定RDB文件和AOF文件所在目录-------------------------------
dir /var/lib/redis/6379

3.1.3その他の自動トリガーメカニズム

savemn に加えて、bgsave をトリガーする状況が他にもいくつかあります。

マスター/スレーブレプリケーションシナリオでは、スレーブノードがフルコピー操作を実行すると、マスターノードは bgsave コマンドを実行し、rdb ファイルをスレーブノードに送信します。
shutdownコマンドを実行すると、自動的にRDB永続化が実行されます。

3.1.4 実行プロセス

Redis の親プロセスはまず、現在 save を実行しているか、bgsave/bgrewriteaof の子プロセスを実行しているかを判断します。実行中の場合、bgsave コマンドは bgsave/bgrewriteaof の子プロセスを直接返し、同時に実行することはできません。主にパフォーマンスの考慮事項に基づいています: 2 つの同時実行子プロセスは同時に多数のディスク書き込み操作を実行するため、重大なパフォーマンスの問題が発生する可能性があります。

親プロセスは子プロセスを作成するためにフォーク操作を実行しますが、このプロセス中、親プロセスはブロックされ、Redis はクライアントからのコマンドを実行できません。

親プロセスがフォークすると、bgsave コマンドは「バックグラウンド保存が開始されました」というメッセージを返し、親プロセスをブロックしなくなり、他のコマンドに応答できるようになります。

子プロセスは RDB ファイルを作成し、親プロセスのメモリスナップショットに基づいて一時スナップショットファイルを生成し、完了後に元のファイルをアトミックに置き換えます。

子プロセスは親プロセスに完了を示すシグナルを送信し、親プロセスは統計を更新します。

3.1.5 起動時のロード

RDBファイルのロードはサーバ起動時に自動的に実行され、特別なコマンドは必要ありません。ただし、A0F の優先度が高いため、AOF がオンになっている場合、Redis は最初に AOF ファイルをロードしてデータを復元します。A0F がオフの場合にのみ、Redis サーバーの起動時に RDB ファイルが検出され、自動的にロードされます。RDB ファイルのロード中、ロードが完了するまでサーバーはブロックされます。

Redis は RDB ファイルをロードするときに RDB ファイルを検証しますが、ファイルが破損している場合はログにエラーが出力され、Redis は起動できません。

4. AOF の永続性

RDB 永続性はプロセスデータをファイルに書き込むことですが、AOF 永続性は Redis によって実行された各書き込みおよび削除コマンドを別のログファイルに記録し、クエリ操作は記録されません。Redis が再起動すると、AOF ファイルコマンドを再度実行します。データを復元します。
AOFは RDB と比較してリアルタイム性が優れているため、永続化ソリューションの主流となっています。

4.1 AOFをオンにする

Redis サーバーはデフォルトで RDB を有効にし、AOF を無効にします。AOF を有効にするには、/etc/redis/6379.conf構成ファイルで構成する必要があります。

vim /etc/redis/6379.conf
--700行--修改，开启AOF
appendonly yes
--704行--指定A0F文件名称
appendfilename "appendonly.aof"
--796行--是否忽略最后一条可能存在问题的指令
aof-load-truncated yes
 
/etc/init.d/redis_6379 restart   重启服务

4.2 実行プロセス

Redis の各書き込みコマンドを記録する必要があるため、A0F をトリガーする必要はありません。AOF の実行プロセスは次のとおりです。

コマンド append (append) : Redis 書き込みコマンドをバッファー aof_ buf に追加します。
ファイル書き込み (write) とファイル同期 (sync) : さまざまな同期戦略に従って、aof_buf の内容をハードディスクに同期します。
ファイルの書き換え (リライト): 圧縮の目的を達成するために、AOF ファイルを定期的に書き換えます。

4.2.1命令追加(append)

Redis は、ファイルに直接書き込むのではなく、最初に書き込みコマンドをバッファーに追加します。これは主に、毎回コマンドを直接ハードディスクに書き込むことを回避するためであり、ハードディスク IO が Redis 負荷のボトルネックになるのを防ぎます。

コマンド append の形式は、Redis コマンドリクエストのプロトコル形式であり、プレーンテキスト形式であり、互換性が高く、可読性が高く、処理が容易で、操作が簡単で、二次的なオーバーヘッドが回避されるという利点があります。A0F ファイルでは、データベースの指定に使用される select コマンド (データベース 0 を選択する select0 など) を除き、Redis によって追加され、その他はすべてクライアントによって送信される書き込みコマンドです。

4.2.2ファイル書き込み（write）とファイル同期（sync）

Redis は、AOF キャッシュ領域に対してさまざまな同期ファイル戦略を提供しており、この戦略には、次のように、オペレーティングシステムの write 関数と fsync 関数が含まれます。

ファイルの書き込み効率を向上させるために、最新のオペレーティングシステムでは、ユーザーがファイルにデータを書き込むために書き込み関数を呼び出すと、通常、オペレーティングシステムはデータをメモリバッファに一時的に保存します。バッファがいっぱいになるか、指定された After を超えると、制限時間が経過すると、バッファ内のデータが実際にハードディスクに書き込まれます。この種の操作は効率を向上させますが、セキュリティ上の問題も引き起こします: コンピュータが停止するとメモリバッファ内のデータが失われるため、システムはオペレーティングシステムに強制的に実行させる fsync や fdatasync などの同期機能も提供します。バッファ内のデータをただちに転送しますデータのセキュリティを確保するために、データはハードディスクに書き込まれます。

AOF キャッシュ領域の同期ファイル戦略には、次の 3 つの同期方法があります。

vim /etc/redis/6379.conf
 
---729---
● appendfsync always:
解释：命令写入aof_ buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。
	 这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，
	 严重降低了Redis的性能；即便是使用固态硬盘(SSD)，每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。
 
● appendfsync no:
解释：命令写入aof_ buf后调用系统write操作，不对AOF文件做fsync同步;
	 同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，
	 且缓冲区中堆积的数据会很多，数据安全性无法保证。
 
● appendfsynceverysec:
解释：命令写入aof_ buf后调用系统write操作，write完成后线程返回; 
	 fsync同步文件操作由专门的线程每秒调用一次。
	 everysec是前述两种策略的折中，是性能和数据安全性的平衡，
	 因此是Redis的默认配置，也是我们推荐的配置。

4.2.3 ファイルの書き換え（リライト）

時間が経つにつれて、Redis サーバーはより多くの書き込みコマンドを実行し、AOF ファイルはますます大きくなります。AOF ファイルが大きすぎると、サーバーの通常の動作に影響を与えるだけでなく、データの回復に時間がかかりすぎる原因になります。。

ファイルの書き換えとは、AOF ファイルのサイズを減らすために AOF ファイルを定期的に書き換えることを指します。AOF の再書き込みは、Redis プロセス内のデータを書き込みコマンドに変換し、新しい AOF ファイルに同期することであり、古い AOF ファイルに対して読み取りまたは書き込み操作は実行されないことに注意してください。

ファイルの書き換えに関するもう 1 つの注意点: AOF 永続性の場合、ファイルの書き換えが強く推奨されますが、必須ではありません。ファイルの書き換えがなくても、データは永続化され、Redis 時間インポートで開始できます。そのため、実装によっては、自動ファイル書き換えが有効になります。オフにすると、スケジュールされたタスクが毎日特定の時刻に実行されます。

4.2.4 ファイル書き換えにより AOF ファイルが圧縮される理由

期限切れのデータはファイルに書き込まれなくなります

一部のデータが繰り返し設定される (set mykey v1、set mykey v2)、一部のデータが削除される (sadd myset v1、del myset) など、無効なコマンドがファイルに書き込まれなくなりました。

複数のコマンドを 1 つに結合できます。たとえば、sadd myset v1、sadd myset v2、sadd myset v3 は、sadd myset v1 v2 v3 に結合できます。

上記の内容から、書き換え後はAOFで実行するコマンドが削減されるため、ファイル書き換えによりファイルの占有容量が削減されるだけでなく、復旧速度も高速化できることがわかります。

4. 3 ファイル書き換えのトリガーは手動トリガーと自動トリガーに分かれます

手動トリガー: bgrewriteaof コマンドを直接呼び出します。このコマンドの実行は bgsave に似ています。両方の fork サブプロセスが特定の作業を実行し、fork 時のみ両方がブロックされます。

自動トリガー: BGREWRITEAOF は、auto-aof-rewrite-min-size オプションと auto-aof-rewrite-percentage オプションを設定することによって自動的に実行されます。auto-aof-rewrite-min-size と auto-aof-rewrite-percentage の 2 つのオプションが同時に満たされた場合にのみ、AOF 書き換え、つまり bgrewriteaof 操作が自動的にトリガーされます。

vim /etc/redis/6379.conf
----771----
auto-aof-rewrite-percentage 100
#当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作
auto-aof-rewrite-min-size 64mb
#当前A0F文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWR ITEAOF

4.4ファイル書き換えの流れ

关于文件重写的流程，有两点需要特别注意：
1.重写由父进程fork子进程进行；
2.重写期间Redis执行的写命令，需要追加到新的AOF文件中，为此Redis引入了aof_rewrite_buf缓存。

Redis の親プロセスは、まず bgsave/bgrewriteaof を実行している子プロセスが存在するかどうかを判断し、存在する場合は bgrewriteaof コマンドを直接返します。bgsave コマンドがある場合は、bgsave の実行が完了するのを待って実行します。

親プロセスはフォーク操作を実行して子プロセスを作成しますが、親プロセスはこのプロセス中にブロックされます。

親プロセスがフォークすると、bgrewriteaof コマンドは「バックグラウンド追加のみのファイル書き換えが開始されました」というメッセージを返し、親プロセスをブロックしなくなり、他のコマンドに応答できるようになります。Redis のすべての書き込みコマンドは引き続き AOF バッファーに書き込まれ、appendfsync 戦略に従ってハードディスクに同期され、元の AOF メカニズムの正確性が保証されます。

フォーク操作ではコピーオンライト技術が使用されるため、子プロセスはフォーク操作中にのみメモリデータを共有できます。親プロセスはまだコマンドに応答しているため、Redis は AOF 書き換えバッファー (aof_rewrite_buf) を使用してデータのこの部分を保存し、新しい AOF ファイルの生成中にデータのこの部分が失われるのを防ぎます。つまり、bgrewriteaof の実行中に、Redis 書き込みコマンドが 2 つのバッファー aof_buf と aof_rewrite_buf に同時に追加されます。

子プロセスは、メモリスナップショットに基づくコマンドマージルールに従って、新しい AOF ファイルに書き込みます。

子プロセスが新しい AOF ファイルを書き込んだ後、親プロセスにシグナルを送信し、親プロセスは統計情報を更新します。統計情報は情報永続化を通じて表示できます。

親プロセスは、AOF 書き換えバッファ内のデータを新しい AOF ファイルに書き込みます。これにより、新しい AOF ファイルに保存されたデータベースの状態がサーバーの現在の状態と一致することが保証されます。

古いファイルを新しい AOF ファイルに置き換えて、AOF の書き換えを完了します。

4.5起動時のロード

AOF がオンになっている場合、Redis は起動時に最初に AOF ファイルをロードしてデータを復元しますが、AOF がオフになっている場合にのみ、RDB ファイルをロードしてデータを復元します。

AOFが有効でAOFファイルが存在しない場合、RDBファイルが存在してもロードされません。

Redis は AOF ファイルをロードするときに AOF ファイルを検証します。ファイルが破損している場合はログにエラーが出力され、Redis は起動できません。ただし、AOF ファイルの末尾が不完全で (突然のマシンのダウンタイムによりファイルの末尾が不完全になる可能性があります)、aof-load-truncated パラメーターが有効になっている場合、ログに警告が出力されますが、Redis は無視します。 AOF ファイルの終わりに達すると、起動は成功します。
aof-load-truncated パラメータはデフォルトで有効になっています。

5. RDBとAOFのメリットとデメリット

5.1 RDB永続化のメリットとデメリット

利点: RDB ファイルはコンパクトでサイズが小さく、ネットワーク転送が速く、フルコピーに適しており、復元速度は AOF よりもはるかに高速です。もちろん、AOF と比較した RDB の最も重要な利点の 1 つは、パフォーマンスへの影響が比較的小さいことです。

短所: RDB ファイルの致命的な欠点は、データスナップショットの永続化方法により、リアルタイムの永続化が達成できないと判断されることです。データの重要性がますます高まっている現在、大量のデータ損失はしばしば許容できないため、AOF 永続化が必要です。主流になる。さらに、RDB ファイルは特定の形式を満たす必要があり、互換性が低くなります (たとえば、古いバージョンの Redis は新しいバージョンの RDB ファイルと互換性がありません)。RDB 永続性の場合、bgsave がフォーク操作を実行するときに Redis メインプロセスがブロックされる一方で、子プロセスによるハードディスクへのデータの書き込みも IO プレッシャーをもたらします。

5.2 AOF 永続化の長所と短所

AOF は、RDB の永続化に対応し、第 2 レベルの永続化に対応し、互換性が高いことがメリットですが、デメリットは、ファイルが大きく、回復速度が遅く、パフォーマンスに大きな影響を与えることです。
AOF 永続性の場合、ハードディスクにデータを書き込む頻度が大幅に増加し (毎秒戦略の 2 番目のレベル)、IO プレッシャーが大きくなり、AOF の追加のブロッキング問題が発生する可能性もあります。
AOF ファイルの書き換えは RDB の bgsave と似ており、fork および子プロセスの I0 プレッシャー中にブロックが発生します。比較的に、AOF はハードディスクにデータをより頻繁に書き込むため、Redis メインプロセスのパフォーマンスに大きな影響を与えます。

6. Redis のパフォーマンス管理

6.1 Redis のメモリ使用量を表示する

----- 查看Redis内存使用 -----
 
redis-cli -h 192.168.40.172 -p 6379
192.168.40.172:6379> info memory

6.2 メモリの断片化率

オペレーティングシステムによって割り当てられたメモリ値 used_memory_rss は、Redis によって使用されるメモリ値 used_memory で除算され、オペレーティングシステムによる物理メモリの非効率な割り当て/再利用 (不連続な物理メモリ割り当て) によって引き起こされるメモリ断片化を計算します。

メモリ断片化率を追跡することは、Redis インスタンスのリソースパフォーマンスを理解するために非常に重要です。

メモリの断片化率が 1 よりわずかに大きいのは妥当です。この値は、メモリの断片化率が比較的低いことを示します。

メモリ断片化率が 1.5 を超える場合、Redis が実際の物理メモリを 150 個消費し、そのうち 50 個がメモリ断片化率であることを意味します。redis-cli ツールで shutdown save コマンドを入力し、Redis サーバーを再起動する必要があります。

メモリ断片化率が 1 より低い場合は、Redis メモリ割り当てが物理メモリを超えており、オペレーティングシステムがメモリを交換していることを意味します。利用可能な物理メモリを増やすか、Redis メモリの使用量を減らす必要がある

6.3メモリ使用量

Redis インスタンスのメモリ使用量が利用可能な最大メモリを超えているため、オペレーティングシステムはメモリとスワップスペースの交換を開始します。

メモリのスワップを回避する方法:

キャッシュされたデータのサイズに応じて Redis インスタンスのインストールを選択します

可能な限りハッシュデータ構造ストレージを使用する

キーの有効期限を設定する

6.4 以内にキーをリサイクルする

Redis の限られたメモリリソースの適切な割り当てを確保する

設定された最大しきい値に達すると、主要なリサイクル戦略を選択する必要があります。デフォルトでは、リサイクル戦略は削除を禁止します。

構成ファイル内の maxmemory-policy 属性値を変更します。

vim /etc/redis/6379.conf
--598--
maxmemory-policy noenviction
●volatile-lru :使用LRU算法从已设置过期时间的数据集合中淘汰数据
●volatile-ttl :从已设置过期时间的数据集合中挑选即将过期的数据淘汰
●volatile-random :从已设置过期时间的数据集合中随机挑选数据淘汰
●allkeys-lru :使用LRU算法从所有数据集合中淘汰数据
●allkeys-random :从数据集合中任意选择数据淘汰
●noenviction :禁止淘汰数据

Redis サービスの最適化

1. RDE の高可用性