この記事では、Redis 永続性の完全版を理解することができます。

#❝この記事では、ナレッジポイントについて説明します 永続性の概要 RDB AOF RDBとAOFの違い 永続化アプリケーションのシナリオ

❞

序文

❝Kaka は、インタビュー ガイドを作成するためのロードマップをまとめ、そのロードマップに従って記事を書く準備をしましたが、後になって、補足されていない知識ポイントを追加していることに気づきました。また、パートナーの皆様にも情報の追加にご協力いただけることを楽しみにしております。コメントセクションでお会いしましょう！

##❞

#ここに画像の説明を挿入

デモ環境centos7.0 redis4.0 redis ストレージディレクトリ:/usr/local/redis redis.conf 格納ディレクトリ:/usr/local/redis/data

1. 永続性の概要

Redis 内のすべてのデータはメモリに保存され、Redis がクラッシュするとデータが失われます。 。 Redis の永続化とは、データをディスクに保存することです。永続的なストレージ メディアを使用してデータ プロセスを保存し、特定の時点で保存されたデータを復元する動作メカニズムは、永続性と呼ばれます。

永続化プロセスでは何が保存されますか?

最初のスナップショット フォームはデータ結果を保存し、後述する RDB であるデータに焦点を当てます。

2 番目の操作プロセスは操作プロセスを格納します。ストレージ構造は複雑であり、焦点は次のとおりです。ポイントはデータ操作プロセスであり、これは以下で説明する AOF

##2 です。 2-1 RDB 起動モード -- save コマンド

##次の図は redis.conf の設定情報で、save を実行すると、 dump.rdbここで値を設定して保存すると、/usr/local/redis/data に dump6379.rdb のファイルが作成されます。

2-2 RDB 起動モード -- コマンド関連の設定を保存

• dbfilename dump6379.rdb:ローカル データベース ファイル名を設定します。デフォルト値は dump.rdb
• dir: rdb ファイルを保存するパス
• rdbcompression yes:ストレージをローカルに設定します データベース内のデータを圧縮するかどうか、デフォルトは lzf 圧縮を使用して Yes です
• rdbchecksum yes: RDB ファイル形式の検証を処理するかどうかを設定します、検証プロセスが実行されます

2-3 RDB データのリカバリ

In実際、このデータ回復は他の関係とは異なります。基本的に、大規模なデータベースを復元するために何もする必要はありません。再起動してください

2-4 RDB -- 保存コマンドの仕組み

この写真はオンライン ビデオから引用しました。 save コマンドを実行すると、現在の RDB プロセスが完了するまで現在の Redis サーバーがブロックされ、長期的なブロックが発生する可能性があります。このコマンドは基本的に放棄され、作業プロセス中に使用されなくなります。すべての

を bgsave に置き換えます

2-5 RDB -- bgsave 命令の動作原理

bgsave が Redis で実行されると、直接戻る バックグラウンドでの保存が開始されました

現時点では、ログ ファイルを確認しています。bgsave コマンドは、保存ブロックの問題に対して最適化されています

##2-5 RDB -- 設定ファイル自動起動

<span style="display: block; background: url(https://my-wechat.mdnice.com/point.png); height: 30px; width: 100%; background-size: 40px; background-repeat: no-repeat; background-color: #272822; margin-bottom: -7px; border-radius: 5px; background-position: 10px 10px;"></span><code class="hljs" style="overflow-x: auto; padding: 16px; color: #ddd; display: -webkit-box; font-family: Operator Mono, Consolas, Monaco, Menlo, monospace; font-size: 12px; -webkit-overflow-scrolling: touch; letter-spacing: 0px; padding-top: 15px; background: #272822; border-radius: 5px;"><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 900 1<br/><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 300 10<br/><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 60 10000<br/><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">stop-writes-on-bgsave-error</span> <span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">yes</span><br/></code>

save [時間] [キー変更回数]

つまりつまり、300 秒間に 10 件あります。キーの値が変更されると、bgsave

がバックグラウンドで実行されます。

#3. AOF

##3-1 AOF の概念 #AOF 永続性: 各書き込みコマンドを独立したログに記録し、再起動時に AOF ファイル内のコマンドを再実行してデータを回復します。 RDB と比較すると、簡単に説明すると、データ生成を記録するプロセスです。

AOF の主な機能は、データ永続化のリアルタイム性を解決することであり、現在、Redis 永続化の主流の方法です

3-2 AOF データ書き込み処理redis コマンドの実行

redis のAOF はコマンド バッファー領域を更新します

その後、特定のポリシーに従って redis.conf で構成された .aof ファイルに同期します

3-3 AOF 書き込みデータの 3 つの戦略

• 常に: すべての書き込み操作は同期されます。 AOF ファイルでは、データ エラーがゼロでパフォーマンスが低くなります。
• everysec の使用は推奨されません: バッファ内の命令を毎秒 AOF ファイルに同期します。データの精度は次のとおりです。パフォーマンスが高い「High」が推奨され、デフォルトの構成でもあります。ただし、システムが突然クラッシュすると、1 秒以内のデータが失われます。
• no: オペレーティング システムは、AOF ファイルへの各同期のサイクルを制御し、プロセス全体は制御不能

