NoSQL の Redis 高可用性

1. Redis の高可用性
2. Redis のパフォーマンス管理

1. Redis の高可用性

1.1 Redis の高可用性

Web サーバーにおける高可用性とは、サーバーに正常にアクセスできる時間を指し、通常のサービスをどれだけ長く提供できるか (99.9%、99.99%、99.999% など) を測定します。
ただし、Redis の文脈での高可用性の意味はもっと広いと思われ、通常のサービス（マスター/スレーブ分離や迅速な災害復旧技術など）の提供を確保することに加えて、高可用性の拡張も考慮する必要があります。損失のないデータ容量とデータセキュリティ。
Redis では、高可用性を実現するためのテクノロジーには、主に永続化、マスター/スレーブレプリケーション、セントリー、およびクラスタークラスター 1 が含まれます。永続性
: 永続化は最も単純な高可用性方法 (高可用性方法として分類されていない場合もあります) であり、主にデータのバックアップです。つまり、プロセスの終了によってデータが失われないように、データをハードディスクに保存します。
2. マスター/スレーブレプリケーション: マスター/スレーブレプリケーションは高可用性 Redis の基礎であり、Sentinel とクラスターは高可用性を実現するためにマスター/スレーブレプリケーションに基づいています。マスター/スレーブレプリケーションでは、主にデータのマルチマシンバックアップ、読み取り操作の負荷分散、および単純な障害回復が実装されます。欠点: 障害回復は自動化できません。書き込み操作の負荷分散はできません。ストレージ容量は 1 台のマシンによって制限されます。
3. Sentinel: Sentinel は、マスター/スレーブレプリケーションに基づいて、自動障害回復を実現します。欠点: 書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。
4. クラスタークラスター: Redis はクラスターを通じて、書き込み操作の負荷分散ができず、ストレージ容量が単一マシンによって制限されるという問題を解決し、比較的完全な高可用性ソリューションを実現します。

1.2 Redis の永続性

永続化機能: Redis はインメモリデータベースであり、データはメモリ上に保存されますが、サーバーの電源障害などの理由で Redis プロセスが異常終了した後、データが永久に失われることを避けるために、定期的にデータを保存する必要があります。 Redis 内のデータを何らかの形式 (データまたはコマンド) でメモリからハードディスクに保存し、次回 Redis を再起動するときに永続ファイルを使用してデータを回復します。さらに、永続ファイルは、災害時バックアップの目的でリモートの場所にコピーできます。
Redis は永続化のために 2 つの方法を提供します
。 1. DB 永続性: 原理は、メモリ内の Reid のデータベースレコードを定期的にディスクに保存することです。
2. AOF 永続性 (追加のみのファイル): 原理は、MySQL の binlog と同様に、Reid の操作ログを追加の方法でファイルに書き込むことです。
由于AOF持久化的实时性更好，即当进程意外退出时丢失的数据更少，因此AOF是目前主流的持久化方式，不过RDB持久化仍然有其用武之地。

1.2.1 RDBの永続化

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

(1) save コマンドと bgsave コマンドの両方を手動でトリガーして、
RDB ファイルを生成できます。
save コマンドは、RDB ファイルが作成されるまで Redis サーバープロセスをブロックします。Redis サーバーのブロック中、サーバーはコマンドリクエストを処理できません。
bgsave コマンドは、RDB ファイルの作成を担当する子プロセスを作成し、親プロセス (つまり、Redis メインプロセス) がリクエストの処理を続行します。

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

(2) 自動トリガー
RDB 永続化が自動的にトリガーされる場合、Redis は永続化のために保存ではなく bgsave を選択します。

save mn の自動トリガーの最も一般的なケース
は、設定ファイルに save mn を渡して、m 秒以内に n 回の変更が発生したときに bgsave がトリガーされてスナップショットが作成されるように指定することです。

vim /usr/local/redis/conf/redis.conf
--433行--RDB默认保存策略
# save 3600 1 300 100 60 10000
#表示以下三个save条件满足任意一个时，都会引起bgsave的调用
save 3600 1 ：当时间到3600秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10 ：当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 ：当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave

--454行--是否开启RDB文件压缩
rdbcompression yes
--481行--指定RDB文件名
dbfilename dump.rdb
--504行--指定RDB文件和AOF文件所在目录
dir /usr/local/redis/data

