AFAIK, не е възможно да се конфигурира Redis да изважда първо по-старите данни.
Когато опциите *-ttl или *-lru са избрани в maxmemory-policy, Redis не използва точен алгоритъм, за да избере ключовете, които да бъдат премахнати. Точният алгоритъм ще изисква допълнителен списък (за *-lru) или допълнителна купчина (за *-ttl) в паметта и ще го направи кръстосана препратка с нормалната структура от данни на речника Redis. Би било скъпо по отношение на консумацията на памет.
С текущия механизъм изгонванията се случват в основния цикъл на събития (т.е. потенциалните изгонвания се проверяват при всяка итерация на цикъла, преди всяка команда да бъде изпълнена). Докато паметта се върне под ограничението за максимална памет, Redis избира произволно извадка от n ключа и избира за изтичане най-неактивния (за *-lru) или този, който е най-близо до границата на изтичане (за *-ttl). По подразбиране се разглеждат само 3 проби. Резултатът е недетерминиран.
Един от начините да увеличите точността на този алгоритъм и да смекчите проблема е да увеличите броя на разглежданите проби (параметър maxmemory-samples в конфигурационния файл). Не го настройвайте твърде високо, тъй като това ще изразходва малко процесор. Това е компромис между точността на изгонване и консумацията на процесора.
Сега, ако наистина се нуждаете от последователно поведение, едно от решенията е да приложите свой собствен механизъм за изгонване върху Redis. Например, можете да добавите списък (за неподлежащи на актуализиране ключове) или сортиран набор (за ключове с възможност за актуализиране), за да проследите ключовете, които трябва да бъдат изгонени първи. След това добавяте демон, чиято цел е периодично да проверява (използвайки INFO) консумацията на памет и да прави заявка за елементите от списъка/сортирания набор, за да премахне съответните ключове.
Моля, имайте предвид, че други системи за кеширане имат свой собствен начин за справяне с този проблем. Например с memcached има една LRU структура на плоча (която зависи от размера на обекта), така че редът за изгонване също не е точен (макар и по-детерминистичен, отколкото при Redis на практика).