3-4 AOF機能有効

• 設定: appendonly yes|no
• Function: AOF 永続化機能を有効にするかどうか、デフォルトは無効です
• Configuration : appendfsync always| Everysec | no
• 関数: AOF 書き込みデータ戦略
• 構成: appenfilename filename
• 関数: AOF 永続ファイル名、デフォルト名は appendonly.aof

# 次に、redis サービスを再起動して、それを使用できます。 usr/local/redis/data ディレクトリに appendonly.aof ファイルが表示されます。次に、redis クライアントでコマンドを実行してチェックアウトします。データがファイル appendonly.aof に保存されることがわかります。

3-5 AOF 書き込みデータの問題

最初にケースを見てみましょう。 name key を繰り返し設定した後、 appendonly.aof ファイルを開いて表示すると、3 つの操作があることがわかりますが、これら 3 つの操作はすべて 1 つのキーで変更されます。最後のキーだけを保存することはできないでしょうか?この質問では、引き続き下を向いていきます。

3-6 AOF 書き換え

コマンドが続くと、 AOF に書き込むとファイルがどんどん大きくなってしまうため、redis ではファイルサイズを圧縮する AOF 書き換え機構を導入しています。 AOF ファイルの書き換えは、redis プロセスのデータを書き込みコマンドに変換し、新しい AOF ファイルに同期するプロセスです。簡単に言えば、同一データに対する複数のコマンドの実行結果を、最終結果データに対応する命令の実行記録に変換します。

たとえば、上記では set name コマンドを 3 回実行しましたが、最終的に必要なのは最後の実行のデータだけです。つまり、最後の実行レコードのみが必要です。

3-7 AOF書き換え機能

• ディスク使用量の削減とディスク使用率の向上
• 永続性の効率を向上させ、永続性の書き込み時間を削減し、IO パフォーマンスを向上させます
• ##データ回復時間を短縮し、データ回復効率を向上させます

3-8 AOF 書き換えルール

• プロセスがタイムアウトしました。データは書き込まれません。
#無効な命令を無視し、再書き込み時にインプロセス データを使用してそれらを直接生成するため、新しい AOF ファイル値が最終的なデータ書き込みコマンドを保持します。 del 命令、
• hdel、srem
  など。キー値を複数回設定するなど。
同じデータに対する複数の書き込みコマンドは 1 つのコマンドにマージされます。
• lpush list a lpush lsit b lpush list c
  などlpush list a b c に変換できます。ただし、過剰なデータ量によるクライアントのバッファ オーバーフローを防ぐため、list、set、hash、zset 型の各命令は最大 64 個の要素を書き込むことができます

3-9 AOF 手動書き換え

コマンド: bgrewriteaof

次に、3-質問 5 では、コマンド ラインで bgrewriteaof コマンドを実行し、appendonly.aof ファイルを確認します。

実行後、ファイルが小さくなり、ファイル内にコマンドが 1 つだけあることがわかります

#ここに画像の説明を挿入

3-10 AOF マニュアル書き換えの動作原理

ここに画像の説明を挿入

3-11 AOF 自動書き換え

構成: auto-aof-rewrite-percentage 100 | auto-aof-rewrite-min-size 64mbトリガー比較パラメーター: aof_current_size | aof_base_size

aof_current_size > auto-aof-rewrite-min-size 64mb が書き換えを開始するとき

この画像はインターネットからのものです

3-11 AOF ワークフローとリライト フロー = プロセス

##4. RDB と AOF の違い

• ## はデータに非常に敏感であるため、デフォルトの AOF 永続化ソリューション

  AOF 永続化戦略は、毎秒、1 秒あたりの fsync 回数を使用します • この戦略 redis は、依然として良好な処理パフォーマンスを維持できます。問題が発生した場合、最大 0 ～ 1 内のデータSecond.
  注: AO ファイルのストレージ サイズが大きく、回復速度が遅いため
• データプレゼンテーション段階の有効性、RDB 永続化ソリューションの使用をお勧めします

  データは段階中に損失なく適切に維持できます (この段階は開発者が操作し、 RDB ソリューションは通常、ステージ ポイントのデータ リカバリに使用されます。
  注: RDB を使用して厳密なデータ永続性を実現すると、Redis のパフォーマンスが非常に低下します。低い
• 総合比較
  • RDB と AOF の選択は実際にはトレードオフであり、それぞれに利点と欠点があります。
  • 数分以内のデータ損失に耐えられない場合は、業界データに非常に敏感な場合は、A0F
  • を選択してください。数分以内のデータ損失に耐えられる場合、大規模なデータ セットの回復速度を追求する場合は、RDB
  を選択してください
  • 災害復旧に RDB を使用する
  • 二重保険戦略、RDB と AOF を同時に開始、再起動後、Redis は A0F を優先してデータを回復し、失われたデータの量

  ❝

  学習の継続、ブログの継続、共有の継続は、カカが就任以来常に堅持してきた信念です。 Kaka の記事が巨大なインターネットで見られることを願っています。少しでもお役に立てれば幸いです。次号でお会いしましょう。

  ❞

# 推奨: 「

redis チュートリアル 》

以上がこの記事では、Redis 永続性の完全版を理解することができます。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。