67 日目 Redis 高可用性の永続性

開発 2023-06-24 19:39:10 訪問数: null

Redis の高可用性

高可用性とは

Web サーバーにおける高可用性とは、サーバーに正常にアクセスできる時間を指し、通常のサービスをどれだけ長く提供できるか (99.9%、99.99%、99.999% など) を測定します。

ただし、Redis の文脈での高可用性の意味はもっと広いと思われ、通常のサービス (マスター/スレーブ分離、迅速な災害復旧技術など) の提供の確保に加えて、高可用性の拡張も考慮する必要があります。データ容量と損失のないデータセキュリティなど。

Redis の高可用性テクノロジー

Redisにおいて高可用性を実現する技術としては、主に永続化、マスタースレーブレプリケーション、セントリー、クラスタークラスターがあり、それぞれの機能とどのような問題を解決できるかについて説明します。

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

  • マスター/スレーブ レプリケーション:マスター/スレーブ レプリケーションは高可用性 Redis の基礎であり、Sentinel とクラスターは高可用性を実現するためにマスター/スレーブ レプリケーションに基づいています。マスター/スレーブ レプリケーションは主に、データの複数マシンのバックアップ (および同期) を実現するだけでなく、読み取り操作の負荷分散と単純な障害回復も実現します。

    • 欠点: 障害回復は自動化できません。書き込み操作の負荷分散はできません。ストレージ容量は 1 台のマシンによって制限されます。

  • Sentinel: Sentinel は、マスター/スレーブ レプリケーションに基づいて、自動障害回復を実装します。(マスターがダウンしているため、新しいマスターとなるスレーブを見つけます。センチネル ノードがそれを監視します)

    • 欠点: 書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。

  • クラスター クラスター: Redis はクラスタリングを通じて、書き込み操作の負荷分散ができず、ストレージ容量が単一マシンによって制限されるという問題を解決し、比較的完全な高可用性ソリューションを実現します。(マスター 3 台、スレーブ 3 台のペアで 6 セット開始)

Redis の永続性

永続的な関数

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

災害時バックアップ: 通常、オフサイト バックアップを実行し、災害発生後にノードを切り替えます。たとえば、当初は上海で使用されていたデータベースが、現在は重慶のデータベースに切り替えられています。

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

  • RDB の永続性: 原則は、メモリ内の Reid のデータベース レコードを定期的にディスクに保存することです。(メモリ内のデータのスナップショットを定期的に生成し、ファイルとしてハードディスクに保存します)
  • AOF 永続性 (追加のみのファイル): 原理は、MySQL の binlog と同様に、Reid の操作ログを追加の方法でファイルに書き込むことです。(Mysqlのバイナリログに似ています) (書き込みおよび削除の操作コマンドはAOFファイルに追加で記録されます)

AOF 永続化のリアルタイム パフォーマンスが優れているため、つまり、プロセスが予期せず終了した場合に失われるデータが少ないため、現在 AOF が主流の永続化方法ですが、RDB 永続化も依然としてその地位を占めています。(RDB はサイズが小さく、復元が速いため、パフォーマンスへの影響が少なくなります。)

RDBの永続性

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

発動条件

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

手動トリガー

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

  • save コマンドは、RDB ファイルが作成されるまで Redis サーバー プロセスをブロックします。Redis サーバーのブロック中、サーバーはコマンド リクエストを処理できません。
  • bgsave コマンドは、RDB ファイルの作成を担当する子プロセスを作成し、親プロセス (つまり、Redis メイン プロセス) がリクエストの処理を続行します。
  • bgsave コマンドの実行中は fork 子プロセスのみがサーバーをブロックしますが、save コマンドの場合はプロセス全体がサーバーをブロックするため、save は基本的に放棄されており、オンラインでは save の使用は避けるべきです。環境

自動トリガー

RDB 永続化を自動的にトリガーする場合、Redis は永続化のために保存する代わりに bgsave を選択します。

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

redis配置文件
 
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
 
--254行-- #指定RDB文件名
dbfilename dump.rdb
--264行-- #指定RDB文件和AOF文件所在目录
dir /var/lib/redis/6379
--242行-- #是否开启RDB文件压缩
rdbcompression yes

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

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

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

bgsave実行処理

(1) Redis の親プロセスは、まず現在 save を実行しているのか、bgsave/bgrewriteaof の子プロセスであるかを判断し、実行中の場合は bgsave コマンドをそのままリターンします。

  • bgsave/bgrewriteaof の子プロセスは、主にパフォーマンス上の考慮事項に基づいて同時に実行できません。2 つの同時子プロセスが同時に大量のディスク書き込み操作を実行するため、重大なパフォーマンス上の問題が発生する可能性があります。

