Redisの永続化と期限切れキー

5542 ワード
概要
Redisは、非常に広く使用されているKey-Valueメモリ・データベースです.データがメモリに格納されているため、アクセス速度が非常に速い.しかし、多くの場合、Redisのデータをバックアップのためにハードディスクに保存する必要があります.Redisは2つのデータ永続化方式を提供し,それぞれRDBとAOPであり,本論文では,この2つの方式の使用と持続化に及ぼす期限切れキーの影響を解析した.
RDB
RDBとは、Redisデータベースのある時点でのスナップショットをディスクに保存することを意味し、生成されたRDBファイルは圧縮されたバイナリファイルであり、このファイルによってRedisのデータ状態を復元することができる.
スナップショットを作成する方法は次のとおりです.
  • クライアントはBGSAVEコマンドをRedisに送信し、Redisはforkを呼び出してサブプロセスを作成し、サブプロセスはスナップショットをハードディスクに書き込む責任を負い、親プロセスはコマンド要求の処理を継続する.
  • クライアントは、SAVEコマンドをRedisに送信し、Redisはスナップショットの作成を開始し、完了するまで他のコマンドに応答しない.
  • ユーザは、save 60 10000のようなsave構成オプションを設定すると、Redisがスナップショットを最近作成したことから、「60秒以内に10000回書き込みがある」という条件が満たされると、RedisはBGSAVEコマンドを自動的にトリガーする.ユーザーが複数のsave構成オプションを設定している場合、いずれかのsave構成が満たされると、RedisはBGSAVEコマンドをトリガーします.save構成のフォーマットは次のとおりです:
    • save 60 10000
stop-writes-on-bgsave-error no
rdbcompression yes    //     
dbfilename dump.rdb  // RBD      

dir ./
  • Redisは、SHUTDOWN命令によりサーバのシャットダウン要求を受信した場合、またはTERM命令を受信した場合、SAVE命令を実行し、すべてのクライアントをブロックし、要求を実行しない.SAVEコマンドの実行が完了したら、サーバを閉じます.
  • は、1つのRedisサーバが別のRedisサーバに接続され、1回のレプリケーション操作を開始するためにSYNCコマンドが相手に送信されたとき、プライマリサーバがBGSAVE操作を実行していないか、またはプライマリサーバがBGSAVEを実行したばかりではない場合、プライマリサーバはBGSAVEコマンドを実行する.

    • RDBの主な問題は、システムがクラッシュした場合、最近のスナップショットの実行後に変更されたデータが失われることです.したがって、RDBは、データの一部が失われても影響を及ぼさないアプリケーションに適している.
    AOF
    AOFとは、実行されたすべての書き込みコマンドをAOFファイルの末尾に書き込み、データの変化を記録することである.RedisがAOFのデータを復元したい場合は、AOFファイルに含まれる書き込みコマンドを再実行すればよい.
    AOFの構成は以下の通りです.
    appendonly yes  //    aof
