Redisキャッシュ失効メカニズム

4904 ワード
redis データベース IT技術
Redisキャッシュが無効になった物語EXPIREというコマンドから言えば、EXPIREはユーザーがあるkeyにタイムアウト時間を指定することを許可し、この時間を超えるとkeyに対応する値がクリアされ、この文章は主にRedisソースコードを分析した上でRedis設計者の立場に立ってRedisキャッシュの無効に関する問題を考える.
Redisキャッシュ失効メカニズム
Redisキャッシュの無効化メカニズムは、キャッシュアプリケーションの一般的なシーンに対応するために設計され、シーンについて説明します.
バックエンド・データベースの圧力を軽減するため、Redisサービスを利用して変化頻度の低いデータをDB loadからキャッシュに入れることができて嬉しいです.そのため、その後しばらくはキャッシュからデータを直接取ることができますが、しばらくしてから、DB loadから現在のデータを再びキャッシュに入れることを望んでいます.このことはどうしますか.
問題が提起されたが,この問題はどうやって解決するのか.はい、私たちは手元の言語ツールに詳しいので、すぐにこのような論理を書くことができると信じています.私たちは前回db loadからデータを記録し、サービスに応答するたびに時間が期限切れになったかどうかを判断し、dbから再loadしたかどうかを判断します.......もちろんこの方法も可能ですが、Redis command documentを調べてみると、もともとやる必要のないことをしたことに気づきました.Redis自体がこのメカニズムを提供しており、EXPIREコマンドを利用すれば簡単に解決できます.
EXPIRE key 30

上のコマンドはkeyに30秒の期限切れを設定し、この時間を超えると、この値にアクセスできないはずです.ここまで、キャッシュの期限切れメカニズムとキャッシュの期限切れメカニズムのいくつかのアプリケーションシーンを理解しました.次に、この問題を深く探り続けます.Redisキャッシュの期限切れメカニズムはどのように実現されていますか.
ちえんこしょうきこう
遅延失効メカニズムは、クライアントがkeyの操作を要求すると、Redisはクライアントが操作を要求するkeyに対して有効期間検査を行い、keyが期限切れになってから対応する処理を行うと、遅延失効メカニズムも消極的失効メカニズムと呼ばれる.t_を見てみましょうstringコンポーネントは、getリクエスト処理のサービス側にスタックを実行します.
getCommand 
     -> getGenericCommand 
            -> lookupKeyReadOrReply 
                   -> lookupKeyRead 
                         -> expireIfNeeded

肝心なのはexpireIfNeedで、Redisはkeyのget操作の前にkey関連の値が失効したかどうかを判断します.ここではまずエピソードを挿入し、Redisに実際に値を格納している場所がどのようになっているかを見てみましょう.
typedef struct redisDb {
    dict *dict;                 /* The keyspace for this DB */
    dict *expires;              /* Timeout of keys with a timeout set */
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP) */
    dict *ready_keys;           /* Blocked keys that received a PUSH */
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */
    int id;
    long long avg_ttl;          /* Average TTL, just for stats */
} redisDb;

