Korrekt brug af Redis Lua-scripts til atomare operationer

Kategorisering af atomare Redis Lua-scripts

Redis Lua-scripts udfører faglig datalogik direkte på Redis-serveren. Mens et script kører, behandler Redis ingen andre serveraktiviteter; de indeholdte kommandoer er derfor isoleret fra andre klienter. På den måde kan flere enkle kommandoer kombineres til en atomoperation at kombinere, f.eks. en grænsekontrol efterfulgt af en opdatering af tælleren eller en debitering, der kun finder sted, hvis der er tilstrækkelig saldo.

Uden et script kan en klient først læse en tæller med GET, kontrollere grænsen i applikationskoden og derefter sende INCR. Mellem disse trin kan en anden klient imidlertid ændre den samme tæller. Et script læser, kontrollerer og øger derimod uden denne observerbare mellemtilstand. Det løser race-betingelsen i den sammensatte regel, men løser ikke automatisk spørgsmål som passende grænseværdier, afviklingstider eller returformater.

Atomisk og isoleret betyder ikke, at Redis Lua-scripts Databasetransaktioner med automatisk rollback. Hvis der opstår en kørselsfejl efter en allerede gennemført skriveoperation, bliver tidligere ændringer ikke automatisk fortrydt. Derfor bør scripts kontrollere indtastninger, datatyper og forretningsmæssige forudsætninger, inden den første skrivning foretages; fejlhåndtering efter ændringer kræver en bevidst udformet strategi.

Typiske regler er: kun at tillade adgang inden for en bestemt grænse eller kun at reducere en beholdning, hvis mængden er tilstrækkelig. Kontroller først, om en eksisterende enkelt Redis-kommando allerede udtrykker hele reglen. Et script giver mening, når flere Redis-operationer, inklusive deres betingelser, skal fungere sammen på en atomar måde.

Et Lua-mønster til »sammenlign og slet« sammenligner den gemte værdi med et overført ejerskabstoken og sletter kun, hvis de er ens. På den måde kan en forsinket proces ikke slette en nøgle, der i mellemtiden er blevet tildelt en ny værdi, alene på grund af sit gamle token.

Dette sammenligningsmønster beskriver udelukkende den sikre rækkefølge for en enkelt Redis-nøgle. Det løser ikke de mere vidtrækkende spørgsmål om distribuerede låse, såsom passende lease-varigheder, procespauser, nedbrud eller koordinering af flere Redis-instanser. Atomiteten af en kommando eller et script omfatter desuden kun de involverede Redis-data, ikke betaling, database, e-mail eller eksterne API'er.

Lua-sandbox og klare grænser

Redis Open Source integrerer Lua 5.1 til scripts. Dette kørselsmiljø kan ikke sidestilles med en lokalt installeret eller den aktuelle hovedversion af Lua: Det er Redis, der bestemmer det tilgængelige sprogomfang og sikkerhedsreglerne. Hvis man udvikler Redis Lua-scripts, bør man derfor teste dem mod den Redis-version, der rent faktisk anvendes, og ikke forudsætte egenskaber fra et vilkårligt eksternt Lua-miljø.

Udførelsen sker i en Sandkasse med bevidst snævre begrænsninger. Et script skal behandle Redis-data og overførte argumenter, men må hverken benytte filsystemet, netværket eller operativsystemtjenester. Eksterne HTTP-anmodninger, afsendelse af beskeder eller adgang til lokale filer hører derfor hjemme i applikationskoden eller i en tjeneste, der er beregnet til dette formål, og ikke i cache-scripting.

Redis tilbyder KEYS og ARGV som globale variabler. Til egne mellemværdier og hjælpefunktioner skal du derimod bruge lokale variabler med local. På den måde kan man se, hvilke værdier der kun gælder for netop dette kald, og scriptlogikken skaber ingen unødvendige afhængigheder. Redis-kommandoer kalder du målrettet via redis.call eller redis.pcall på.

