この記事では、Redis に関する関連知識を提供し、メモリがいっぱいになったときに Redis を最適化する方法に関する関連問題を主に紹介し、削除メカニズム、LRU アルゴリズム、削除の処理についても説明します。 , 皆様のお役に立てれば幸いです。
推奨学習: Redis 学習チュートリアル
Redis メモリ データ セットのサイズが増加した場合一定のサイズに達すると、データ削除戦略が実装されます。
Redis のメモリが不足するとどうなりますか?
キャッシュされたデータの削除メカニズムについて話す
Redis キャッシュの削除戦略とは何ですか?データを削除しない唯一の戦略は、noeviction です。
allkeys-lru、allkeys-random、allkeys-lfu を含むすべてのデータ範囲で削除します。
##volatile-ttl | フィルタリングの際、有効期限が設定されているキーと値のペアは有効期限が早い順に削除されます。 |
---|---|
有効期限が設定されたキーと値のペアをランダムに削除します。 | |
LRU アルゴリズムを使用して、有効期限を指定してキーと値のペアをフィルター処理します | |
LFU アルゴリズムを使用して有効期限が設定されたキーと値のペアを選択する | |
##戦略 |
allkeys-random | すべてのキーと値のペアからデータをランダムに選択して削除します。 |
---|---|
valkeys-lfu | |
#LRU アルゴリズムについて話しますは、最も最近使用されていない原則に従ってデータをフィルタリングすることです。最も頻繁に使用されていないデータは除外されますが、最近頻繁に使用されたデータはキャッシュに残ります。 正確にはどのように審査されますか? LRU はすべてのデータをリンク リストに編成します。リンク リストの先頭と末尾はそれぞれ MRU の端と LRU の端を表し、最も最近使用されたデータと最も最近使用されなかったデータを表します。 問題: LRUアルゴリズムを実際に実装する場合、リンクされたリストを使用してすべてのキャッシュされたデータを管理する必要があり、追加のスペースオーバーヘッドが発生します。さらに、データにアクセスすると、データをリンク リストの MRU に移動する必要があり、大量のデータにアクセスするとリンク リストの移動操作が多数発生し、非常に時間がかかり、Redis キャッシュのパフォーマンスが低下します。 。 解決策: 使用上の推奨事項:
削除されたデータにどう対処するか?削除されたデータが選択されたら、そのデータがクリーン データの場合は直接削除しますが、ダーティ データの場合はデータベースに書き戻す必要があります。 では、データがクリーンかダーティかを判断するにはどうすればよいでしょうか?
削除されたデータがダーティ データであっても、Redis はそれらをデータベースに書き戻しません。したがって、Redis キャッシュを使用する場合、データが変更された場合は、データが変更されたときにデータベースに書き戻す必要があります。そうしないと、ダーティ データが削除されるときに Redis によって削除され、データベースには最新のデータがなくなります。 Redis はどのようにメモリを最適化しますか?1. キーの数を制御する: Redis を使用して大量のデータを保存する場合、通常は多数のキーがあり、キーが多すぎると大量のメモリも消費します。 Redis は本質的にデータ構造サーバーであり、ハッシュ、リスト、セット、zset、その他の構造などのさまざまなデータ構造を提供します。 Redis を使用する際に誤解しないように、get/set などの API を多用し、Redis を Memcached として使用します。同じデータ内容を保存する場合、Redis データ構造を使用して外部キーの数を減らすと、メモリを大幅に節約できます。
3. コーディングの最適化。 Redis は、string、list、hash、set、zet などの外部型を提供しますが、Redis にはさまざまな型のエンコーディングの概念が内部的にあり、いわゆるエンコーディングは、実装に使用される特定の基礎となるデータ構造を指します。エンコーディングの違いは、メモリ使用量とデータの読み取りおよび書き込み効率に直接影響します。
:コレクション型データを使用します :異なるエンコーディングを使用すると、メモリ使用量に明らかな違いがあります :開発のヒント: scan object idletime コマンドを使用すると、長期間アクセスされていないキーをバッチでクエリし、長期間アクセスされていないキーを見つけて、それらをクリーンアップしてメモリを削減できます。使用法。 :オブジェクトが整数で範囲が [0-9999] の場合、Redis は共有オブジェクトを使用してメモリを節約できます。 :開発のヒント: 同時書き込みが多いシナリオでは、条件が許せば文字列の長さを 39 バイト以内に制御することをお勧めします。 redisObject を作成するためのメモリ割り当ての数を減らし、パフォーマンスを向上させます。 #2. キーと値のオブジェクトを減らす
#3. 共有オブジェクト プール
LRU アルゴリズムは、オブジェクト プールを排除するために、オブジェクトの最終アクセス時刻を取得する必要があります。最も長くアクセスされていないデータ。オブジェクトの最終アクセス時刻は、redisObject オブジェクトの lru フィールドに保存されます。オブジェクトの共有とは、複数の参照が同じ redisObject を共有することを意味しますが、このとき lru フィールドも共有されるため、各オブジェクトの最終アクセス時刻を取得することができなくなります。 maxmemory が設定されていない場合、Redis はメモリが使い果たされるまでメモリのリサイクルをトリガーしないため、共有オブジェクト プールは正常に動作できます。 要約すると、共有オブジェクト プールは maxmemory LRU 戦略と競合するため、使用する場合は注意する必要があります。 まず第一に、整数オブジェクト プールは再利用の可能性が最も高くなります。第二に、オブジェクト共有の重要な操作は同等性を判断することです。Redis に整数オブジェクト プールしかない理由は、整数オブジェクト プールの時間計算量が高いためです。整数比較アルゴリズムは O(1) です。オブジェクト プールの無駄を防ぐために、10,000 個の整数のみを保持します。文字列の等しいかどうかを判断する場合、時間計算量は O(n) になり、特に長い文字列の場合、より多くのパフォーマンスが消費されます (浮動小数点数は文字列を使用して Redis の内部に格納されます)。ハッシュ、リストなどのより複雑なデータ構造の場合、同等性の判定には O(n2) が必要です。シングルスレッド Redis の場合、このようなオーバーヘッドは明らかに不当であるため、Redis は整数の共有オブジェクト プールのみを保持します。 4. 文字列の最適化
: 特徴:
: 文字列再構築: ハッシュ タイプに基づく 2 次エンコード方式。 Redis のメモリが不足した場合、最初に考慮すべきことは、水平方向の拡張のためにマシンを追加しないことです。まずメモリの最適化を試みる必要があります。ボトルネックに遭遇した場合は、水平方向の拡張を検討してください。クラスタリング ソリューションの場合でも、クラスタリング後のリソースと管理コストの不必要な浪費を避けるために、垂直レベルの最適化が同様に重要です。 推奨される学習: Redis チュートリアル |
以上がメモリがいっぱいになったときに Redis を最適化する方法の詳細な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。