Redis キャッシュ無効化メカニズムの概要

Redis キャッシュ障害の話は、EXPIRE コマンドから始まります。EXPIRE を使用すると、ユーザーはキーのタイムアウトを指定できます。この時間を超えると、キーに対応する値はクリアされます。この記事では主に、 Redis ソース コード: 上記の Web サイトでは、Redis キャッシュの障害に関連する問題を Redis 設計者の観点から考察しています。

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

Redis キャッシュ無効化メカニズムは、キャッシュ アプリケーションにおける非常に一般的なシナリオに対処するように設計されています。シナリオについて話しましょう:

バックエンド データベースへの負荷を軽減するために、私たちは Redis サービスを喜んで使用して、あまり頻繁に変更されないデータを DB ロードからロードし、キャッシュに置きました。したがって、一定期間内はキャッシュから直接データを取得できますが、一定期間が経過した後に現在のデータを DB からキャッシュに再度ロードしたいと考えています。

疑問が生じました。この問題をどのように解決すればよいでしょうか?さて、私たちは手元にある言語ツールに精通しており、このようなロジックをすぐに作成できると確信しています。データベースから最後にデータをロードした時間を記録し、毎回その時間が経過したかどうかを判断します。サービスに応答します。データベースからリロードしますか?もちろん、この方法も可能です。しかし、Redis コマンドのドキュメントを確認すると、行う必要のないことを行っていたことがわかりました。この仕組みは Redis 自体が提供しています。 EXPIRE コマンド:

EXPIRE key 30

上記のコマンドは、キーの有効期限を 30 秒に設定します。この時間を超えると、この値にアクセスできないはずです。これまでのところ、キャッシュ無効化メカニズムが何であるかを大まかに理解しました。一部のアプリケーション シナリオでは、この問題についてさらに詳しく説明します。Redis キャッシュ無効化メカニズムはどのように実装されていますか?

遅延無効化メカニズム

遅延無効化メカニズムとは、クライアントがキーの操作を要求したときに、Redis がクライアントによって要求されたキーの有効期間をチェックすることを意味します。対応する処理はキーの有効期限が切れた後にのみ実行されます。遅延障害メカニズムは、受動的障害メカニズムとも呼ばれます。 t_string コンポーネントでの get リクエスト処理のサーバー側実行スタックを見てみましょう:

getCommand 
     -> getGenericCommand 
            -> lookupKeyReadOrReply 
                   -> lookupKeyRead 
                         -> expireIfNeeded

重要な点は、expireIfNeed です。Redis は、get 操作の前に、キーに関連付けられた値が無効かどうかを判断します。まずはここにキーを挿入してください。ちょっとしたエピソードですが、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 つは期限切れです。

dict は通常のデータを保存するために使用されます。例えばset key「ははは」を実行すると、このデータがdictに保存されます。

expires は、有効期限に関連付けられたキーを保存するために使用されます。たとえば、上記に基づいて期限切れキー 1 を実行すると、この時点で期限切れとなるレコードが追加されます。

expireIfNeeded の処理を​​振り返ると、おおよそ次のようになります:

expires からキーの有効期限を求め、存在しない場合は、対応するキーが存在しないことを意味します有効期限が設定されており、直接返されます。

スレーブ マシンの場合は、直接返されます。これは、データの一貫性と実装の簡素化を確保するために、Redis がキャッシュの無効化の主導権をマスター マシンに与え、スレーブ マシンにはキャッシュの無効化の主導権が与えられていないためです。キーを無効にする権限。

現在マスター マシンであり、キーの有効期限が切れている場合、マスターは 2 つの重要な作業を行います。 1) 削除コマンドを AOF ファイルに書き込みます。 2) 現在のキーが無効で削除できることをスレーブに通知します。

マスターはローカル辞書からキーの値を削除します。

アクティブ無効化メカニズム

アクティブ無効化メカニズムはアクティブ無効化メカニズムとも呼ばれます。つまり、サーバーは無効なキャッシュを定期的にチェックし、失敗した場合は対応する操作を実行します。 。

Redis がシングルスレッドでイベント駆動であることは誰もが知っています。Redis には EventLoop があります。EventLoop は 2 種類のイベントの処理を担当します:

1 つの種類は IO イベントです。これはイベントのタイプ 基礎となるマルチプレクサから分離されます。

最初のタイプはスケジュールされたイベントで、主に特定のタスクのスケジュールされた実行に使用されます。

Redis の EventLoop 関数は Netty や JavaScript の関数とほぼ似ているようですが、ネットワーク 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 ロジックの実行がトリガーされ、最後にキーの有効期限処理のロジックが実行されますが、activeExpireCycle ロジックはマスターのみが実行できることに注意してください。

redis の詳細については、redis 入門チュートリアル 列に注目してください。

以上がRedis キャッシュ無効化メカニズムの概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。