Sandboxen er ikke en erstatning for kapacitetsplanlægning. Under normal kørsel blokerer et script andre klienter på serveren, og derfor er lange sløjfer, ubegrænsede datamængder og beregningskrævende analyser uegnede. Begræns arbejdet til få, på forhånd kendte nøgler og små beregninger. Omfattende analyser, SCAN-baserede samlede beholdninger eller kommunikation med eksterne systemer ville øge driftsrisiciene uden at udvide atomariteten på en meningsfuld måde.

At forstå EVAL, KEYS og ARGV

Når man direkte kalder et script, bruger man følgende form EVAL script numkeys [key …] [arg …]. Ifølge kildekoden angiver `numkeys`, hvor mange af de efterfølgende parametre der er nøgler. Scriptet henter dem via KEYS med indeksering fra 1; alle øvrige værdier findes i ARGV. Denne opdeling er afgørende: Nøgler beskriver Redis-dataene, mens argumenter beskriver de faglige indtastninger såsom grænseværdi, beløb eller forventet token.

Et grænseskript modtager for eksempel tælleren som KEYS[1] og den maksimale værdi som ARGV[1]. Det læser den aktuelle værdi og omregner grænseværdien med tonumber(ARGV[1]) omregner den til et tal og sammenligner de to værdier, før den øges. Omregningen gør den tilsigtede numeriske regleregel eksplicit, i stedet for at stole på en implicit behandling af argumentværdier. Mangler der en tæller, kan scriptet målrettet behandle den indlæste værdi som nul.

Hver nøgle, som scriptet læser eller skriver, skal på forhånd angives som et nøgleargument. Det er ikke en pålidelig fremgangsmåde at sammensætte nøglenavne i scriptet ud fra præfikser eller udlede dem fra gemte data. Redis kan især i Redis Open Source med aktiveret cluster ikke før udførelsen afgøre, hvilke data scriptet har brug for. Overfør derfor kendte nøgler fuldt ud via KEYS og variable værdier udelukkende via ARGV.

I Redis Open Source med aktiveret cluster skal de nøgler, der overføres til et script, desuden ligge i samme hash-slot. Den foregående deklaration muliggør denne kontrol, men erstatter den ikke. For data, der hører sammen, kan et bevidst valgt hash-tag være en hjælp, for eksempel account:{4711}:balance og account:{4711}:reservations. Den del, der står i krøllede parenteser, bestemmer her slot-tildelingen; dynamisk fastlagte nøgler ville omgå denne planlægning.

Atomisk opdatering af Fixed-Window-tælleren

Følgende eksempel er en atomar Tæller med fast tidsinterval til en lokal testinstans. Den kontrollerer tællerstand og grænse i et enkelt serverkørsel og indstiller udløbstiden kun ved den første vellykkede adgang inden for tidsvinduet. Dermed undgås det tidsrum mellem et GET i applikationskoden og et senere INCR, hvor en anden klient kunne ændre tælleren.

Kaldet overfører tællernøglen, grænsen og vinduets varighed i sekunder. Status 1 betyder godkendt, status 0 betyder, at grænsen er nået. Status 2 angiver en ugyldig indtastning, der er opdaget ved forudgående kontroller, en streng-tællerværdi, der er afvist dér, eller en eksisterende streng-tæller uden TTL. Hvis nøglen indeholder en anden Redis-datatype, mislykkes GET allerede med en teknisk typefejl; scriptet returnerer da ikke status 2. Også andre Redis-kørselsfejl skal skelnes fra den faglige returstatus. Eksemplet er ikke en skabelon til adgangsdata, produktive grænser eller belastningstests.

Før hver skriveoperation kontrollerer scriptet, at alle tal er endelige positive heltal inden for en bevidst lav øvre grænse. Det er mere end blot en kontrol med tonumber: Værdier som 1.5 eller 1e3 afvises. Grænsen på en million forhindrer desuden, at Lua-talpræcision eller den fra INCR forventet heltalstreng uden for eksempelområdet bliver relevant. Den maksimale vinduesvarighed på 86.400 sekunder begrænser også den EXPIRE det overførte antal sekunder.