appendfsync everysec // aof      
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100 //                    aof
auto-aof-rewrite-min-size 64mb  //                     aof

    上記の構成では、appendfsync everysecは同期の周波数を設定している.アプリケーションがハードディスク(HDD)にデータを書き込むには、次の3つのステップがあります.
  • は、file.write()を呼び出してファイルへの書き込みを呼び出し、書き込みが必要なコンテンツがバッファに格納され、実際にハードディスクに書き込まれたわけではありません.
  • オペレーティングシステムは、ある時点でバッファの内容をハードディスクに書き込むと、データが本当に永続化されます.

    • オペレーティングシステムでは、以上のファイル書き込み方式を使用してパフォーマンスを向上させるため、ハードディスクI/O操作は時間がかかります.しかし,この方式の欠点は,機器がクラッシュするとバッファの内容が失われることである.プログラムは、file.flush()を使用して、オペレーティングシステムにバッファの内容をハードディスク(HDD)にできるだけ早くリフレッシュするように要求することができるが、いつ実行を開始するかはオペレーティングシステムによって決定される.プログラムは、オペレーティングシステムにファイルをハードディスクに同期(sync)するように命令することもでき、同期操作は、データがハードディスクに書き込まれるまでアプリケーションをブロックします.同期操作が完了すると、システムに障害が発生しても、同期されたファイルには影響しません.
    Redisでは、appendfsyncがハードディスク(HDD)にデータを完全に同期させる方法を指定できます.この構成には、3つのオプションがあります.
  • always:各Redis書き込みコマンドは、すぐにハードディスクに同期します.これは、パフォーマンスを消費する
    • です.
  • everysec:毎秒1回の同期を実行し、パフォーマンスとデータセキュリティを両立させる、比較的一般的なオプション
    • です.
  • no:オペレーティングシステムに同期をいつ行うかを決定させる
    • alwaysは、Redisがクラッシュしたときに失われるデータを最小限に抑えることができるが、最も性能を消費し、Redisの処理速度が遅くなる.ererysecは、パフォーマンスとデータセキュリティを両立させる方法であり、この場合、システムがクラッシュすると、ユーザは最大1秒以内にデータを失うことになる.noオプションは完全にオペレーティングシステムに同期を渡すことが決定され、性能もeverysecよりそれほど高くなく、推奨されない方式である.
    AOFの欠点は、Redisが稼働するにつれて、AOFファイルが非常に大きくなり、ハードディスク(HDD)のスペースが切れてしまう可能性があることです.この問題を解決する方法はAOF書き換えである.
    書き換える
    クライアントは、RedisにAOFファイルを書き換えるようにBGREWRITEAOFコマンドを送信することができ、Redisは冗長なAOFコマンドを削除して書き換えることができ、AOFファイルの体積ができるだけ小さくなる.
    クライアントがBGREWRITEAOFコマンドを自発的に送信するほか、構成を使用して、Redisが一定の条件を満たす場合にAOFファイルの書き換えを自動的に開始するようにしてもよい.たとえば、前のセクションにはauto-aof-rewrite-percentage 100とauto-aof-rewrite-min-size 64mbが設定されています.この2つの構成は、AOFファイルが64 MBより大きく、前回の書き換え後のサイズより2倍になった場合、RedisはBGREWERITEAOFコマンドを実行することを意味する.
    期限切れキーの削除
    ユーザはRedisのキーの有効期限を設定することが多いため、有効期限キーを削除するために一定のポリシーが必要であり、3つのポリシーがあります.
  • は、タイマによって期限切れが到着したときに期限切れのキーを削除するタイミングで削除する.この方式の利点はメモリを節約することであり、大量の期限切れキーがメモリリソースを占有することはないが、欠点はCPUリソースを消費することであり、特に期限切れキーの数が多い場合、削除操作に時間がかかりすぎて、Redisの応答時間を低減することである.
  • 不活性削除、すなわち、あるキーを取得するたびに期限が切れたかどうかを判断し、期限が切れていない場合は正常に値を返し、そうでなければこのキーを削除し、空に戻る.この方式の利点は、CPUリソースを節約するが、メモリを消費することである.特に期限切れキーの数が多い場合、大量のメモリが無効なキーで占有され、メモリ漏洩に相当します.
  • は定期的に削除されます.つまり、データベース内のキーは一定期間ごとにスキャンされますが、その一部だけをスキャンして、メモリとCPUのバランスをとるようにします.

    • 上記の3つの戦略から,1つ目だけではだめであり,Redisの応答時間が重要であることが分かる.2つ目は、キーを取得する際に期限が切れたかどうかを判断し、削除するかどうかを決定する良い方法で、多くのキーがタイムリーに削除できないという欠点があります.期限切れのキーが二度とアクセスされない場合は、メモリに永遠に残り、3つ目の方法はちょうど補うことができます.
    Redisの期限切れキーの削除ポリシーは、不活性削除と定期削除の組み合わせです.
    期限切れキーと永続化
    期限切れキーの削除ポリシーを理解したら、キーの期限切れ時間が永続化に与える影響を見てみましょう.
    RDBファイルを生成する過程で、1つのキーが期限切れになった場合、RDBファイルには保存されません.RDBをロードする場合は、次の2つのケースに分けられます.
  • Redisがプライマリ・サーバのモードで動作している場合、RDB内のキーは時間チェックされ、期限切れのキーはRedisに復元されません.
  • Redisがサーバからのモードで実行されると、RDB内のすべてのキーがロードされ、タイムチェックは無視されます.サーバからプライマリサーバとデータ同期を行うと、サーバからのデータが先に空になりますので、ロード期限切れキーに問題はありません.

    • AOFの場合、1つのキーが期限切れになった場合、AOFファイルにすぐに影響を与えることはありません.Redisは不活性削除と定期削除を使用しているため、このキーが削除された場合にのみAOFファイルにDELコマンドが追加されます.AOFを書き換える過程で、プログラムはデータベース内のキーをチェックし、期限切れのキーはAOFファイルに保存されません.
    実行中、プライマリ・スレーブ・レプリケーションのRedisでは、プライマリ・サーバとスレーブ・サーバの期限切れキーの処理も異なります.
  • プライマリサーバについて、1つの期限切れのキーが削除すると、対応するキー
    • がサーバから削除されることを通知するDELコマンドがサーバに送信される.
  • サーバから1つのキーを読み出すコマンドを受信した場合、このキーが期限切れになっても削除されず、通常通りこのコマンドを処理します.
  • サーバからプライマリサーバのDELコマンドを受信すると、対応する期限切れキーが削除されます.

    • この主な目的は、データの一貫性を保証することです.したがって、期限切れキーがプライマリ・サーバに存在する場合、セカンダリ・サーバにも必ず存在します.
    まとめ
    本論文では,Redisの2つの永続化方式を簡潔に整理し,Redisが期限切れキーを削除する戦略と永続化に及ぼす影響を解析した.この部分を理解することで、Redisの使用をより適切にすることができるだけでなく、レプリケーションなどのRedisの他のコンテンツの学習にも役立ちます.
    リファレンス
  • 『Redis実戦』
  • 『Redis設計と実現』
    • ページ転送&gridviewバインドテクニック
    CSS | float