ちなみに、最初に古いデータを一貫して削除するようにRedisを構成することはできません。
maxmemory-policyで*-ttlまたは*-lruオプションが選択されている場合、Redisは削除するキーを選択するために正確なアルゴリズムを使用しません。正確なアルゴリズムでは、メモリ内に追加のリスト（* -lruの場合）または追加のヒープ（* -ttlの場合）が必要であり、通常のRedisディクショナリデータ構造と相互参照します。メモリ消費の点でコストがかかります。
現在のメカニズムでは、エビクションはメインイベントループで発生します（つまり、各コマンドが実行される前に、ループの反復ごとに潜在的なエビクションがチェックされます）。メモリがmaxmemory制限を下回るまで、Redisはn個のキーのサンプルをランダムに選択し、最もアイドル状態のキー（* -lruの場合）または有効期限に最も近いキー（* -ttlの場合）を有効期限として選択します。デフォルトでは、3つのサンプルのみが考慮されます。結果は非決定論的です。
このアルゴリズムの精度を高めて問題を軽減する1つの方法は、考慮されるサンプルの数を増やすことです（構成ファイルのmaxmemory-samplesパラメーター）。CPUを消費するため、高く設定しすぎないでください。これは、エビクションの精度とCPU消費量の間のトレードオフです。
一貫した動作が本当に必要な場合、1つの解決策は、Redisの上に独自の排除メカニズムを実装することです。たとえば、最初に削除する必要のあるキーを追跡するために、リスト（更新不可能なキーの場合）またはソートされたセット（更新可能なキーの場合）を追加できます。次に、（INFOを使用して）定期的にメモリ消費量をチェックし、リスト/ソートされたセットの項目を照会して関連するキーを削除することを目的としたデーモンを追加します。
他のキャッシングシステムには、この問題に対処する独自の方法があることに注意してください。たとえば、memcachedの場合、スラブごとに1つのLRU構造があり（オブジェクトサイズによって異なります）、エビクションの順序も正確ではありません（ただし、実際のRedisよりも決定論的です）。