(2) 親プロセスが fork 操作を実行して子プロセスを作成すると、親プロセスはブロックされ、Redis はクライアントからのコマンドを実行できなくなります。

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

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

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

起動時の負荷

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

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

AOF 永続性 (第 2 レベルの書き込みをサポート)

  • RDB 永続化はプロセス データをファイルに書き込むことですが、AOF 永続化は Redis によって実行された各書き込みおよび削除コマンドを別のログ ファイルに記録することであり、クエリ操作は記録されません。

  • Redis が再起動したら、AOF ファイル内のコマンドを再度実行してデータを復元します。(回復用再生コマンド)

  • AOFはRDBと比較してリアルタイム性が優れているため、永続化ソリューションの主流となっています。

AOFを有効にする

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

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

実装プロセス

Redis の各書き込みコマンドを記録する必要があるため、AOF をトリガーする必要はありません。以下に AOF の実行プロセスを説明します。

AOF の実行プロセスには次のものが含まれます。

  • コマンド append (append) : Redis 書き込みコマンドをバッファー aof_ buf に追加します。

  • ファイル書き込み (write) とファイル同期 (sync) : さまざまな同期戦略に従って、aof_buf の内容をハードディスクに同期します。

  • ファイルの書き換え (リライト) : 圧縮の目的を達成するために、AOF ファイルを定期的に書き換えます。(期限切れデータ、無効なコマンド、複数のコマンドを圧縮または削除)

命令追加(append)

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

  • コマンド append の形式は、Redis コマンドリクエストのプロトコル形式であり、プレーンテキスト形式であり、互換性が高く、可読性が高く、処理が容易で、操作が簡単で、二次的なオーバーヘッドが回避されるという利点があります。

  • AOF ファイルでは、Redis によって追加されるデータベースの指定に使用される select コマンド (select 0 からデータベース 0 を選択するなど) を除いて、その他はすべてクライアントによって送信される書き込みコマンドです。

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

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

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

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

  • appendfsync always: コマンドが aof_buf に書き込まれた後、システム fsync 操作がすぐに呼び出され、AOF ファイルと同期されます。セキュリティは高いが、パフォーマンスは低い。

  • appendfsync no: バッファーがいっぱいになるか、指定された制限時間 (デフォルトでは 30 秒) を超えると、バッファー内のデータがハードディスクに書き込まれます。パフォーマンスは高いですが、セキュリティは低いです。

  • appendfsync eachsec: 1 秒に 1 回同期します。これはパフォーマンスとデータ セキュリティのバランスをとるため、Redis のデフォルト構成です。

 vim /etc/redis/6379.conf
 ----729行----
  729 # appendfsync always
  730 appendfsync everysec
  731 # appendfsync no
 ​
 ------------------------以下是注释----------------------------------------------------
 ● 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的默认配置，也是我们推荐的配置。
 （同时保证了数据安全和性能的需求）

作者：LINK11222
链接：https://juejin.cn/post/7162050595145613326
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

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

  • 時間が経つにつれて、Redis サーバーはますます多くの書き込みコマンドを実行し、AOF ファイルはますます大きくなります。AOF ファイルが大きすぎると、サーバーの通常の動作に影響を与えるだけでなく、データの回復に時間がかかりすぎることになります。
  • ファイルの書き換えとは、AOF ファイルのサイズを減らすために AOF ファイルを定期的に書き換えることを指します。AOF の再書き込みは、Redis プロセス内のデータを書き込みコマンドに変換し、新しい AOF ファイルに同期することであり、古い AOF ファイルに対して読み取りまたは書き込み操作は実行されないことに注意してください。
  • ファイルの書き換えに関するもう 1 つの注意点: AOF 永続性の場合、ファイルの書き換えが強く推奨されますが、必須ではありません。ファイルの書き換えがなくても、データは永続化され、Redis のインポート時に開始できます。したがって、実際には、ファイルの自動書き換えがオフになり、スケジュールされたタスクが毎日特定の時間に実行されます。

知らせ：

書き換えはパフォーマンスを消費し、ビジネスに影響を与えるため、業務のピーク時間帯には書き換えを実行できません。したがって、通常は自動書き換えはオフになっており、スケジュールされたタスクによって毎日特定の時刻に書き換え機能が実行されます。

ファイルの書き換えによって AOF ファイルが圧縮される理由は次のとおりです。

  • 期限切れのデータはファイルに書き込まれなくなります。
  • 無効なコマンドがファイルに書き込まれなくなりました。たとえば、一部のデータが繰り返し設定される (set mykey v1、set mykey v2)、一部のデータが削除される (set myset vl、del myset) などです。
  • 複数のコマンドを 1 つに結合できます。たとえば、sadd myset v1、sadd myset v2、sadd myset v3 は、sadd myset v1 v2 v3 に結合できます。(悲しいことにコレクションを追加)