EVAL "local max_counter = 1000000; local max_window = 86400; local function positive_integer(value, maximum) if type(value) ~= 'string' or not string.match(value, '^%d+$') then return nil; end; local number = tonumber(value); if not number or number ~= math.floor(number) or number < 1 or number > maximum then return nil; end; return number; end; local limit = positive_integer(ARGV[1], max_counter); local window = positive_integer(ARGV[2], max_window); if not limit or not window then return {2, 'invalid-arguments'}; end; local raw = redis.call('GET', KEYS[1]); if raw and (type(raw) ~= 'string' or not string.match(raw, '^%d+$')) then return {2, 'invalid-counter'}; end; local current = raw and tonumber(raw) or 0; if not current or current ~= math.floor(current) or current < 0 or current > max_counter then return {2, 'invalid-counter'}; end; if raw and redis.call('TTL', KEYS[1]) == -1 then return {2, 'missing-ttl'}; end; if current >= limit then return {0, current}; end; local next = redis.call('INCR', KEYS[1]); if next == 1 then redis.call('EXPIRE', KEYS[1], window); end; return {1, next}" 1 demo:rate-limit 3 60

Det regulære udtryk accepterer kun decimaltal; derefter kontrollerer hjælpefunktionen talværdien, om tallet er et heltal og den øvre grænse. En allerede eksisterende tæller må kun være en ikke-negativ heltalværdi inden for det samme begrænsede interval. Dermed kan en negativ, brøkdel eller for stor værdi ikke ændre grænsesemantikken ubemærket. Først efter disse kontroller følger INCR.

Hvis nøglen ikke findes, starter scriptet ved 0. Hvis der allerede findes en gyldig strengtæller uden udløbstid, returnerer det status 2 og skriver intet. Efter den første INCR sæt EXPIRE den TTL, der tidligere er blevet fuldstændigt kontrolleret. Ved senere treffere forbliver den uændret, så vinduet ikke forlænges løbende.

Der Returkontrakt er en del af grænsefladen: Det første element i arrayet beskriver status, det andet leverer, afhængigt af status, tællerstanden eller en fejlkode. Den kaldende kode bør behandle en faglig afvisning med status 0 anderledes end status 2, der angiver en overtrådt forudsætning. For yderligere oplysninger om valg og overvågning af løbetider henvises til artiklen Analyse og optimering af Redis-nøgleudløb et supplerende grundlag.

TTL-værdien sættes her bevidst kun ved det første hit. En skabelon, der opdateres ved hver adgang, ville have en anden tidssemantik og ville ikke længere være et fast vindue. Lua-atomicitet Det fjerner kun race-betingelsen. Om det er Fixed Window, Sliding Window eller Token Bucket, der passer til den ønskede retfærdighed og belastningsfordeling, afgøres af den valgte algoritme, ikke af script-sproget.

Vælg en passende forstøvningsmodel

Ikke alle sammensatte krav kræver et script. Hvis der findes en enkelt Redis-kommando, der allerede fuldt ud udtrykker forretningsreglen, er den som regel nemmere at anvende og kontrollere. For flerstrengede regler skal betingelser, datatyper og returkontrakt derimod betragtes samlet.

Fra og med Redis Open Source 8.4 findes der indbyggede »Compare-and-Set«- og »Compare-and-Delete«-operationer for enkelte strengnøgler: SET understøtter sammenligningsmulighederne IFEQ/IFNE/IFDEQ/IFDNE; DELEX håndterer betinget sletning. I tilfælde med enkelte nøgler er der derfor ikke behov for et separat sammenligningsscript. I Redis 8.2, 8.0 og 7.x er disse nye SET-indstillinger og DELEX ikke tilgængelige; her er de relevante WATCH- eller Lua-mønstre stadig gældende.

Ved optimistisk »Compare-and-Set« kan WATCH være et passende valg før MULTI og EXEC: Hvis en overvåget nøgle ændres før EXEC, afbrydes transaktionen, og klienten beslutter, om der skal gøres et nyt forsøg. Transaktioner tilbyder heller ikke en generel rollback ved fejl under EXEC. WATCH forbliver derfor en mulighed, hvis den nødvendige betingelse ikke kan implementeres med en enkelt indbygget kommando.

