redis持続化の概要

永続化の概要
永続化には一般的に2つの考え方があります.

現在のデータ状態を保存し、スナップショット形式で、データ結果を格納し、格納フォーマットが簡単で、注目点はデータにある.

データの操作過程を保存し、ログ形式、記憶操作過程、記憶フォーマットが複雑で、データの操作過程に注目する.

以上の2つの考え方はredisにおいてRDBとAOFにそれぞれ対応している.
RDB
RedisコマンドラインにSAVEコマンドを入力すると、手動でRDB永続化を1回実行できます.しかし、このようなフロント起動方式では、現在のRDBプロセスが完了するまで、オンライン環境は使用を推奨しない現在のRedisサーバがブロックされます.実際にredis内部のRDBに関する動作はbgsaveの方式を採用している.
bgsave SAVE単一スレッド実行方式の効率が低すぎる以上、bgsaveバックグラウンドで非同期に実行することが考えられる.この命令実行後、redisはfork関数生成サブプロセスを呼び出してrdbファイルを作成する.
しかし、bgsaveを手動で実行するたびに永続化するのは愚かで、自動化できるに違いありません.プロファイルで構成する必要があります.

save second changes
#          key                 
second：       
changes：  key    
 ：
save 900 1
save 300 10
save 60 10000
         ，    rdb     。

#   rdb  
save ""

RDB関連構成
フィールドの設定
説明
dbfilename dump.rdb
ローカルデータベースのファイル名を設定します.デフォルトはdumpです.rdbは、通常dump-ポート番号に設定.rdb
dir
rdbファイルを格納するパス、ディレクトリ名dataの設定
rdbcompression yes
ローカルデータベースに格納するときにデータを圧縮するかどうかを設定します.デフォルトはyesで、LZF圧縮を採用します.通常、デフォルトはオン状態です.noに設定すると、CPUの実行時間を節約できますが、格納されているファイルは大きくなります.
rdbchecksum yes
RDBファイルフォーマットの検証を行うかどうかを設定します.この検証プロセスはファイルの書き込みとファイルの読み取りの両方で行われます.通常、デフォルトではオープン状態です.noに設定すると、読み書きプロセスの約10%の時間消費を節約できますが、一定のデータ破損リスクを格納します.
stop-writes-on-bgsave-error yes
バックグラウンドストレージ中にエラーが発生した場合、保存操作を停止するかどうかは、デフォルトでオンになります.
RDB特殊起動形式

フルコピー:プライマリ・スレーブ・コピーに表示されます.

サーバの稼働中に再起動:debug reload

サーバをシャットダウンするときの指定保存データ:shutdown save

デフォルトでshutdownコマンドを実行すると、自動的にbgsaveが実行されます(AOF永続化機能がオンになっていない場合).
RDBの利点

RDBはコンパクトな圧縮バイナリファイルであり、ストレージ効率が高い

である.

RDB内部に格納されているのは、ある時点におけるredisのデータスナップショットであり、データバックアップ、フルコピーなどのシーン

に非常に適している.

RDBがデータを復元する速度はAOFよりずっと速い

アプリケーション:サーバでX時間ごとにbgsaveバックアップを実行し、災害復旧用にRDBファイルをリモートマシンにコピーします.

RDBの欠点

RDB方式は、命令を実行するにしても、構成を利用するにしても、リアルタイムで永続化することができず、データを失う可能性が高い

である.

bgsave命令fork操作を実行するたびにサブプロセスを作成し、メモリは

を追加消費する.

Redisの多くのバージョンでRDBファイルフォーマットのバージョン統一が行われていないため、各バージョンのサービス間でデータフォーマットが互換性がない現象が発生する可能性がある

.

スナップショットの考え方に基づいて、読み書きのたびにすべてのデータであり、データ量が大きい場合、IO効率は非常に低い