その他の自動トリガーメカニズム
save mn に加えて、bgsave をトリガーする状況は他にもあります。
(1) マスター/スレーブレプリケーションシナリオでは、スレーブノードがフルコピー操作を実行すると、マスターノードは bgsave コマンドを実行し、rdb ファイルをスレーブノード。
(2) shutdownコマンドを実行(サービスを停止)すると、自動的にRDB永続化が実行されます。
2. 実行処理
(1) まず、Redis の親プロセスが現在 save を実行しているか、bgsave/bgrewriteaof の子プロセスであるかを判断し、実行中の場合は bgsave コマンドをそのままリターンします。bgsave/bgrewriteaof の子プロセスは、主にパフォーマンス上の考慮事項に基づいて同時に実行できません。2 つの同時子プロセスが同時に大量のディスク書き込み操作を実行するため、重大なパフォーマンス上の問題が発生する可能性があります。
(2) 親プロセスがフォーク操作を実行して子プロセスを作成します。このプロセス中、親プロセスはブロックされ、Redis はクライアントからのコマンドを実行できません。 (3) 親プロセスがフォークした後、bgsave コマンドは「
バックグラウンド保存を開始しました」というメッセージが表示され、ブロックされなくなります。親プロセスは他のコマンドに応答できます。
(4) 子プロセスは、RDB ファイルを作成し、親プロセスのメモリスナップショットに基づいて一時スナップショットファイルを生成し、元のファイルをアトミックに置き換えます。完了後
(5) 子プロセスは親プロセスに完了を示すシグナルを送信し、親プロセスは統計情報を更新します。
3.
起動時に RDB ファイルをロードします。 RDB ファイルのロードは、サーバーの起動時に自動的に実行され、何も行われません。特別なコマンド。ただし、AOF の優先順位が高いため、AOF が有効な場合、Redis は AOF ファイルのロードを優先してデータを復元します。AOF が無効な場合にのみ、Redis サーバーの起動時に RDB ファイルが検出され、自動的にロードされます。RDB ファイルのロード中、ロードが完了するまでサーバーはブロックされます。
Redis は RDB ファイルをロードするときに RDB ファイルを検証しますが、ファイルが破損している場合はログにエラーが出力され、Redis は起動できません。

1.2.2 AOF の永続性

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

Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置：
vim /usr/local/redis/conf/redis.conf
--1380行--修改，开启AOF
appendonly yes
--1407行--指定AOF文件名称
appendfilename "appendonly.aof"
--1505行--是否忽略最后一条可能存在问题的指令
aof-load-truncated yes


systemctl restart redis-server.service

2. 実行プロセス
Redis の各書き込みコマンドを記録する必要があるため、AOF は次のような AOF の実行プロセスをトリガーする必要はありません:
コマンド追加 (append): Redis 書き込みコマンドをバッファー aof_buf に追加、
ファイル書き込み (write) およびファイル同期 (sync) : さまざまな同期戦略に従って、aof_buf のコンテンツをハードディスクに同期します;
● ファイルの書き換え (リライト): 圧縮の目的を達成するために、AOF ファイルを定期的に書き換えます。

(1) コマンドの追加 (アペンド)
Redis は、書き込みコマンドをファイルに直接書き込むのではなく、最初にバッファーに追加します。これは主に、書き込みコマンドがあるたびにハードディスクに直接書き込むことを避けるためであり、ハードディスク IO がRedis負荷のボトルネック。
コマンド append の形式は、Redis コマンドリクエストのプロトコル形式であり、プレーンテキスト形式であり、互換性が高く、可読性が高く、処理が容易で、操作が簡単で、二次的なオーバーヘッドが回避されるという利点があります。AOF ファイルでは、Redis によって追加されるデータベースの指定に使用される select コマンド (select 0 からデータベース 0 を選択するなど) を除いて、その他はすべてクライアントによって送信される書き込みコマンドです。

