AFAIK, det er ikke muligt at konfigurere Redis til konsekvent at fjerne de ældre data først.
Når *-ttl eller *-lru mulighederne er valgt i maxmemory-policy, bruger Redis ikke en nøjagtig algoritme til at vælge de nøgler, der skal fjernes. En nøjagtig algoritme ville kræve en ekstra liste (for *-lru) eller en ekstra heap (for *-ttl) i hukommelsen og krydsreference den med den normale Redis-ordbogsdatastruktur. Det ville være dyrt i forhold til hukommelsesforbrug.
Med den nuværende mekanisme forekommer udsættelser i hovedbegivenhedsløkken (dvs. potentielle udsættelser kontrolleres ved hver loop-iteration, før hver kommando udføres). Indtil hukommelsen er tilbage under den maksimale hukommelsesgrænse, vælger Redis tilfældigt en prøve på n nøgler og vælger til udløb den mest ledige (for *-lru) eller den, der er tættest på dens udløbsgrænse (for *-ttl). Som standard tages kun 3 prøver i betragtning. Resultatet er ikke-deterministisk.
En måde at øge nøjagtigheden af denne algoritme og afhjælpe problemet er at øge antallet af overvejede samples (maxmemory-samples parameter i konfigurationsfilen). Indstil det ikke for højt, da det vil forbruge noget CPU. Det er en afvejning mellem eviction-nøjagtighed og CPU-forbrug.
Hvis du nu virkelig har brug for en konsekvent adfærd, er en løsning at implementere din egen udsættelsesmekanisme oven på Redis. For eksempel kan du tilføje en liste (for ikke-opdaterbare nøgler) eller et sorteret sæt (for opdaterbare nøgler) for at spore de nøgler, der først skal smides ud. Derefter tilføjer du en dæmon, hvis formål er periodisk at kontrollere (ved hjælp af INFO) hukommelsesforbruget og forespørge elementerne i listen/sorterede sæt for at fjerne de relevante nøgler.
Bemærk venligst, at andre cachesystemer har deres egen måde at håndtere dette problem på. For eksempel med memcached er der én LRU-struktur pr. plade (som afhænger af objektstørrelsen), så udsættelsesrækkefølgen er heller ikke nøjagtig (selvom mere deterministisk end med Redis i praksis).