Redis でキャッシュ クリーニング ポリシーを構成する場所

Redis をキャッシュとして使用する場合、メモリ領域がいっぱいになると、古いデータが自動的に削除されます。 Memcached はデフォルトでこのように動作し、ほとんどの開発者はこれに精通しています。 (推奨学習: Redis ビデオ チュートリアル )

LRU は、Redis でサポートされる唯一のリサイクル アルゴリズムです。この記事では、最大メモリ使用量を制限するために使用される maxmemory 命令について詳しく紹介し、詳しく説明しますRedis が使用するもの 近似 LRU アルゴリズム。

maxmemory 構成ディレクティブ

maxmemory は、Redis が使用できる最大メモリを指定するために使用されます。これは、redis.conf ファイルで設定することも、CONFIG SET コマンドを使用して操作中に動的に変更することもできます。

たとえば、メモリ制限を 100MB に設定するには、redis.conf ファイルで次のように設定できます。

maxmemory 100mb

maxmemory を 0 に設定します。これは、メモリ制限がないことを意味します。 。もちろん、32 ビット システムには、最大 3 GB の RAM という暗黙の制限があります。

メモリ使用量が上限に達したとき、新しいデータを保存する必要がある場合、構成されたポリシーに応じて、Redis はエラー メッセージを直接返すか、古いデータの一部を削除することがあります。

エビクション ポリシー

最大メモリ制限 (maxmemory) に達すると、Redis は maxmemory-policy で構成されたポリシーに基づいて特定の動作を決定します。

現在のバージョンでは、Redis 3.0 でサポートされている戦略は次のとおりです:

noeviction: 戦略を削除しないでください。最大メモリ制限に達した場合、より多くのメモリが必要な場合は、直接エラー メッセージを返します。ほとんどの書き込みコマンドでは、より多くのメモリが占​​有されます (DEL などのまれな例外はあります)。

allkeys-lru: すべてのキーに共通; 最も最近使用されていない (LRU) キーを最初に削除します。

volatile-lru: 有効期限が設定されている部分のみ。最初に最も最近使用されていない (LRU) キーを削除します。

allkeys-random: すべてのキーに共通; いくつかのキーをランダムに削除します。

volatile-random:expireが設定されている部分のみ、キーの一部をランダムに削除します。

volatile-ttl: 有効期限が設定されている部分に限定され、残り時間 (有効期間、TTL) が短いキーから削除されます。

期限切れキーが設定されておらず、前提条件が満たされていない場合、volatile-lru、volatile-random、および volatile-ttl 戦略の動作は、基本的に noeviction (削除なし) と同じになります。

システムの特性に基づいて、適切なエビクション戦略を選択する必要があります。もちろん、運用中にコマンドを使用してエビクション ポリシーを動的に設定したり、チューニングのために INFO コマンドを使用してキャッシュ ミスとヒットを監視したりすることもできます。

一般的に言えば:

ホット データとコールド データに分割されている場合は、allkeys-lru 戦略を使用することをお勧めします。つまり、一部のキーは頻繁に読み書きされるため、特定のビジネス特性がよくわからない場合は、allkeys-lru が適しています。

ループ内のすべてのキーの読み取りと書き込みが必要な場合、または各キーのアクセス頻度が類似している場合は、allkeys-random 戦略を使用できます。つまり、すべての要素の読み取りと書き込みの確率は次のとおりです。ほぼ同じ。

Redis で TTL に基づいて削除する必要があるキーをフィルタリングする場合は、volatile-ttl 戦略を使用してください。

volatile-lru および volatile-random 戦略の主なアプリケーション シナリオは次のとおりです: キャッシュと永続キーの両方を持つインスタンス。一般に、このようなシナリオでは、2 つの別個の Redis インスタンスを使用する必要があります。

期限切れを設定すると追加のメモリが消費されるため、allkeys-lru 戦略を使用すると、有効期限を設定する必要がなくなるため、メモリをより効率的に使用できることに注意してください。

エビクションの内部実装

エビクション プロセスは次のように理解できます:

クライアントがコマンドを実行し、その結果、 Redis ではデータが増加し、より多くのメモリを消費します。

Redis はメモリ使用量をチェックし、maxmemory 制限を超えた場合、ポリシーに従って一部のキーがクリアされます。

次のコマンドの実行を続けます。

このプロセス中、メモリ使用量は継続的に制限値に達し、その後制限値を超え、いくつかのキーが削除されると、使用量は再び制限値を下回ります。

特定のコマンドによって大量のメモリ使用量が発生する場合 (新しいキーを使用して大規模なセットを保存する場合など)、メモリ使用量が一定期間 maxmemory 制限を大幅に超える可能性があります。

おおよその LRU アルゴリズム

Redis は完全な LRU アルゴリズムを使用しません。自動的に追い出される鍵は必ずしも LRU の特性を最もよく満たすものではなく、近似 LRU アルゴリズムによって少数の鍵サンプルが抽出され、アクセス時間が最も古い鍵が削除されます。

エビクション アルゴリズムは、Redis 3.0 以降、候補としてプールを使用することで大幅に最適化されており、これによりアルゴリズムの効率が大幅に向上し、実際の LRU アルゴリズムに近づきました。

Redis LRU アルゴリズムでは、サンプル数を設定することでアルゴリズムの精度を調整できます。次の手順に従って設定します:

maxmemory-samples 5

完全な LRU 実装を使用しない理由は、メモリを節約するためです。ただし、Redis の動作は基本的に LRU と同等であり、以下は Redis LRU と完全な LRU アルゴリズムの動作比較図です。

テスト中は最初のキーからアクセスが開始されるため、最初のキーが最適なエビクション オブジェクトになります。

この図からは、3 つの異なるストリップを形成する 3 種類の点が確認できます。

薄い灰色の部分は、排除されたオブジェクトを示します。

灰色の部分は、「排除されていない」オブジェクトを示します。

緑色の部分は後から追加されたオブジェクトを示します。

純粋な LRU アルゴリズムの実装では、古いキーの前半が解放されます。 Redis の LRU アルゴリズムは、確率的に長いキーのみを解放します。

ご覧のとおり、Redis 3.0 では、5 つのサンプルの効果が Redis 2.8 の効果よりもはるかに優れています。もちろん、Redis 2.8 も優れており、最後にアクセスしたキーは基本的にメモリ内に残りますが、Redis 3.0 で 10 個のサンプルを使用すると、純粋な LRU アルゴリズムに非常に近くなります。

LRU は、特定のキーが今後もアクセスされる可能性を予測するために使用される確率モデルにすぎないことに注意してください。また、データ アクセス状況がべき乗則分布 (べき乗則) に従う場合、ほとんどのリクエストでは、LRU は適切にパフォーマンスを発揮します。

シミュレーションでは、べき乗則アクセスを使用すると、純粋な LRU と Redis の結果が大きく異なるか、目に見えないことさえあることがわかりました。

もちろん、追加の CPU を消費してサンプル数を 10 に増やすこともできます。これにより、結果が実際の LRU に近くなり、キャッシュ ミス統計を通じて違いを判断できます。 。

サンプル サイズの設定は簡単で、CONFIG SET maxmemory-samples コマンドを使用するだけです。

Redis 関連の技術記事の詳細については、Redis Getting Started をご覧ください。チュートリアル コラム 勉強しましょう！

以上がRedis でキャッシュ クリーニング ポリシーを構成する場所の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。