(2) ファイル書き込み (write) とファイル同期 (sync)
Redis では、AOF バッファ領域に対して、オペレーティングシステムの write 関数と fsync 関数を使用したさまざまなファイル同期戦略を提供しています。
ファイルの書き込み効率を向上させるため、最新のオペレーティングシステムでは、ユーザーがファイルにデータを書き込むために書き込み関数を呼び出すと、通常、オペレーティングシステムはデータをメモリバッファに一時的に保存します。バッファがいっぱいになるか、指定された制限時間を超えると、実際にバッファが保存され、その領域のデータがハードディスクに書き込まれます。この種の操作は効率を向上させますが、セキュリティ上の問題も引き起こします。コンピュータがシャットダウンすると、メモリバッファ内のデータが失われるため、システムには、オペレーティングシステムを強制的に実行できる fsync や fdatasync などの同期機能も用意されています。データのセキュリティを確保するために、データはハードディスクに書き込まれます。

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

vim /usr/local/redis/conf/redis.conf
--1439--
●appendfsync always： 命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。

●appendfsync no： 命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。

●appendfsync everysec： 命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。

(3) ファイルの書き換え (リライト)
時間の経過とともに、Redis サーバーは書き込みコマンドを実行する回数が増えるため、AOF ファイルはますます大きくなり、大きすぎる AOF ファイルはサーバーの通常の動作に影響を与えるだけでなく、原因データの回復に時間がかかりすぎます。

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

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

ファイルの書き換えによって AOF ファイルが圧縮される理由は次のとおりです。
● 古いデータがファイルに書き込まれなくなる
● 無効なコマンドがファイルに書き込まれなくなる: たとえば、一部のデータが繰り返し設定されます (set mykey v1、set mykey v2)。一部のデータが削除されます (set myset v1、del myset) など。
●複数のコマンドを 1 つに結合できます。sadd myset v1、sadd myset v2、sadd myset v3 などを、sadd myset v1 v2 v3 に結合できます。

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

ファイル書き換えのトリガーは、手動トリガーと自動トリガーに分けられます。
●手動トリガー: bgrewriteaof コマンドを直接呼び出します。このコマンドの実行は、bgsave に似ています。両方の fork サブプロセスが特定の作業を実行し、どちらもブロックされるのは実行中にのみです。フォーク。
●自動トリガー：auto-aof-rewrite-min-size オプションおよび auto-aof-rewrite-percentage オプションを設定することにより、BGREWRITEAOF を自動的に実行します。auto-aof-rewrite-min-size と auto-aof-rewrite-percentage の 2 つのオプションが同時に満たされた場合にのみ、AOF 書き換え、つまり bgrewriteaof 操作が自動的にトリガーされます。

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

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

ファイル書き換えの処理は以下のとおりです:
(1) Redis の親プロセスは、まず bgsave/bgrewriteaof を実行している子プロセスが存在するかどうかを判断し、存在する場合は bgrewriteaof コマンドを直接返し、bgsave コマンドが存在する場合は bgsave の実行を待ちます。実行する前に実行を完了する必要があります。
(2) 親プロセスが fork 操作を実行して子プロセスを作成し、このプロセス中に親プロセスがブロックされます。
(3.1) 親プロセスがフォークした後、bgrewriteaof コマンドは「バックグラウンド追加のみのファイル書き換えが開始されました」というメッセージを返し、親プロセスをブロックしなくなり、他のコマンドに応答できるようになります。Redis のすべての書き込みコマンドは引き続き AOF バッファーに書き込まれ、appendfsync 戦略に従ってハードディスクに同期され、元の AOF メカニズムの正確性が保証されます。
(3.2) フォーク操作ではコピーオンライト技術が使用されるため、子プロセスはフォーク操作中にのみメモリデータを共有できます。親プロセスはまだコマンドに応答しているため、Redis は AOF 書き換えバッファー (aof_rewrite_buf) を使用してデータのこの部分を保存し、新しい AOF ファイルの生成中にデータのこの部分が失われるのを防ぎます。つまり、bgrewriteaof の実行中に、Redis 書き込みコマンドが 2 つのバッファー aof_buf と aof_rewrite_buf に同時に追加されます。
(4) 子プロセスは、メモリスナップショットに従って、コマンドマージルールに従って新しい AOF ファイルに書き込みます。
(5.1) 子プロセスが新しい AOF ファイルを書き込んだ後、親プロセスにシグナルを送信し、親プロセスは統計情報を更新します。統計情報は情報永続化を通じて表示できます。
(5.2) 親プロセスは、AOF 書き換えバッファ内のデータを新しい AOF ファイルに書き込み、新しい AOF ファイルに保存されたデータベースの状態がサーバーの現在の状態と一致することを保証します。
(5.3) 古いファイルを新しい AOF ファイルに置き換えて、AOF の書き換えを完了します。

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