上はRedisで定義された構造体で、dictはRedisで実装された辞書です.つまり、各DBには上の5つのフィールドが含まれています.ここでは2つの辞書にしか関心がありません.1つはdictで、1つはexpiresです.
  • dictは、通常のデータを格納するために使用されます.例えば、set key「hahaha」を実行し、このデータはdictに格納されます.
  • expiresは、上記のベースに実行されたexpire key 1のような期限切れのkeyを格納するために使用され、expiresにレコードが追加されます.

    • 振り返ってexpireIfNeededの流れを見ると、大体次のようになります.
  • expiresからkeyの期限切れ時間を検索し、説明が存在しない場合は対応するkeyが期限切れ時間を設定していない場合、直接返します.
  • slaveマシンであれば、Redisはデータの一貫性を保証し、簡単に実現するために、キャッシュが無効になったアクティブ権をMasterマシンに渡すため、slaveマシンはkeyを無効にする権限がないため、直接戻ります.
  • 現在マスターマシンでkeyが期限切れの場合、マスターは2つの重要なことをします:1)AOFファイルに削除コマンドを書き込みます.2)Slaveの現在のキーが無効になったことを通知し、削除することができます.
  • masterローカルの辞書からkeyペアの値を削除します.

    • アクティブフェイルオーバメカニズム
    アクティブな失効メカニズムは、アクティブな失効メカニズムとも呼ばれます.すなわち、サービス側は、失効したキャッシュをタイミングよくチェックし、失効した場合は対応する操作を行います.
    Redisは単一スレッドであり、イベント駆動に基づいて、RedisにEventLoopがあり、EventLoopは2つのイベントの処理を担当していることを知っています.
  • のクラスはIOイベントであり、これらのイベントは最下位のマルチプレクサから分離される.
  • クラスは、主にタスクのタイミング実行に使用されるタイミングイベントである.

    • RedisのEventLoopとNetty、JavaScriptのEventLoop機能は似ているように見えますが、ネットワークI/Oイベントの処理一方で、小さなタスクもできます.
    なぜRedisの単一スレッドモデルについて言及したのか.Redisのアクティブ失効メカニズムロジックは、主スレッドによって実行されるタイミングタスクとして扱われるため、関連コードは以下の通りである.
    if(aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL) == AE_ERR) {
        redisPanic("Can't create the serverCron time event.");
        exit(1);
    }

    serverCronはこのタイミングタスクの関数ポインタであり、adCreateTimeEventはserverCronタスクをEventLoopに登録し、最初の実行時間を1ミリ秒後に設定します.次に、私たちが知りたいことはすべてserverCronの中にあります.serverCronはいくつかのことをしています.私たちは本編の内容に関連する部分だけに関心を持っています.つまり、キャッシュの失効がどのように実現されているのか、コードが何をしているのか、呼び出しスタックが直感的だと思います.
    aeProcessEvents
    ->processTimeEvents
        ->serverCron 
             -> databasesCron 
                   -> activeExpireCycle 
                           -> activeExpireCycleTryExpire

    EventLoopは、タイミングタスクの処理によりserverCronロジックの実行をトリガし、最終的にkeyの期限切れ処理を実行するロジックであり、activeExpireCycleロジックはmasterのみで行うことができる.
    問題を残す
    Redisのキャッシュ失効に対する処理メカニズムは大きく2つに分けられ、1つはクライアントがkeyにアクセスする際の消極的な処理であり、1つはメインスレッドが定期的に積極的にキャッシュ失効クリーンアップロジックを実行することであり、上の文章はいくつかの詳細についてまだ紹介していないが、Redisキャッシュ失効実現メカニズムという話題について、本文はいくつかの問題を残している.
  • Redisキャッシュ失効論理はなぜmasterのみが操作できるのですか?
  • では、クライアントがslaveにアクセスしている場合、slaveが失効キャッシュをクリーンアップしない場合、今回のクライアントは失効キャッシュを取得したのではないでしょうか.
  • で説明した2つのキャッシュ失効メカニズムには、それぞれどのようなメリットとデメリットがありますか?Redisデザイナーはなぜこのように設計したのですか?
  • サービス側のクライアントに対する要求処理は単一スレッドであり、単一スレッドはまた失効したキャッシュを処理し、Redis自身のサービス能力に影響を与えるのではないでしょうか.

    • 参考文献
    『Redisソース』
    関連記事
  • Redisの不正アクセス欠陥は、システムをブラック
    • に簡単に導くことができる.
  • SQL SERVERでインデックス検索がインデックススキャン
    • になる場合
  • Redis 3.0.0正式版リリース、新しい分散型高可用性データベース
  • Redisハッシュテーブルの実装要点
  • Redisを用いる分散ロック
    • を実現する.
  • Redisに基づく分散ロック、Redisson使用及びソースコード分析
    • を実現する.
  • ベテランドライバーRedisキャッシュを使用した複雑なクエリー
  • Redisによる分散ロックとタスクキュー
    • の実装
  • Redisの性能幻想と残酷な現実
  • 10個のRedis推奨/テクニック
    • Redisキャッシュの失効メカニズムは、記事-伯楽オンラインで開始されます.
    白駿11815偶数?奇数.
    TIL 7週間(IM)