Redisキーの有効期限ポリシー

3761 ワード

1、有効期限の設定
  • expire key time(s)--これは最も一般的な方法
  • です.
  • setex(String key,int seconds,String value)--文字列固有の方法
  • 注意:
  • string独自の有効期限設定方法に加えて、他のタイプはexpire方法によって時間
  • を設定する必要がある.
  • 時間が設定されていない場合、キャッシュは期限切れになりません.
  • 期限切れが設定されている場合、その後キャッシュを期限切れにしないようにpersist key
  • を使用します.
    2、3種類の期限切れの策略
  • タイミング削除
  • とは、keyの有効期限を設定するとともに、そのkeyの有効期限が到来すると、そのkeyを削除するタイマを作成することを意味する.
  • の利点:メモリができるだけ早く解放されることを保証する
  • 欠点:
  • 期限切れのkeyが多いと、これらのkeyを削除するのに多くのCPU時間がかかり、CPU時間が緊張している場合、CPUはすべての時間を重要なことに使うことができず、これらのkey
  • を削除するのに時間がかかる.
  • タイマの作成に時間がかかり、有効期限を設定したkeyごとにタイマを作成すると(大量のタイマが発生する)、パフォーマンスに大きな影響を及ぼす
  • .
  • 誰も
  • を使っていません

  • 不活性削除
  • 意味:keyが期限切れになったときは削除せず、データベースからkeyを取得するたびに期限切れかどうかをチェックし、期限切れになったら削除しnullを返す.
  • の利点:削除操作はデータベースからkeyを取り出すときにのみ発生し、現在のkeyのみを削除するため、CPUに対する時間の占有量は比較的少ない、しかもこのときの削除はすでにしなければならない段階に達している(この時点で削除しなければ、期限切れのkeyを取得する)
  • .
  • 欠点:大量のkeyがタイムアウト時間を超えた後、長い間取得されていない場合、メモリ漏洩(不要なゴミが大量のメモリを占有する)が発生する可能性がある
  • 定期削除
  • 意味:期限切れkey削除操作
  • を一定時間毎に実行する.
  • の利点:
  • 削除操作の時間と周波数を制限ことにより、削除操作によるCPU時間の消費を低減する--「タイミング削除」の処理の欠点
  • .
  • 期限切れkeyを定期的に削除する--「不活性削除」を処理する欠点
  • の欠点
  • メモリの友好的な面では、「タイミング削除」
  • に及ばない.
  • CPUの時間の友好の方面で、“不活性な削除”
  • に及ばない
  • 難点
  • 削除操作の実行時間(削除ごとにどれくらいの時間が実行されるか)と実行頻度(どのくらいの時間ごとに削除されるか)を合理的に設定
  • .


    注意:
  • 上で述べたデータベースはメモリデータベースを指し、デフォルトではredisサーバごとに16個のデータベース(データベースの設定については、下のコードを参照)があり、デフォルトでは0番のデータベースが使用され、すべての操作は0番のデータベースに対する操作
  • である.
    #        。   16  ,    DB 0,    "select 1"        
    #   :      0    ,                 0     ,
    #    1           ,      set    
    #    0           1    ,    "move key 1"
    databases 16
    
  • memcachedは不活性削除のみを用いたが、redisは不活性削除と定期削除を同時に用いた.これも両者の異なる点である(redisがmemcachedより優れている点と見なすことができる)
  • 不活性削除では、keyを取得したときだけkeyが期限切れであるかどうかをチェックするわけではありません.keyの設定方法によってもチェックされます(eg.setnx key 2 value 2:このメソッドはmemcachedのaddメソッドに類似しており、設定されたkey 2がすでに存在する場合はfalseを返し、何もしない.設定されたkey 2が存在しない場合はキャッシュkey 2-value 2を設定する.このメソッドを呼び出すとredisにkey 2が存在するが、このkey 2は期限切れであり、削除を実行しない場合は操作するとsetnxメソッドはfalseに直接戻ります.つまり、key 2-value 2の再設定に成功していないため、setnxが実行される前にkey 2の期限切れチェックを必ず行う必要があります)
  • .
    3、Redisが採用した期限切れの策略
    不活性削除+定期削除
  • 不活性削除プロセス
  • getやsetnxなどの操作を行う場合は、keyが期限切れであるかどうかを確認し、
  • 期限が切れた場合、keyを削除し、対応する操作を実行します.
  • 期限が切れていない場合は、対応する操作
  • を直接実行する.
  • 定期削除プロセス(簡単に言えば、指定された数のライブラリに対する各ライブラリのランダム削除は、指定された数の期限切れkey以下)
  • 各データベースを巡回します(redis.confで構成されているdatabaseの数で、デフォルトは16です).
  • 現在のライブラリで指定された数のkeyをチェックします(デフォルトでは、ライブラリごとに20のkeyをチェックします.このループが20回実行されることに注意してください.ループ時の下の説明です).
  • 現在のライブラリにキーが1つも設定されていない場合は、次のライブラリのループ
  • を直接実行します.
  • は、期限切れが設定されたkeyをランダムに取得し、そのkeyが期限切れであるかどうかを確認し、期限切れである場合、key
  • を削除する.
  • 定期削除操作が指定時間に達したか否かを判断し、達した場合は定期削除を直接終了する.




  • 注意:
  • 定期削除の場合、プログラムにグローバル変数current_があります.dbは次の遍歴するライブラリを記録します.16個のライブラリがあると仮定します.今回は定期的に10個の遍歴を削除しました.そのときのcurrent_dbは11で、次回の定期削除は11番目のライブラリから巡回し、current_を仮定します.dbは15に等しいので、その後、0番ライブラリから
  • (current_db=0)を巡回します.
  • 実際に定期的に削除する時間と頻度は操作されていないので、この2つの値の設定方法は疑問として?

  • 4、RDBによる期限切れkeyの処理
    期限切れkeyはRDBに何の影響もありません
  • メモリ・データベースからRDBファイルへのデータの永続化
  • キーを永続化する前に、有効期限が切れているかどうかを確認します.有効期限が切れたキーはRDBファイル
  • には入りません.
  • RDBファイルからメモリ・データベースへのデータのリカバリ
  • データがデータベースにロードされる前に、keyに対して期限切れのチェックが行われ、期限切れの場合、データベース(メインライブラリの場合)
  • はインポートされません.

    5、AOFによる期限切れkeyの処理
    期限切れkeyはAOFに何の影響もありません
  • メモリ・データベースからAOFファイルへのデータの永続化:
  • keyが期限切れになった後、まだ削除されていない場合、変更コマンドが発生していないためaofファイルには入らない持続化操作を実行する
  • .
  • keyが期限切れになると、削除操作が発生すると、プログラムはaofファイルにdelコマンド(将来aofファイルでデータを復元すると、その期限切れのキーが削除される)
  • を追加する.
  • AOF書き換え
  • 書き換える場合、keyが期限切れであるか否かを先に判断し、期限切れのkeyはaofファイル
  • に書き換える.