Redisの期限切れキー削除戦略の原理の説明-Redis-php.cn

Redisの期限切れキー削除戦略の原理の説明

WBOY

リリース： 2022-09-02 20:55:20

転載

2184 人が閲覧しました

この記事では、Redis に関する関連知識を提供します。主に、Redis の期限切れキー削除戦略の原則を紹介します。Redis サーバーは、実際には、遅延削除と定期削除という 2 つの戦略を使用します。これらの戦略を組み合わせることで、サーバーは CPU 時間の合理的な使用とメモリ領域の無駄の回避との間で適切なバランスを実現できます。

Redisの期限切れキー削除戦略の原理の説明

推奨される学習: Redis ビデオチュートリアル

Redis サーバーは実際に 2 つの戦略を使用します: 遅延削除と定期的な削除: 協力によるこれら 2 つの削除戦略により、サーバーは CPU 時間の合理的な使用とメモリ領域の無駄の回避との間で適切なバランスを実現できます。

遅延削除

遅延削除戦略は、CPU 時間に最も優しい方法です。プログラムは、キーが取り出されたときにのみキーの有効期限をチェックするため、削除操作を確実に行うことができます。期限切れのキーは必要なときにのみ実行され、削除対象は現在処理されているキーに限定され、他の関係のない期限切れのキーの削除に CPU 時間を費やすことはありません。

遅延削除戦略の欠点は、メモリに最も優しくないことです。キーの有効期限が切れていて、そのキーがまだデータベースに保持されている場合、期限切れのキーが削除されない限り、メモリは占有されますが、解放されません。

遅延削除戦略を使用する場合、データベース内に期限切れのキーが多数あり、これらの期限切れのキーがたまたまアクセスされなかった場合、(ユーザーが手動で FLUSHDB を実行しない限り) それらのキーは削除されない可能性があります。この状況はメモリリークとみなすこともできます。無駄なガベージデータが大量のメモリを占有していますが、サーバーはそれらを自動的に解放しません。これは、実行ステータスがメモリに大きく依存する Redis サーバーにとって問題です。これは間違いなく問題です。良いニュースではありません。

たとえば、ログなどの一部の時間関連データの場合、特定の時点を過ぎると、それらへのアクセスが大幅に減少するか、アクセスされなくなることさえあります。ユーザーはサーバーがそれらを自動的に削除したと考えていますが、実際にはこれらのキーはまだ存在しており、キーによって占有されていたメモリは解放されていません。結果は非常に深刻になるはずです。

定期的な削除

遅延削除に関する上記の説明から、この削除方法には単独で使用すると明らかな欠陥があります。メモリが多く、メモリリークの危険性があります。定期的な削除戦略は、最初の 2 つの戦略を統合して折衷したものです:

定期的な削除戦略は、期限切れのキーの削除を一定の間隔で実行し、削除操作の期間と頻度を制限することで削除操作を減らします。 CPU時間。さらに、期限切れのキーを定期的に削除することにより、定期的な削除戦略により、期限切れのキーによって引き起こされるメモリの無駄が効果的に削減されます。定期的な削除戦略の難しさは、削除操作の期間と頻度を決定することです。

削除操作の実行頻度が高すぎる場合、または実行時間が長すぎる場合、定期的な削除戦略は劣化してしまいます。期限切れのキーの削除に費やされる CPU 時間が多すぎます。

削除操作の実行時間が少なすぎる場合、または実行時間が短すぎる場合、通常の削除戦略は遅延削除戦略と同じになり、メモリが無駄に消費されます。したがって、定期的な削除戦略を採用する場合、サーバーは状況に応じて削除操作の実行期間と頻度を合理的に設定する必要があります。

遅延削除戦略

期限切れキーの遅延削除戦略は、db.c/expireIfNeeded 関数によって実装されます。データベースを読み書きするすべての Redis コマンドは、expireIfNeeded 関数を呼び出して、実行前の入力キー:

入力キーの有効期限が切れた場合、expireIfNeeded 関数はデータベースから入力キーを削除します。

入力キーの有効期限が切れていない場合、expireIfNeeded 関数はアクションを実行しません。

expireIfNeeded 関数はフィルターのようなもので、コマンドが実際に実行される前に期限切れの入力キーを除外して、コマンドが期限切れのキーに触れないようにすることができます。

さらに、アクセスされた各キーは期限切れにより、expireIfNeeded 関数によって削除される可能性があるため、各コマンドの実装関数は、キーの存在とキーの不在の両方を処理できる必要があります。

キーが存在する場合、キーの有無に応じてコマンドが実行されます。

キーが存在しない場合、または期限切れによりexpireIfNeeded関数によってキーが削除された場合、コマンドはキーが存在しないものとして実行されます。

定期削除戦略の実装

期限切れキーの定期削除戦略は、redis.c/activeExpireCycle 関数によって実装されます。Redis サーバーの定期操作 redis.c/serverCron 関数が実行されるたびに、activeExpireCycle 関数が実行されます。 will 呼び出されると、指定された時間内にサーバー内の各データベースを複数回走査し、データベースの有効期限ディクショナリから一部のキーの有効期限をランダムにチェックし、期限切れのキーを削除します。

プロセス全体は次のように疑似コードで記述できます。

activeExpireCycle 関数の動作モードは次のようになります。概要は次のようになります。

関数が実行されるたびに、検査のために一定数のデータベースから一定数のランダムなキーが抽出され、期限切れのキーが削除されます。

グローバル変数 current_db は、現在の activeExpireCycle 関数チェックの進行状況を記録し、次回 activeExpireCycle 関数が呼び出されたときに、以前の進行状況が処理されます。たとえば、現在の activeExpireCycle 関数がデータベース 10 番を走査したときに戻った場合、次回 activeExpireCycle 関数が実行されると、データベース 11 番から期限切れのキーが検索されて削除されます。

activeExpireCycle 関数の実行が続くと、サーバー内のすべてのデータベースがチェックされます。この時点で、この関数は current_db 変数を 0 にリセットし、新しいラウンドのチェック作業を再度開始します。

サーバーがレプリケーションモードで実行されている場合、スレーブサーバーからの期限切れのキーの削除はマスターサーバーによって制御されます。

マスターサーバーが期限切れのキーを削除した後、キーを押すと、「DEL コマンドをすべてのスレーブサーバーに正式に送信して、期限切れのキーを削除するようにスレーブサーバーに指示します」と表示されます。

#スレーブサーバーがクライアントから送信された読み取りコマンドを実行すると、期限切れのキーが見つかった場合でも、期限切れのキーは削除されず、期限切れのキーを期限切れになっていないキーと同様に処理し続けます

スレーブサーバーは、マスターサーバーから DEL コマンドを受信した後でのみ、期限切れのキーを削除します。

マスターサーバーがスレーブサーバーの有効期限切れキーを一律に削除するように制御することで、マスターサーバーとスレーブサーバーのデータの整合性を確保することができるため、有効期限切れのキーがスレーブサーバーのデータベースに存在する場合、マスターサーバー、スレーブサーバー内のこの期限切れのキーのレプリカも引き続き存在します。たとえば、マスター/スレーブサーバーのペアがあり、図に示すように、それらのデータベースにはすべて同じ 3 つのキー message、xxx、yyy が格納されています。message は期限切れのキーです。

この時点でクライアントがコマンド GET メッセージをスレーブサーバーに送信すると、スレーブサーバーはメッセージキーの有効期限が切れていることを認識しますが、スレーブサーバーはメッセージキーを削除しません。メッセージキー。メッセージキーの有効期限が切れていないかのように、メッセージキーの値をクライアントに返し続けます。