一、Redis持続化RDBとAOF

1.1 RDB詳細

RDBはRedisのデフォルトの永続化スキームである.指定した間隔で、指定した回数の書き込みを行うと、メモリのデータがディスクに書き込まれます.すなわち、指定ディレクトリの下にdumpを生成する.rdbファイル.Redis再起動はdumpをロードする.rdbファイルはデータを復元します.
プロファイルからRDBについて
開くconfファイル、SNAPSHOTTING対応コンテンツを見つけます

RDBコア規則構成(重点)

save  
# save ""
save 900 1
save 300 10
save 60 10000

解説:saveは、条件を満たすとメモリのデータをハードディスクに同期します。デフォルトでは900秒以内に1つの変更があり、300秒以内に10つの変更があり、60秒以内に10000の変更がある場合は、メモリ内のデータスナップショットをディスクに書き込みます。RDBスキームを使用したくない場合は、save""のコメントを開いて、次の3つのコメントを開くことができます。

ローカルデータベースファイル名を指定し、一般的にデフォルトのdumpを採用する.rdb

dbfilename dump.rdb

ローカル・データベースの格納ディレクトリを指定します.一般的にはデフォルトの構成

も使用します.

dir ./

デフォルトオープンデータ圧縮

rdbcompression yes

説明:ローカル・データベースに格納するときにデータを圧縮するかどうかを設定します。デフォルトはyesです。RedisはLZF圧縮方式を採用しているが,CPUの時間が少しかかっている.このオプションをオフにすると、データベース・ファイルが大きくなります。開くことを推奨します。

RDBスナップショットのトリガー

所定の時間間隔で、所定回数の書き込み操作

が実行する.

save(スナップショットの保存のみ、その他の待機)またはbgsave(非同期)コマンド

を実行する.

flushallコマンドを実行し、データベースのすべてのデータを空にするのは意味がありません.

shutdownコマンドを実行し、サーバが正常に閉じられ、データが失われないことを保証します.意味もありません.

RDBファイルによるデータ復旧
これをrdbファイルをredisのインストールディレクトリのbinディレクトリにコピーし、redisサービスを再起動すればよい.実際の開発では、物理機のハードディスクの破損を考慮して、バックアップdumpを選択するのが一般的である.rdb .以下の操作のプレゼンテーションから理解できます.
RDBの長所と短所
メリット:

は、大規模なデータ・リカバリに適しています.

ビジネスがデータの整合性と一貫性に対する要求が高くない場合、RDBは良い選択です.

欠点:

データの整合性と一貫性は高くありません.これは、RDBが最後のバックアップでダウンタイムする可能性があるためです.

バックアップ時にメモリを消費します.Redisはバックアップ時に独立してサブプロセスを作成し、一時ファイルにデータを書き込み(メモリのデータは元の2倍ですよ)、最後に一時ファイルを前のバックアップファイルに置き換えます.だからRedisの持続化とデータの回復は夜が更けて人が静かな時に実行するのが合理的だ.

1.2 AOF詳細

AOF:Redisはデフォルトではオンになっていません.RDBの不足(データの不一致)を補うために、ログ形式で各書き込み操作を記録し、ファイルに追加します.Redisが再起動すると、ログ・ファイルの内容に応じて、データのリカバリを完了するために、書き込みコマンドが前後に1回実行されます.
構成ファイルからAOFについてredis.confファイルを開けて、APPEND ONLY MODEの対応する内容を探し当てます

redisはデフォルトで閉じ、開くには手動でnoをyes

に変更する必要があります.

appendonly yes

ローカルデータベースファイル名を指定します.デフォルトはappendonlyです.aof

appendfilename "appendonly.aof"

更新ログ条件

を指定する.

# appendfsync always
appendfsync everysec
# appendfsync no

解説: Always:同期永続化で、データの変更が発生するたびにディスクに書き込まれます。パフォーマンスが劣るデータ整合性が良好(遅い、安全) everysec:出荷時のデフォルト推奨、毎秒非同期記録(デフォルト) No：非同期

書き換えトリガ機構

を構成する.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

解説：AOFファイルサイズが前回rewrite後のサイズの倍であり、ファイルが64 Mより大きい場合にトリガーされます。普通はすべて3 Gに設定して、64 Mは小さすぎます。