1.3 RDBとAOFのメリットとデメリット

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

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

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

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

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

192.168.9.236:7001> info memory

2.2 メモリの断片化率

mem_fragmentation_ratio：内存碎片率。mem_fragmentation_ratio = used_memory_rss / used_memory
used_memory_rss：是Redis向操作系统申请的内存。
used_memory：是Redis中的数据占用的内存。
used_memory_peak：redis内存使用的峰值。

#内存碎片如何产生的？
Redis内部有自己的内存管理器，为了提高内存使用的效率，来对内存的申请和释放进行管理。
Redis中的值删除的时候，并没有把内存直接释放，交还给操作系统，而是交给了Redis内部有内存管理器。
Redis中申请内存的时候，也是先看自己的内存管理器中是否有足够的内存可用。
Redis的这种机制，提高了内存的使用率，但是会使Redis中有部分自己没在用，却不释放的内存，导致了内存碎片的发生。

#跟踪内存碎片率对理解Redis实例的资源性能是非常重要的：
●内存碎片率在1到1.5之间是正常的，这个值表示内存碎片率比较低，也说明 Redis 没有发生内存交换。
●内存碎片率超过1.5，说明Redis消耗了实际需要物理内存的150%，其中50%是内存碎片率。
●内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换。需要增加可用物理内存或减少 Redis内存占用。

#解决碎片率大的问题：
如果你的Redis版本是4.0以下的，需要在 redis-cli 工具上输入 shutdown save 命令，让 Redis 数据库执行保存操作并关闭 Redis 服务，再重启服务器。Redis服务器重启后，Redis会将没用的内存归还给操作系统，碎片率会降下来。

Redis4.0版本开始，可以在不重启的情况下，线上整理内存碎片。
config set activedefrag yes     #自动碎片清理，内存就会自动清理了。
memory purge					#手动碎片清理

2.3 メモリ使用量

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

#避免内存交换发生的方法：
●针对缓存数据大小选择安装 Redis 实例
●尽可能的使用Hash数据结构存储
●设置key的过期时间

2.4 キーをリサイクルする

メモリデータの削除戦略により、Redis の限られたメモリリソースが適切に割り当てられます。
設定された最大しきい値に達すると、主要なリサイクル戦略を選択する必要があります。デフォルトでは、リサイクル戦略は削除を禁止します。

配置文件中修改 maxmemory-policy 属性值：
vim /usr/local/redis/conf/redis.conf
--1149--
maxmemory-policy noenviction
●volatile-lru：使用LRU算法从已设置过期时间的数据集合中淘汰数据(移除最近最少使用的key，针对设置了TTL的key)
●volatile-ttl：从已设置过期时间的数据集合中挑选即将过期的数据淘汰（移除最近过期的key）
●volatile-random：从已设置过期时间的数据集合中随机挑选数据淘汰（在设置了TTL的key里随机移除）
●allkeys-lru：使用LRU算法从所有数据集合中淘汰数据（移除最少使用的key，针对所有的key）
●allkeys-random：从数据集合中任意选择数据淘汰（随机移除key）
●noenviction：禁止淘汰数据（不删除直到写满时报错）


//其它限制相关
●maxclients
设置redis同时可以与多少个客户端进行连接。
默认情况下为10000个客户端。
如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。

●maxmemory
建议必须设置，否则，将内存占满，造成服务器宕机。
设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。
如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。
但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明redis集群有主从），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素。

●maxmemory-samples
设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个。
一般设置3到7的数字，数值越小样本越不准确，但性能消耗越小。

NoSQL の Redis 高可用性

NoSQL の Redis 高可用性

1. Redis の高可用性

1.1 Redis の高可用性

1.2 Redis の永続性

1.2.1 RDBの永続化

1.2.2 AOF の永続性

1.3 RDBとAOFのメリットとデメリット

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

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

2.2 メモリの断片化率

2.3 メモリ使用量

2.4 キーをリサイクルする

おすすめ