書き換え後、aof ファイルはキーの最終状態を保存し、以前の冗長性をクリアしてファイルを縮小します。

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

ファイル書き換えのトリガーは、手動トリガーと自動トリガーに分けられます。

ファイル書き換えのトリガーは、手動トリガーと自動トリガーに分けられます。

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

  • 自動トリガー: auto-aof-rewrite-min-size オプションと auto-aof-rewrite-percentage オプションを設定すると、BGREWRITEAOF が自動的に実行されます。

    • auto-aof-rewrite-min-size と auto-aof-rewrite-percentage の 2 つのオプションが同時に満たされた場合にのみ、AOF 再書き込み、つまり bgrewriteaof 操作が自動的にトリガーされます。

 vim /etc/redis/6379.conf
 ----771行----
  771 auto-aof-rewrite-percentage 100
  772 auto-aof-rewrite-min-size 64mb
 ​
 -----------------------以下是注释--------------------------------
 ● auto-aof-rewrite-percentage 100  
 #文件的大小超过基准百分之多少后触发bgrewriteaof。默认这个值设置为100，意味着当前aof是基准大小的两倍的时候触发bgrewriteaof。把它设置为0可以禁用自动触发的功能。
 #即当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作。
 #注意：例如上次文件达到100M进行重写，那么这次需要达到200M时才进行重写。文件需要越来越大，所以一般不使用自动重写。如果使用自动重写，需要定期手动重写干预一次，让文件要求恢复到100M。
 ​
 ● auto-aof-rewrite-min-size 64mb      #当文件大于64M时才会进行重写
 #当前aof文件大于多少字节后才触发。
 #当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF

ファイルの書き換え処理に関して、特に注意が必要な点が 2 つあります。

  1. 書き換えは、親プロセスが子プロセスをフォークすることによって実行されます。
  2. Redis が書き換え時に実行する書き込みコマンドは、新しい AOF ファイルに追加する必要があるため、Redis では aof_rewrite_buf キャッシュが導入されています。

ファイル書き換えのプロセスは次のとおりです。

(1) Redis の親プロセスは、まず bgsave/bgrewriteaof を実行している子プロセスが存在するかどうかを判断し、存在する場合は bgrewriteaof コマンドをそのままリターンし、bgsave コマンドが存在する場合は、bgsave の実行が完了するのを待って実行します。(通常の状況では、AOF を使用する場合、AOF は記録に使用され、RDB は使用されません。マスター/スレーブ レプリケーション中に 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 の書き換えを完了します。(置換はアトミックです)

起動時の負荷

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

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

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

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

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

アドバンテージ：

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

(サイズが小さく、回復が速く、パフォーマンスへの影響が少ない。)

欠点:

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

(リアルタイム パフォーマンスが低く、互換性が低く、子プロセスをフォークするときに親プロセスがブロックされます。)

AOF 永続化の長所と短所

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

Redis のパフォーマンス管理

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

 方法一：进入redis数据库查看
 redis-cli
 127.0.0.1:6379> info memory
 ​
 方法二：命令行查看
 redis-cli info memory

記憶の断片化

メモリの断片化率の計算方法:

メモリの断片化率 = Redis がオペレーティング システムから要求したメモリ / Redis 内のデータが占有するメモリ

mem_fragmentation_ratio = used_memory_rss / used_memory

  • mem_fragmentation_ratio: メモリの断片化率。

  • 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 は不要なメモリをオペレーティング システムに返し、断片化率が低下します。

  • Redis バージョン 4.0 以降では、再起動せずにオンラインでメモリをデフラグし、未使用のメモリをオペレーティング システムに戻すことができます。

 config set activedefrag yes    #自动碎片清理
 memory purge                   #手动碎片清理

メモリ使用量

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

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

  • キャッシュされたデータのサイズに応じて Redis インスタンスのインストールを選択します
  • 可能な限りハッシュ データ構造ストレージを使用する
  • キーの有効期限を設定する

リサイクルキー

メモリ クリーニング戦略により、Redis の限られたメモリ リソースが適切に割り当てられます。

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

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

 vim /etc/redis/6379.conf
 ---598行----
 maxmemory-policy noenviction   #修改max-memory-policy属性值
 ​
 ##回收策略有以下几种：##
 ●volatile-lru
 #使用LRU算法从已设置过期时间的数据集合中淘汰数据
 （移除最近最少使用的key，针对设置了TTL的key）
 ​
 ●volatile-ttl
 #从已设置过期时间的数据集合中挑选即将过期的数据淘汰
 （移除最近过期的key）
 ​
 ●volatile-random
 #从已设置过期时间的数据集合中随机挑选数据淘汰
 （在设置了TTL的key里随机移除）
 ​
 ●allkeys-lru
 #使用LRU算法 从所有数据集合中淘汰数据
 （移除最少使用的key，针对所有的key）
 ​
 ●allkeys-random
 #从数据集合中任意选择数据淘汰（随机移除key）
 ​
 ●noenviction
 #禁止淘汰数据（不删除直到写满时报错）

作者：LINK11222
链接：https://juejin.cn/post/7162050595145613326
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

Redis の最適化とは何ですか

クライアント接続タイムアウト、クライアント接続の最大数、自動ゴミ掃除、最大メモリしきい値、キー回復戦略を設定します。

Redisクライアント接続のタイムアウト時間を設定する

 vim /etc/redis/6379.conf
 -----114行------
 114 timeout 0     
 #单位为秒（s），取值范围为0~100000。默认值为0，表示无限制，即Redis不会主动断开连接，即使这个客户端已经空闲了很长时间。
 #例如可设置为600，则客户端空闲10分钟后，Redis会主动断开连接。
 ​
 #注意：在实际运行中，为了提高性能，Redis不一定会精确地按照timeout的值规定的时间来断开符合条件的空闲连接，例如设置timeout为10s，但空闲连接可能在12s后，服务器中新增很多连接时才会被断开。

Redis クライアントの最大接続数を設定する

Redis クライアントの最大接続数はデフォルトで 10000 です。

 vim /etc/redis/6379.conf
 -----540行------
 540 # maxclients 10000     #若不设置，默认是10000

現在の Redis 接続数を表示します。

 [root@yuji ~]# redis-cli
 127.0.0.1:6379> info clients       #查看redis当前连接数
 # Clients
 connected_clients:1                 #redis当前连接数的为1   
 client_recent_max_input_buffer:2
 client_recent_max_output_buffer:0
 blocked_clients:0

Redis によって許可される接続の最大数を表示します。

 127.0.0.1:6379> config get maxclients
 1) "maxclients"     
 2) "10000"              #redis允许的最大连接数默认为10000

