Redis Cache Eviction

Generelt er en hurtigbuffer en programvare eller maskinvarekomponent som inneholder data fra tidligere klientforespørsler, slik at data kan hentes og serveres raskere for forespørslene fremsatt i fremtiden. I de fleste tilfeller er ikke backend -systemene så raskt som du vil at de skal være. Cachen sitter mellom backend -databaselaget og klientapplikasjonen, og gir hurtig datainnhenting og en rask responstid.

Når de forespurte dataene er tilgjengelige i Redis -cachen, kan dataene direkte serveres fra Redis -cachen uten å omdirigere forespørselen til den primære databasen, som kalles en hurtigbuffer. På den annen side, hvis dataene ikke er tilgjengelige i Redis Cache, må forespørselen nå den originale backend -databasen for å hente dataene som vanlig, noe som er en cache -glipp, men påfølgende forespørsler vil tjene fra cachen.

Med denne typen oppførsel er Redis Caching et utmerket valg for mange brukssaker.

• Maskinlæring slutninger
• Fulltekstsøk
• Kompleks relasjonsdatabasespørsmål
• Tredjeparts API-resultater

Redis Caches bringer søknaden din flere fordeler mens du introduserer en stor utfordring, som kalles cache -staleness. På et tidspunkt kan hurtigbufferen din være full av foreldede data som ikke engang er gyldig for i dag. Derfor bør det være en mekanisme for å kaste ut de gamle eller ugyldige dataene når du fortsetter å bruke Redis -cachen din med nye data.

Redis Cache Eviction

Da Redis Cache først ble introdusert, brukte utviklerne TTL (tid-til-levende) verdi for hver nøkkel for å opprettholde en relativt konstant mengde minne ved å matche hastigheten på data som går inn og ut av systemet. Dette var mye manuelt arbeid for utviklere, noe som Redis -serveren skulle håndtere.

Så den ideelle tilnærmingen bør være å automatisk utvise de gamle dataene ettersom den maksimale cache -minnegrensen er nådd, som også er prosessen etterfulgt av det memcached -systemet. Redis bruker det spesielle MaxMemory Direktiv for å varsle om at den maksimale minnegrensen er nådd.

MaxMemory Konfigurasjonsdirektiv

Redis bruker MaxMemory -konfigurasjonsdirektivet for å identifisere det maksimale tilgjengelige minnet for at hurtigbufferen skal fungere på. Det er to måter du kan angi MaxMemory -direktivverdien.

• Bruke Redis.Conf -fil
• Konfigurasjonssett kommando ved runtime

Følgende er et eksempel på en redis.Conf -fil som viser hvordan du kan spesifisere det maksimale cache -minnet for datasettet. I dette tilfellet er MaxMemory -direktivet satt til 1000 byte.

Tilsvarende kan Redis Config Set -kommandoen brukes til å angi MaxMemory -direktivet ved kjøretid, som vist i det følgende.

Config Set MaxMemory 100

Videre, hvis du angir MaxMemory -direktivverdien til 0, betyr det at det ikke er spesifisert noen minnegrense for Redis -cachen. I de fleste 64-biters systemer er denne verdien satt til 0. 32-biters systemet bruker 3 GB maksimal minnegrense implisitt.

Når Redis -cachen treffer minneverdien som er spesifisert av MaxMemory -direktivet, begynner den å fjerne nøkler i henhold til den valgte utkastelsespolitikken. Hvis ingen nøkkel oppfyller policy -kriteriene, vil ingenting bli kastet ut. I stedet vil Redis-serveren svare med feil på kommandoer som LPush og sett som bruker mer minne og svarer bare på skrivebeskyttede kommandoer som Get.

I det følgende avsnittet vil vi diskutere Redis Eviction Policies og hvordan de bestemmer hvilke nøkler som skal kastes ut eller ikke.

Utkastelsespolitikk

En utkastelsespolitikk bestemmer oppførselen til Redis -cachen når MaxMemory -verdien er nådd. Redis vil fjerne alle nøklene som oppfyller de gitte politiske kriteriene på et gitt tidspunkt. Derfor er det viktig å sørge for at du har en stor nok database til å beholde de ønskede nøklene. Følgende seksjoner beskriver de forskjellige Redis Eviction -retningslinjene som er tilgjengelige for bruk.