EVAL-scripts er knyttet til script-cachen og modtager deres inddata via KEYS og ARGV. Redis-funktioner Findes fra Redis 7.0 som navngivne biblioteker: De registreres med FUNCTION LOAD, kaldes med FCALL og gemmes og replikeres sammen med databasen. Deres nøgler og argumenter overføres til funktionen som parametre; dette medfører en anden implementerings- og opkaldsmodel end ved EVAL.

Til anvendelsesorienteret, enkel logik er EVAL derfor en nem indgang. Flere klienter og datalogik, der skal vedligeholdes på lang sigt, taler ofte for Functions, forudsat at den anvendte open source-version af Redis understøtter dem. Beslutningen bør desuden tage højde for implementering, tilladelser, fejlhåndtering og en klart dokumenteret returværdi, ikke kun antallet af Redis-kommandoer.

Klynger, fejl og returkontrakter

I Redis Open Source med aktiveret cluster skal de overførte nøgler i et script med flere nøgler ligge i samme hash-slot. Hash-tags gør det muligt at styre dette: I account:{4711}:balance og account:{4711}:reservations Indholdet mellem krøllede parenteser bestemmer slotten. Begge nøgler kan derfor adresseres samtidigt. Kravet om samme slot gælder også her for de her omhandlede operationer med flere nøgler og MULTI/EXEC-transaktioner. Andre produkt- og clusterkonfigurationer kan afvige for enkelte kommandoer. Dette medfører ikke en generel cross-slot-godkendelse for Lua: Dokumentationen for operationer med flere nøgler klassificerer EVAL/EVALSHA som en single-slot-operation, selv i Redis Software med aktiveret cluster og med eller uden OSS Cluster API.

Alle anvendte nøgler skal deklareres som nøgleargumenter, før de kaldes. Et script må ikke udlede nøglenavne fra gemte værdier eller sammensætte dem dynamisk. Denne regel gør det muligt for Redis at foretage en korrekt slot-kontrol før udførelse og forhindrer skjulte afhængigheder, som forbliver ubemærkede i en standalone-instans, men som fejler i Redis Open Source med aktiveret cluster.

Med redis.call() videreformidles en fejl i den kaldte Redis-kommando som en scriptfejl til klienten. redis.pcall() returnerer den derimod til Lua, så scriptet kan håndtere den målrettet. pcall giver kun mening, hvis der er defineret en specifik reaktion, f.eks. et velstruktureret fejl svar eller et alternativt tilladt forløb. At ignorere fejl i stilhed skjuler data- og integritetsproblemer.

En Ugyldig aftale adskiller tekniske fejl fra faglige resultater. WRONGTYPE betyder for eksempel, at den gemte Redis-datatype ikke stemmer overens med den forventede kommando og derfor skal undersøges. En afvist reservation på grund af manglende lagerbeholdning er derimod et forventet resultat og kan for eksempel returnere status og restbeholdning. Applikationer bør ikke behandle disse kategorier ens eller gentage begge kategorier uden undtagelse.

Sikre en stabil drift af script-leveringen

EVAL er egnet til direkte opkald: Klienten overfører den fulde Lua-kildekode sammen med nøgle- og argumentværdier. For et ofte anvendt, uændret script kan applikationen i stedet bruge SCRIPT LOAD indlæse i script-cachen. Redis returnerer et SHA1-digest til dette formål; EVALSHA udfører derefter netop den tilhørende kildekode. Det sparer gentagne overførsler, men ændrer hverken scriptets atomaritet eller det faglige ansvar.

Der Script-cache er ikke permanent. Efter en genstart, et failover eller SCRIPT FLUSH kan et opkald via Digest foretages med NOSCRIPT mislykkes. Applikationen bør håndtere denne situation på normal vis: Indlæs scriptet igen og gentag det fagligt korrekte kald, forudsat at den egne retry-logik tillader det. Et digest må derfor ikke opfattes som en garanti for, at scriptet allerede findes på hver eneste målserver.

I forbindelse med pipelines er denne fallback-funktion begrænset. Hvis flere kommandoer allerede er sendt samlet, kan applikationen støde på en NOSCRIPT-Fejl må ikke erstattes med tilbagevirkende kraft ved at indlæse og køre koden igen på samme sted. Redis anbefaler i sådanne tilfælde parametriseret EVAL som en alternativ strategi. Hvis man planlægger replikering og failover, bør man desuden forstå, hvilken rolle replikeringsbufferen spiller, når en replika genopretter forbindelsen: Sådan forstår du Redis-replikationsbackloggen.

