Политики за изчистване в Redis: Коя да използвате

Вашият Redis кеш се запълва. Това се случва винаги – точно затова съществува ограничение на паметта. Какво се случва в следващата милисекунда се решава от една-единствена настройка, която повечето хора приемат по подразбиране и никога повече не поглеждат.

Политиката за изчистване.

Ако я настроите правилно, Redis защитава най-натоварените ви данни, поддържа висок процент на попадения в кеша и кара сайта ви да се чувства бърз дори при голямо натоварване. Ако сбъркате, Redis може да изчисти полезни ключове или да откаже записвания, в зависимост от политиката. В SPanel политиката е изведена като удобно падащо меню вместо ръчна редакция на redis.conf.

Разликата в производителността е реална – проучване на Deloitte установява, че подобрение от 0.1 секунда в скоростта на мобилния сайт повишава конверсионните нива в ритейл търговията с 8.4%.

Затова нека изясним какво всъщност представлява политиката за изчистване в Redis, да разгледаме всички осем политики на ясен и разбираем език и да стигнем до тази, която най-вероятно трябва да използвате.

Потребителите на SPanel могат да променят политиката за изчистване в Redis директно от екрана Redis Cache, без да редактират файлове. Просто отидете в Redis Cache Manager и отляво ще видите падащото меню Mempolicy.

Какво е политика за изчистване в Redis?

Политиката за изчистване в Redis е правилото, което Redis следва, за да определи кои ключове да изтрие, когато лимитът на паметта е достигнат и е необходима памет за нов запис. Тя отговаря на един прост въпрос: когато кешът е пълен, какво се изхвърля, за да се освободи място?

Преди да се стигне до изчистване, трябва да са изпълнени две условия:

1. Съществува таван на паметта. Redis изчиства само когато достигне стойността на maxmemory. Без зададен лимит Redis ще продължи да консумира RAM, докато операционната система не се намеси – а това вече е проблем от съвсем друг характер.
2. Нов запис се нуждае от място. Изчистването се задейства от нуждата. Redis освобождава място реактивно, ключ по ключ, в момента, в който пристигат нови записи, а паметта вече е запълнена.

Ето частта, която често обърква потребителите.

В чистата open-source версия на Redis по подразбиране е зададена политиката noeviction. Това означава, че Redis не изчиства нищо и започва да отхвърля нови записи, когато паметта се запълни. Това е безопасно подразбиране за база данни, но не е добро за кеш.

Volatile vs. Allkeys: Първото важно разклонение

Преди осемте политики за изчистване в Redis да започнат да придобиват смисъл, трябва да разберете едно ключово разграничение. Всяка политика работи в рамките на един от двата обхвата:

• Allkeys политиките могат да изчистят всеки ключ в кеша, независимо дали има зададено време на изтичане (TTL).
• Volatile политиките могат да изчистят само ключове, които имат TTL (време на живот). Ключовете без TTL са защитени и остават недокоснати.

Този единствен избор – дали всеки ключ е „в играта“, или само тези, които сте маркирали изрично като временни – определя цялата останала логика.

Как SPanel се справя с това по различен начин

В SPanel Redis не е споделена кеш услуга. Всеки хостинг акаунт получава собствена изолирана Redis инстанция с:

• частен loopback адрес
• собствена парола
• собствен бюджет за памет
• собствена политика за изчистване

По подразбиране е зададена allkeys-lfu с лимит от 256 MB памет. Това е отлична отправна точка за повечето WordPress, WooCommerce и application-cache натоварвания. Ако вашето приложение изисква нещо друго, можете да смените политиката директно от формата за настройки на Redis Cache в SPanel – без да се налага да редактирате redis.conf през SSH.

Всички осем политики за изчистване в Redis – обяснени

Redis поддържа осем политики за изчистване. Шест от тях са комбинации между обхват (volatile или allkeys) и стратегия (LRU, LFU или random), плюс две специални: една базирана на TTL и noeviction.

Ето матрицата:

Политика	Обхват	Премахва първо	Най-подходяща за
allkeys-lru	Всеки ключ	Най-малко наскоро достъпен ключ	Общи кешове без зададени TTL-и
allkeys-lfu	Всеки ключ	Най-рядко достъпен ключ	Повечето application caches (препоръчително подразбиране)
allkeys-random	Всеки ключ	Произволен ключ	Униформен достъп без „горещи“ ключове
volatile-lru	Само TTL ключове	Най-малко наскоро достъпен TTL ключ	Смесен кеш + данни, които трябва да останат
volatile-lfu	Само TTL ключове	Най-рядко достъпен TTL ключ	Смесени данни, кеширане по честота
volatile-random	Само TTL ключове	Произволен TTL ключ	Смесени данни, нискорисково изчистване
volatile-ttl	Само TTL ключове	Ключ с най-близко изтичане	Краткотрайни ключове, rate limiters
noeviction	Няма	Нищо (записите връщат грешка)	Постоянни хранилища, никога чист кеш

Политиките LRU (volatile-lru, allkeys-lru)

LRU означава Least Recently Used (Най-малко наскоро използван). Когато паметта се запълни, тези политики изчистват ключа, който не е бил докосван най-дълго време. Предположението е, че най-старите недокоснати данни са най-малко вероятно да са нужни отново.

allkeys-lru прилага това правило върху целия кеш, докато volatile-lru го ограничава само до ключовете с TTL.

LRU е класическият, интуитивен избор и години наред беше единствената „умна“ опция в Redis.

Политиките LFU (volatile-lfu, allkeys-lfu)

LFU означава Least Frequently Used (Най-рядко използван). Това е настройката, която повечето кеш системи искат.

Вместо да пита „Кое е останало недокоснато най-дълго?“, LFU пита „Кое се използва най-рядко?“ и изчиства точно него.

Разликата е съществена. Ключ, който се достъпва хиляди пъти в час, но е бил тих през последните няколко секунди, ще оцелее при LFU. При обикновен LRU същият ключ може да бъде изчистен, ако се появят по-нови записи.

Redis добави поддръжка за LFU във версия 4.0 именно заради това – да защитава истински „горещите“ ключове независимо от момента на последния им достъп.

Случайните политики (volatile-random, allkeys-random)

Както подсказва името – когато паметта е пълна, Redis избира произволен ключ и го изчиства. Няма проследяване, няма оценяване, почти нулев overhead.

Случайното изчистване има смисъл само когато моделът на достъп е наистина униформен – всеки ключ е еднакво вероятно да бъде нужен. На практика това е изключително рядко.

Повечето реални натоварвания имат „горещи“ и „студени“ данни. Политика, базирана на честота или актуалност, почти винаги превъзхожда хвърлянето на монета.

Политиката TTL (volatile-ttl)

volatile-ttl изчиства ключа с най-кратко оставащо време на живот – този, който и без това е най-близо до изтичане.

Тя работи само с ключове, които имат TTL.

Това е отличен избор, когато умишлено задавате изтичане на кеш записите си и предпочитате Redis да изчиства първо тези, които скоро ще умрат сами. Типични примери: rate limiters, краткотрайни токени, time-boxed кеш записи.

Noeviction

noeviction отказва да изчисти каквото и да било.

Когато паметта се запълни, Redis спира да приема нови записи, които изискват допълнителна памет, и връща грешка out-of-memory. Четенията продължават да работят нормално.

Това звучи като лоша идея за кеш – и наистина е. 

Но е правилният избор, когато използвате Redis като store of record за данни, които не могат просто да бъдат регенерирани (например постоянен брояч или опашка от задачи).

В такъв случай мълчаливото изтриване на ключ е по-лошо от отхвърлянето на запис. Уверете се обаче, че приложението ви прихваща и обработва тази грешка грациозно.

Важна бележка за SPanel: SPanel Redis Cache е проектиран предимно като бърз, изолиран кеш за хостинг акаунт. Това е single-node Redis инстанция на същия сървър като сайта. SPanel не предлага Redis clustering, реплики, high availability или AOF persistence през интерфейса. Ако използвате Redis за опашки, броячи или други данни, които не могат лесно да бъдат възстановени, уверете се, че приложението ви може да толерира ограниченията на single-node Redis и правилно обработва грешките при noeviction.

Allkeys-lfu vs. Allkeys-lru: Коя да изберете?

За типичен application cache allkeys-lfu е по-добрият избор. Той запазва най-често използваните данни въз основа на честотата на достъп, а не само на това колко скоро са били докоснати.

allkeys-lru остава безопасен и добре познат fallback, който се представя почти толкова добре и е по-лесен за умствено моделиране.

Разликата се свежда до една дума:

• allkeys-lru защитава ключовете, докоснати най-скоро. Ключ, който е бил интензивно използван цял ден, но е бил в покой само десет секунди, може да бъде изчистен, ако нови ключове го изместят.
• allkeys-lfu защитава ключовете, докосвани най-често. Същият горещ ключ оцелява, защото Redis проследява честотата на достъп във времето, а не само timestamp-а на последния му докосване.