1.2.2 AOFスナップショットのトリガ
プロファイルによってトリガされると、実行ごとにトリガされ、毎秒トリガされ、同期されなくてもよい.
AOFファイルによるデータ復旧
通常はappendonly.aofファイルをredisのインストールディレクトリのbinディレクトリにコピーし、redisサービスを再起動すればよい.しかし、実際の開発では、いくつかの理由でappendonlyが発生する可能性があります.aofファイルのフォーマットが異常で、データの復元に失敗し、redis-check-aof--fix appendonlyをコマンドすることができる.aofは修復を行う.以下の操作プレゼンテーションから体験します.
AOFの書き換えメカニズム
前述したように、AOFの動作原理は、書き込み操作をファイルに追加することであり、ファイルの冗長性が増すことである.だから賢いRedisは書き換えメカニズムを追加しました.AOFファイルのサイズが設定した閾値を超えると、RedisはAOFファイルの内容を圧縮する.
書き換えの原理:Redisはforkから新しいプロセスを出し、メモリのデータを読み出し、一時ファイルに書き換え、古いファイルを読み込まず、最後に古いaofファイルを置き換えます.
トリガメカニズム:AOFファイルサイズが前回rewrite後のサイズの倍であり、ファイルが64 Mより大きい場合にトリガされます.ここで「倍」と「64 M」はプロファイルで変更できます.
AOFのメリットとデメリット

の利点:データの整合性と一貫性がより高い

欠点:AOF記録の内容が多いため、ファイルはますます大きくなり、データ復旧もますます遅くなります.

1.3まとめ

RedisはデフォルトでRDB永続化方式をオンにし、指定された時間間隔で指定された回数の書き込み操作を実行すると、メモリ内のデータがディスクに書き込まれる.

RDB永続化は、大規模なデータ・リカバリに適していますが、データの一貫性と完全性が低下しています.

Redisは、AOF永続化方式を手動でオンにする必要があります.デフォルトでは、書き込み操作ログは1秒あたりAOFファイルに追加されます.

AOFのデータ整合性はRDBよりも高いが、記録内容が多くなり、データ復旧の効率に影響を与える.

RedisはAOFファイルの大きな問題に対して、書き換えのダイエットメカニズムを提供しています.

Redisのみでキャッシュする場合は、永続化をオフにできます.

Redisの永続化を使用する場合.RDBもAOFもオンにすることをお勧めします.実はRDBはデータのバックアップに適していて、後手を残しています.AOFに問題が発生しました.RDBもあります.

二、Redis期限切れ削除ポリシー

Redisには3つの異なる削除ポリシーがあります.

:キーの有効期限を設定すると、タイムプロセッサによってキーの削除操作が自動的に実行されるコールバックイベントが作成されます.

:キーが期限切れになると期限切れになります.dict辞書からkeyを押すたびに、このkeyが期限切れであるかどうかを確認し、期限切れであれば削除しnilを返し、期限切れでなければキー値を返します.

:expires辞書を一定時間おきにチェックし、中の期限切れキーを削除します.

2つ目はパッシブ削除であり,1つ目と3つ目はアクティブ削除であり,1つ目はリアルタイム性が高いことがわかる.この3つの削除ポリシーを具体的に分析します.

2.1今すぐ削除

は、期限切れキー値が期限切れ後すぐに削除されることを保証するため、メモリ内のデータの最大鮮度を保証します.メモリが使用されるメモリも解放されます.しかし、すぐに削除するのはcpuにとって最も友好的ではありません.削除操作にはcpuの時間がかかるため、ちょうどcpuが忙しいとき、例えば交差やソートなどの計算をしているときに、cpuに余分な圧力がかかります.また、現在のredisイベントプロセッサの時間イベントの処理方式である無秩序チェーンテーブルは、keyを検索する時間の複雑さがO(n)であるため、大量の時間イベントを処理するのに適していない.

2.2不活性削除

とは、あるキー値が期限切れになると、そのキー値がすぐに削除されるのではなく、次回使用されるまで期限切れがチェックされ、そのときに削除されることを意味します.したがって、不活性な削除の欠点は明らかです.メモリの浪費です.dict辞書とexpires辞書は、このキー値の情報を保存します.たとえば、logログなどの時間単位で更新されたデータについては、期限が切れた後も長い間アクセスできない可能性があります.これにより、この間、こんなに多くのメモリを無駄にしてlogを保存することになります.これは、メモリサイズに非常に依存するredisにとって致命的です.

2.3タイミング削除

以上の解析から,直ちに削除すると短時間で大量のcpuが消費され,不活性削除は一定時間メモリを浪費するため,タイミング削除は折衷的な方法である. は、一定時間ごとに削除操作を実行し、削除操作の実行時間と頻度を制限することによって、削除操作がcpuに与える影響を低減する.一方、タイミング削除は、不活性削除によるメモリの浪費を効果的に低減する.

2.4 redisが使用するポリシー

redisで使用される期限切れキー値削除ポリシーは、不活性削除と定期削除の両方を組み合わせて使用します.
参照先:https://www.cnblogs.com/itdragon/p/7906481.html https://blog.csdn.net/jiangchunhui2009/article/details/81504073