Variable værdier hører ikke hjemme i Lua-kildekoden, men i ARGV. Ellers vil hver grænseværdi f.eks. generere et andet script og unødigt forstørre cachen. Siden Redis 7.4 kan man via EVAL eller EVAL_RO indlæste scripts fjernes ved en cache-grænse efter LRU-princippet; dette erstatter hverken parametrisering eller håndteringen af NOSCRIPT.

At mestre lange scripts og stavefejl

Et Lua-script blokerer andre serveraktiviteter, mens det kører normalt. Det skaber isolation, men bliver ved lange køretider til Driftsrisiko. Hvis et script overskrider den konfigurerede busy-reply-threshold, svarer Redis på almindelige kommandoer med BUSY; det afslutter ikke scriptet automatisk. Begræns derfor scripts til få kendte nøgler og små, afgrænsede beregninger.

Skriveoperationer, der udføres umiddelbart før en fejl eller en uendelig løkke, er særligt kritiske. Hvis et script allerede har ændret data, kan SCRIPT KILL det ikke afsluttes korrekt. Kontroller derfor indtastningerne, før du skriver for første gang, og undgå ubegrænsede sløjfer samt SCAN om samlede beholdninger. Testene bør afspejle datamængden og fejlforløbene i den planlagte anvendelse.

Med maksimal hukommelse afhænger forløbet af den første skriveoperation. Hvis Redis allerede har overskredet grænsen, kan en hukommelseskrævende kommando ved redis.call afbryde scriptet; redis.pcall returnerer fejlen til Lua og kræver en bevidst udformet fejlhåndteringsrute. Ændringer, der allerede er gennemført, bliver ikke rettet som følge heraf.

En første operation uden behov for yderligere lagerplads, f.eks. DEL eller LREM, kan man derimod lade scriptet køre videre; senere skrivninger kan øge forbruget via maxmemory øge. Tekniske fejl som f.eks. WRONGTYPE eller CROSSSLOT I Redis Open Source med aktiveret klynge kræver rettelser i datamodellen eller nøgledesignet, mens det kun er selve scriptet, der kan definere en faglig afvisning som en stabil status.

Bevidst vælge egnede anvendelsestilfælde

Ved en betinget reservation kan et script kontrollere lagerbeholdningen, afvise en for lille mængde og, hvis det lykkes, returnere den resterende beholdning. Den atomreservation omfatter dog kun Redis. Betaling, relationsdatabase, e-mail og eksterne API’er kræver en separat tilpasning og eventuelt en afstemningslogik.

Valget afhænger af Redis-versionen og datamodellen. Fra og med Redis Open Source 8.4 kan sammenligningsindstillingerne fra SET en betinget indstilling og DELEX at udføre sammenligning og sletning af en enkelt string-nøgle. Før Redis 8.4 eller ved en mere kompleks betingelse er WATCH med MULTI/EXEC Et alternativ: Hvis en overvåget nøgle ændres før EXEC, afbrydes transaktionen, og klienten beslutter, om der skal læses igen og gentages. Et kort Lua-script er velegnet, når flere kommandoer eller datastrukturer, herunder deres forretningsregler, skal samvirke på serversiden.

Hverken den enkelte kommando eller Lua-mønsteret er tilstrækkeligt som overordnet koncept for distribuerede låse. Lease-varighed, procespauser, nedbrud, gentagelser, failover og scenarier med flere instanser skal vurderes separat. Foretræk en indbygget kommando, hvis den anvendte version og dens semantik dækker hele reglen. Ellers er WATCH og vurdere, om et kort script er passende afhængigt af fejlkontrakten og placeringen af den faglige logik. Til genanvendelig server-side logik kan en Redis-funktion være en god løsning. Skrivbeskyttede scripts kan fra og med Redis 7.0 via EVAL_RO eller EVALSHA_RO kører, men kun hvis logikken garanteret er skrivefri.