Redis の自動デフラグを設定する

 config set activedefrag yes    #自动碎片清理
 memory purge                   #手动碎片清理

Redis の最大メモリしきい値を設定する

メモリしきい値が設定されていない場合、サーバーのメモリがいっぱいになるまで制限はなく、いっぱいになるとスワップ パーティションが使用されます。

メモリしきい値を設定すると、スワップ パーティションは使用されなくなります。キー回復ポリシーが設定されている場合、メモリ使用量が設定された最大しきい値に達すると、システムはキー回復を実行します。

vim /etc/redis/6379.conf
 -----567行------
 567 # maxmemory <bytes>
 568 maxmemory 1gb           #例如设置最大内存阈值为1gb

キーのリサイクルポリシーを設定する

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

キー回復ポリシーを設定した後、Redis メモリ使用量が設定された最大しきい値に達すると、システムはキー回復を実行し、メモリの一部を解放します。

 vim /etc/redis/6379.conf
 ---598行----
 maxmemory-policy noenviction   #需要修改max-memory-policy属性值
 ​
 ##回收策略有以下几种：##
 ●volatile-lru
 #使用LRU算法从已设置过期时间的数据集合中淘汰数据（移除最近最少使用的key，针对设置了TTL的key）
 ​
 ●volatile-ttl
 #从已设置过期时间的数据集合中挑选即将过期的数据淘汰（移除最近过期的key）
 ​
 ●volatile-random
 #从已设置过期时间的数据集合中随机挑选数据淘汰（在设置了TTL的key里随机移除）
 ​
 ●allkeys-lru
 #使用LRU算法 从所有数据集合中淘汰数据（移除最少使用的key，针对所有的key）
 ​
 ●allkeys-random
 #从数据集合中任意选择数据淘汰（随机移除key）
 ​
 ●noenviction
 #禁止淘汰数据（不删除直到写满时报错）


作者：LINK11222
链接：https://juejin.cn/post/7162050595145613326
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

おすすめ

転載: blog.csdn.net/weixin_57560240/article/details/130914074
おすすめ
ランキング
Oracleのクエリ重複フィールド
An error occurred when ssm used count to query data
【Leyes de la Naturaleza】La sabiduría de las multitudes
JavaWebの研究では、（13）を締結 - セッションの使用は、重複送信フォームを防ぎます
Firebase増加サインアップクォータ
[MyBatisフレームワーク]mybatis入門
ハートレスの世界
Djangoのインストールと使用について
[转] UiPath展開アーキテクチャ
mybatis-plusは楽観的なロック変更を使用します
アーカイブ
もっと
2024-05-14(9)
2024-05-13(8)
2024-05-12(27)
2024-05-11(31)
2024-05-10(33)
2024-05-09(30)
2024-05-08(18)
2024-05-07(34)
2024-05-06(6)
2024-05-05(0)

コードワールド

© 2018 codetd.com