За кеширане на повторни заявки към базата данни на WordPress сайт, за ecommerce каталог или всяко натоварване с ясен набор от популярни елементи – честотата е по-добрият сигнал. Затова базираното на честота изчистване печели за повечето application caches.

Честно предупреждение: И LRU, и LFU в Redis са приблизителни. Redis не сканира целия keyspace при всяко изчистване – той взема проба от няколко ключа. Това е компромис между прецизност и скорост. Можете да настроите размера на пробата, но подразбираните стойности са напълно достатъчни за огромното мнозинство сайтове.

Как да изберете правилната политика за изчистване

Кратката версия?

Ако управлявате нормален кеш и не сте сигурни – използвайте allkeys-lfu и продължете нататък. Това е разумното подразбиране с причина. Обърнете се към друга политика само когато вашето конкретно натоварване ви дава основателна причина за това.

Ето проста логическа схема, с която ще стигнете до правилния избор с три въпроса:

1. Redis чисто кеш ли е?
   Ако данните живеят някъде другаде и могат да бъдат възстановени (база данни, API, приложна логика) – тогава всеки ключ е безопасен за изчистване. Преминете към стъпка 2.
   Ако не – използвате Redis като datastore. Преминете към стъпка 3.
2. Всички ли кеширани ключове имат TTL?
   Ако сте задали изтичане на всички ключове и искате изчистването да е ограничено само до тях – използвайте volatile-lru или volatile-ttl.
   Ако ключовете са смесени или изобщо нямате TTL – отговорът е allkeys-lfu.
3. Има ли данни, които задължително** трябва да се запазят?**
   Ако да – използвайте volatile-lru, за да изчиствате само кеш ключовете с TTL, а важните данни да останат защитени.
   Ако абсолютно нищо не може да бъде изтрито – единственият безопасен избор е noeviction. Уверете се, че кодът ви обработва грешките при запис.

Едно число ви казва дали изборът ви работи: броят на изчистените ключове (evicted keys). Ако Redis изчиства активно, докато hit rate-ът ви спада – кешът вероятно е с недостатъчен размер, а не неправилно конфигуриран. Решението е повече памет, а не смяна на политика.

И двете метрики (hit rate и evicted keys) са налични в статистиката на самия Redis – всеки добър control panel ги показва.

Как да наблюдавате работата на политиката си в SPanel

Добрата политика за изчистване е невидима, когато работи правилно. Затова начинът да я валидирате е чрез числата.

Отворете Redis stats изгледа във вашия SPanel акаунт и наблюдавайте две ключови метрики:

• Hit rate – колко често заявките се обслужват директно от кеша
• Evicted keys – колко ключа Redis е изхвърлил, за да освободи място

Ако изчистванията растат, а hit rate-ът спада – увеличете лимита на паметта от същия екран, вместо да сменяте политиката.

Ако искате да видите в реално време точно кои ключове приложението ви чете и записва – използвайте инструмента Monitor. Той показва всяка Redis команда за зададен от вас период.

След deploy на нов код, който променя структурата на кеш ключовете, използвайте Flush Cache, за да изчистите инстанцията и приложението да я възстанови коректно.

Всичко това са self-service контроли – без да се налага да отваряте support ticket.

Как да зададете политиката за изчистване в Redis по лесния начин

На повечето платформи смяната на eviction policy изисква:

• SSH достъп до сървъра
• Ръчна редакция на redis.conf
• Точно задаване на реда maxmemory-policy
• Внимателен рестарт на услугата

За човек, който не е разработчик и управлява натоварен онлайн магазин, това често означава support ticket и доста нерви.

В SPanel не е необходимо да е така.

На всеки менажиран VPS план на NS1 Redis е включен по подразбиране (без допълнителна такса и без premium tier). Политиката за изчистване е красиво оформено падащо меню в Redis Cache Manager – инструмента за Redis вътре в SPanel.

Избирате политика → Запазвате → SPanel автоматично прилага промяната и рестартира Redis услугата вместо вас. Няма нужда от редакция на конфигурационни файлове или ръчен рестарт.

При типичен self-managed сървър трябва да редактирате redis.conf, да зададете maxmemory-policy и внимателно да рестартирате. В SPanel всичко става от един формуляр.

Няколко важни решения вече са взети вместо вас:

• При всеки нов deploy получавате работещ Redis с 256 MB памет и allkeys-lfu като подразбираща се политика – правилната отправна точка за огромното мнозинство сайтове.
• Кешът не е споделен. Всеки акаунт има собствена изолирана Redis инстанция на частен адрес със собствена парола. Така клиент с „runaway“ скрипт не може да засегне вашия кеш или да чете вашите данни.
• Кешът работи на същата машина като сайта ви – latency-то е минимално, на скоростта на локалната мрежа. Това е точно това, което прави кеширането ефективно при пикови натоварвания (WooCommerce разпродажби, високотрафични WordPress сайтове).

Това е вид self-service контрол, който всеки developer-friendly хостинг трябва да предлага по подразбиране – на инфраструктура, която вече захранва над 700 000 уебсайта в повече от 120 държави.

Заключение

Политиката за изчистване е една от онези настройки, които не ви струват нищо, ако я настроите правилно, и тихо ви „изяждат“ от производителността, когато е грешна.

За почти всеки сайт отговорът е allkeys-lfu – запазвайте това, което се използва най-много, изхвърляйте това, което е изстинало, и следете hit rate-а си.

Изберете друга политика само когато вашите данни и натоварване ви казват ясно да го направите.

Ако предпочитате да управлявате тази настройка от удобно падащо меню вместо от конфигурационен файл – и искате Redis да е включен, изолиран и разумно настроен още от първия ден – напълно управляваната среда на ScalaHosting сваля цялото администриране на сървъра от раменете ви.

Често задавани въпроси

В: Каква е подразбиращата се политика за изчистване в Redis?

О: Open-source Redis по подразбиране използва noeviction – не изчиства нищо и отхвърля нови записи, когато паметта се запълни.

Тъй като това поведение е по-подходящо за datastore, отколкото за кеш, управляваните среди обикновено го презаписват. При SPanel свежо разгърнатият Redis използва allkeys-lfu – по-доброто подразбиране за application caching.

В: Какво се случва, когато Redis остане без памет?

О: Redis прилага политиката за изчистване, която сте конфигурирали.

При политика като allkeys-lfu той изчиства най-малко ценните ключове и продължава да обслужва заявките нормално.

При noeviction спира да приема записи, които изискват повече памет, и връща out-of-memory грешка (четенията продължават да работят).

В: По-добър ли е LFU от LRU за кеширане?

О: За повечето application caches – да.

LFU (Least Frequently Used) запазва ключовете, до които приложението ви се обръща най-често. Това защитава истински „горещите“ данни по-добре от LRU (Least Recently Used), който следи само колко скоро е бил докоснат даден ключ.

LRU остава солиден и по-прост избор, който се представя много добре в редица реални сценарии.

В: Кога не трябва да използвате allkeys-lfu?

О: Не използвайте allkeys-lfu, ако в Redis се съхраняват данни, които не могат да бъдат възстановени.

Ако някои ключове никога не трябва да бъдат изчистени – използвайте volatile политика и задавайте TTL само на кеш ключовете, които могат да се изтрият.

Ако нито един ключ не може да бъде изтрит – използвайте noeviction и се уверете, че приложението ви обработва грешките при запис.

В: Кога да използвам noeviction?

О: Използвайте noeviction само когато третирате Redis като store of record, а не като кеш – за данни, които не могат да бъдат регенерирани, ако бъдат изтрити (например постоянен брояч или опашка от задачи).

За всичко, което е истински кеш, noeviction е грешен избор – отхвърлянето на записи е по-лошо от изчистването на остарели ключове. Приложението ви задължително трябва да може да обработва out-of-memory грешките.

В: Нужно ли е да променям политиката за изчистване сам?

О: Обикновено – не.

allkeys-lfu е правилната отправна точка за голямото мнозинство кеш натоварвания и в SPanel е зададена автоматично при deploy. Променяйте я само ако имате конкретна нужда – например смесвате кеш данни с данни, които трябва да се запазят, или сте задали TTL на абсолютно всички ключове и искате изчистването да е ограничено само до тях.

В: Мога ли да променя политиката за изчистване без да редактирам конфигурационни файлове?

О: Да – на платформи, които я показват в контролния панел.

В Redis Cache Manager на ScalaHosting SPanel са налични всички осем политики в удобно падащо меню. Избирате една, запазвате и SPanel автоматично я прилага към работещата Redis инстанция и рестартира услугата. Няма нужда от редакция на redis.conf или команден ред.