Flere utkastelsespolitikker er tilgjengelig for bruk, og Noeviction er en av de mest brukte hvis du ikke vil fjerne noen gamle nøkler når den maksimale minnegrensen er nådd. Imidlertid vil det kaste feil på alle Redis skriveoperasjoner for å varsle brukeren om at hurtigbufferen er full og frigjør litt plass. Kort sagt, dataene vil ikke bli lagret i hurtigbufferen før du frigjør litt plass manuelt.

I flyktig-ttl Policy, Redis tar prøver av nøkler hvis utløpsfelt er satt til True og utviser de med den minste TTL -verdien. Hvis det ikke er noen nøkler med det utløpende feltet satt til True, skjer det ingen utkastelse, noe som ligner på Noeviction Politikk.

Dette er en annen versjon av den flyktige TTL-policyen der Redis tilfeldig fjerner nøkler hvis utløpsfelt er satt til True. Igjen vurderer den bare nøklene som har en TTL -verdi, men ikke hele nøkkelplassen.

Dette ligner mer på flyktig random policy, men med Allkeys-Random Politikk, hele nøkkelplassen vil bli vurdert, ikke bare nøklene med en TTL -verdi. I dette tilfellet vil Redis kaste ut nøkler tilfeldig for å legge til nye data.

Begge de ovennevnte retningslinjene bruker en tilfeldig algoritme for å kaste ut nøkler fra hurtigbufferen, noe som er ganske risikabelt og er kanskje ikke den optimale måten å gjøre nøkkelutkastelsen. Så Redis introduserte en mer optimal måte å gjøre dette med det nye LRU (minst nylig brukt) algoritme.

LRU (minst nylig brukt) algoritmen

LRU -algoritmen er basert på antagelsen om at hvis en gitt nøkkel har blitt åpnet nylig, er det større sannsynlighet for å få tilgang til den igjen i nær fremtid. På den annen side, hvis vi ikke har brukt en gitt nøkkel på lang tid, er det større sjanse for at nøkkelen ikke blir brukt snart eller noen gang igjen. Med den antagelsen prøver LRU -algoritmen å kaste ut de minst nylig brukte nøklene fra Redis Cache, som er en mer optimal tilnærming enn de tilfeldige nøkkelutkastelsesalgoritmene.

For å implementere denne policyen bruker Redis -objektet en ny LRU Felt med 24 biter tilordnet, noe som holder oversikt over når nøkkelen sist ble brukt. Med LRU -algoritmen på plass, tar den et spesifisert antall tilfeldige nøkler og utkast den med høyest tomgangstid eller eldste tilgangstid. MaxMemory-Sampples-direktivet brukes til å spesifisere antall taster per prøve. Dette kan settes ved hjelp av Config Set -kommandoen, som vist i det følgende.

Config Set MaxMemory-Sampples 5

Det er viktig å huske på at Redis kjører en tilnærming av LRU -algoritmen for å holde ting enkelt og lagre databehandlingsressurser som CPU og minne.

Det er to smaker av LRU Eviction Policy.

De minst nylig brukte nøklene med utløpsfeltet som er satt til True, vil bli fjernet. Tastene som ikke er assosiert med en TTL -verdi, vil ikke bli kastet ut under denne policyen fordi utvalget bare tas fra nøklene hvis utløpsfelt er satt til True.

Alle nøklene med høyeste tomgangstid vil bli fjernet. I dette tilfellet vil Redis beholde de sist brukte nøklene.

LFU (minst ofte brukt) algoritme

Redis introduserte den nye LFU (minst ofte brukt) algoritmen i versjon 4.0 for å identifisere sjelden brukte nøkler og fjerne dem fra hurtigbufferen når den maksimale minnegrensen er nådd. Med LFU -policyen vil nøkler som er tilgjengelig for ofte gjenstår.

Tastene med utløpsfeltene satt til True og de som er minst ofte brukt blant den valgte prøven, vil bli kastet ut.

Den søker i hele nøkkelplassen etter sjelden brukte nøkler og sletter dem mens de holder de ofte brukte nøklene.

Konklusjon

For å konkludere, bruker Redis MaxMemory -direktivet for å spesifisere den maksimale minnegrensen for Redis -cachen. Som diskutert, når hurtigbufferen når sin maksimale minnegrense, vil den konfigurerte utkastelsespolitikken skyte og fjerne tastene. Redis bruker tilnærmingene til LRU- og LFU -algoritmene for å finne de beste kandidatene for utkastelse.