である.
AOF
AOF(append only file)永続化:コマンドを書き込むたびに独立したログで記録し、再起動時にAOFファイルのコマンドを再実行してデータを復元する目的を達成します.RDBと比較して、記録データを記録データに変更するプロセスを簡単に説明することができる.AOFの主な役割はデータ永続化のリアルタイム性を解決することであり,現在はRedis永続化の主流である.
AOF書き込みデータの3つのポリシー
RDBと同様に、AOFはバックグラウンドforkのサブプロセスを行い、メインプロセスはサービスを行い、サブプロセスはAOF持続化を実行し、データはディスクにdumpされる.ただし、RDBとは異なり、バックグラウンドサブプロセスの永続化の過程で、メインプロセスは期間中のすべてのデータ変更を記録し、コマンドが先にキャッシュキュー(バッファ)に入り、その後、バックグラウンドサブプロセスが終了するまで待ってから、Redis更新キャッシュがAOFファイルに追加されると理解できる.この期間には3つのポリシーがあります.

always(毎回)書き込み操作ごとにAOFファイルに同期し、データに誤差がなく、性能が低く、使用を推奨しない.

everysec(毎秒)毎秒バッファ内の命令をAOFファイルに同期させ、データの正確性が高く、性能が高く、使用を推奨し、デフォルト構成でもあり、システムが突然ダウンタイムした場合に1秒以内のデータを失う.

no(システム制御)はオペレーティングシステムによってAOFファイルに同期する周期を制御し、全体のプロセスは制御できない.

AOF関連構成
フィールドの設定
説明
appendonly yes|no
AOF持続化機能をオンにするかどうかは、デフォルトではオンになっていません
appendfilename filename
AOF永続化ファイル名、デフォルトファイル名はappendonly.aof、appendonly-ポート番号に設定することをお勧めします.aof
dir
AOF永続化ファイル保存パス、RDB永続化ファイルと一致、ディレクトリ名data
appendfsync always|everysec|no
AOF書き込みデータポリシー
AOF書き換え
コマンドがAOFに書き込まれるにつれて、ファイルはますます大きくなり、この問題を解決するために、RedisはAOF書き換えメカニズムを導入してファイルボリュームを圧縮した.AOFファイル書き換えは、Redisプロセス内のデータを書き込みコマンドに変換して新しいAOFファイルに同期させるプロセスである.簡単に言えば、同一データの複数のコマンド実行結果を最終結果データに対応するコマンドに変換して記録する.
たとえば同じキーを複数回セットして、最後だけ記録すればいいです.
AOF書き換え規則

プロセス内でタイムアウトしたデータはファイルに書き込まれません.

無効な命令を無視し、書き換え時にプロセス内のデータを使用して直接生成することにより、新しいAOFファイルは最終データの書き込み命令のみを保持する.

同じデータに対する複数の書き込みコマンドが1つのコマンドに統合されます.データ量が大きすぎてクライアントバッファがオーバーフローしないようにlist,set,hash,zsetなどのタイプに対して,各命令は最大64要素まで書き込まれる.

AOF書き換え方式

手動書き換え:bgrewriteaof

自動書き換え:

auto-aof-rewrite-min-size size 
# size     64mb
auto-aof-rewrite-percentage percentage 
#   100，   AOF             AOF        

の構成
RDBとAOFの比較
永続化方式
RDB
AOF
ストレージ容量の使用
小(データレベル:圧縮)
大きい(指令レベル:書き換え)
きおくそくど
遅い
速い
リカバリ速度
速い
遅い
データセキュリティ
データが失われます
策略によって決定する.
リソース消費
ヘビー級
低/軽量級
起動の優先度
低い
高い
数分以内のデータ損失に耐えられない場合は、業務データに非常に敏感で、AOFを選択します.AOFファイルのストレージ容量が大きく、リカバリ速度が遅い.
数分以内のデータロスに耐え、ビッグデータセットのリカバリ速度を追求できる場合は、RDBを選択します.比較的コンパクトなデータ永続化を実現すると、Redisのパフォーマンスが低下します.
ソース:https://www.bilibili.com/video/BV1CJ411m7Gc