Att använda Redis Lua-skript för atomära operationer på rätt sätt

Sortera atomära Redis-Lua-skript

Redis Lua-skript utför affärslogik direkt på Redis-servern. Medan ett skript körs hanterar Redis inga andra serveraktiviteter; de kommandon som ingår är därför isolerade från andra klienter. På så sätt kan flera enkla kommandon slås samman till en atomär operation koppla ihop, till exempel en gränskontroll följd av en uppdatering av räknaren eller en debitering endast om det finns tillräckligt med saldo.

Utan ett skript kan en klient först läsa av en räknare med GET, kontrollera gränsvärdet i applikationskoden och därefter skicka INCR. Mellan dessa steg kan dock en annan klient ändra samma räknare. Ett skript läser, kontrollerar och ökar däremot utan detta observerbara mellanläge. Detta löser race-villkoret i den sammansatta regeln, men löser inte automatiskt frågor som lämpliga gränsvärden, tidsgränser eller returformat.

Att vara avskild och isolerad betyder inte att Redis Lua-skript Databastransaktioner med automatisk återställning. Om ett körningsfel uppstår efter att en skrivoperation redan har genomförts, återtas inte tidigare ändringar automatiskt. Därför bör skript kontrollera indata, datatyper och affärsmässiga förutsättningar innan den första skrivningen; felhantering efter ändringar kräver en medvetet utformad strategi.

Typiska regler är: att endast tillåta åtkomst inom en viss gräns eller att endast minska ett lager om det finns tillräckligt med varor. Kontrollera först om en befintlig enskild Redis-kommando redan uttrycker hela regeln. Ett skript är lämpligt när flera Redis-operationer, inklusive deras villkor, måste samverka atomärt.

Ett Lua-mönster för jämförelse och radering jämför det lagrade värdet med ett överfört ägarskapstoken och raderar endast om de är identiska. På så sätt kan en försenad process inte radera en nyckel som under tiden har tilldelats en annan värde enbart på grund av sitt gamla token.

Denna jämförelsemodell beskriver uteslutande den säkra sekvensen för en enskild Redis-nyckel. Den löser inte de mer omfattande frågorna kring distribuerade lås, såsom lämpliga leasingperioder, processpauser, avbrott eller samordningen av flera Redis-instanser. Atomiciteten hos ett kommando eller ett skript omfattar dessutom endast de berörda Redis-uppgifterna, inte betalningar, databaser, e-post eller externa API:er.

Lua Sandbox och tydliga gränser

Redis Open Source har inbyggt stöd för Lua 5.1 i sina skript. Denna runtime ska inte likställas med en lokalt installerad eller aktuell huvudversion av Lua: Redis bestämmer vilka språkfunktioner som är tillgängliga och vilka säkerhetsregler som gäller. Den som utvecklar Redis Lua-skript bör därför testa dem mot den Redis-version som faktiskt används och inte förutsätta egenskaper hos en godtycklig extern Lua-miljö.

Utförandet sker i en Sandlåda med avsiktligt snäva begränsningar. Ett skript ska bearbeta Redis-data och överförda argument, men får varken använda filsystemet, nätverket eller operativsystemstjänsterna. Externa HTTP-anrop, sändning av meddelanden eller åtkomst till lokala filer hör därför hemma i applikationskoden eller i en tjänst avsedd för detta, inte i cache-scripting.

Redis tillhandahåller KEYS och ARGV som globala variabler. För egna mellanvärden och hjälpfunktioner använder du däremot lokala variabler med local. På så sätt blir det tydligt vilka värden som endast gäller för just detta anrop, och skriptlogiken skapar inga onödiga beroenden. Redis-kommandon anropar du specifikt via redis.call eller . redis.pcall på.

Sandboxen ersätter inte kapacitetsplanering. Vid normal körning blockerar ett skript andra klienter på servern, varför långa loopar, obegränsade datamängder och beräkningskrävande utvärderingar är olämpliga. Begränsa arbetet till ett fåtal, i förväg kända nycklar och små beräkningar. Omfattande analyser, SCAN-baserade sammanställningar eller kommunikation med externa system skulle öka driftsriskerna utan att på ett meningsfullt sätt utöka atomariteten.

Att förstå EVAL, KEYS och ARGV

För att direkt köra ett skript används följande format EVAL script numkeys [key …] [arg …]. Enligt källkoden anger numkeys hur många av de efterföljande parametrarna som är nycklar. Skriptet hämtar dem via KEYS med indexering från 1; alla övriga värden finns i ARGV. Denna uppdelning är väsentlig: nycklarna beskriver Redis-data, medan argumenten beskriver de faktiska inmatningarna såsom gränsvärde, belopp eller förväntat token.

Ett gränsvärdesskript tar till exempel emot räknaren som KEYS[1] och gränsvärdet som ARGV[1]. Det läser av det aktuella värdet och omvandlar gränsvärdet med tonumber(ARGV[1]) omvandlar det till ett tal och jämför de båda värdena innan det ökas. Omvandlingen gör den avsedda numeriska regeln explicit, istället för att förlita sig på en implicit hantering av argumentvärden. Om en räknare saknas kan skriptet medvetet behandla det inlästa värdet som noll.

Varje nyckel som skriptet läser eller skriver måste anges i förväg som ett nyckelargument. Att sätta samman nyckelnamn i skriptet av prefix eller härleda dem från lagrade data är inte en tillförlitlig metod. Redis kan då, särskilt i Redis Open Source med aktiverad klusterfunktion, inte avgöra vilka data skriptet behöver innan det körs. Överför därför kända nycklar fullständigt via KEYS och variabla värden uteslutande via ARGV.

I Redis Open Source med kluster aktiverat måste dessutom de nycklar som överförs till ett skript ligga i samma hash-slot. Den tidigare deklarationen möjliggör denna kontroll, men ersätter den inte. För data som hör ihop kan en medvetet vald hash-tagg vara till hjälp, till exempel account:{4711}:balance och account:{4711}:reservations. Delen inom klamrarna bestämmer här tilldelningen av platser; dynamiskt fastställda nycklar skulle undergräva denna planering.

Uppdatera Fixed-Window-räknaren atomärt

Följande exempel är en atomär Räknare med fast fönster för en lokal testinstans. Den kontrollerar räknarvärdet och gränsvärdet i ett serverkörningspass och ställer in tidsgränsen först vid den första lyckade åtkomsten inom tidsfönstret. På så sätt undviks det tidsfönster mellan ett GET-anrop i applikationskoden och ett senare INCR-anrop, under vilket en annan klient skulle kunna ändra räknaren.

Anropet överför räknarnyckeln, gränsvärdet och fönstrets varaktighet i sekunder. Status 1 betyder godkänd, status 0 betyder att gränsen har nåtts. Status 2 indikerar en ogiltig inmatning som upptäckts vid förkontrollen, ett strängräknarvärde som avvisats där eller en befintlig strängräknare utan TTL. Om nyckeln innehåller en annan Redis-datatyp misslyckas redan GET med ett tekniskt typfel; skriptet returnerar då inte status 2. Även andra Redis-körningsfel måste skiljas från den funktionella returstatusen. Exemplet är inte en mall för åtkomstdata, produktiva gränsvärden eller belastningstester.

Innan varje skrivoperation kontrollerar skriptet att alla tal är ändliga positiva heltal inom en medvetet låg övre gräns. Det är mer än en kontroll med tonumber: Värden som 1.5 eller . 1e3 avvisas. Gränsen på en miljon förhindrar dessutom att Lua-talens noggrannhet eller den från INCR förväntad heltalssträng utanför exempelområdet blir relevant. Den maximala fönsterlängden på 86 400 sekunder begränsar också den EXPIRE antalet sekunder som överförts.

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 reguljära uttrycket accepterar endast decimalsiffror; därefter kontrollerar hjälpfunktionen talvärdet, om det är ett heltal och om det ligger inom gränserna. En redan befintlig räknare får endast vara ett icke-negativt heltal inom samma begränsade intervall. På så sätt kan ett negativt, bråktalsvärde eller ett för stort värde inte förändra gränssemantiken utan att det märks. Först efter dessa kontroller följer INCR.

Om nyckeln inte finns börjar skriptet vid 0. Om det redan finns en giltig strängräknare utan utgångstid returnerar det status 2 och skriver ingenting. Efter den första INCR uppsättningar EXPIRE den TTL som tidigare har kontrollerats fullständigt. Vid senare träffar förblir den oförändrad, vilket innebär att fönstret inte förlängs kontinuerligt.

Der Återlämningsavtal ingår i gränssnittet: Det första arrayelementet beskriver statusen, det andra returnerar, beroende på status, räknarvärdet eller en felkod. Den anropande koden bör hantera ett sakligt avslag med status 0 på ett annat sätt än status 2, som indikerar att ett villkor inte är uppfyllt. För mer information om val och övervakning av löptider, se artikeln Analysera och optimera utgångstiden för Redis-nycklar en kompletterande grund.

TTL-värdet sätts här medvetet endast vid den första träffen. Ett mönster som uppdateras vid varje åtkomst skulle ha en annan tidssemantik och skulle inte längre vara ett fast fönster. Lua-atomicitet Det eliminerar endast race condition. Om det är Fixed Window, Sliding Window eller Token Bucket som ger önskad rättvisa och lastfördelning avgörs av den valda algoritmen, inte av skriptspråket.

Välj lämplig atomiseringsmodell

Det är inte alla sammansatta krav som kräver ett skript. Om det finns ett enda Redis-kommando som redan fullständigt uttrycker affärsregeln är det oftast enklare att använda och kontrollera. För flerstegsregler måste däremot villkor, datatyper och returvärdeskontrakt beaktas tillsammans.

Från och med Redis Open Source 8.4 finns det inbyggda Compare-and-Set- och Compare-and-Delete-operationer för enskilda strängnycklar: SET stöder jämförelsefunktionerna IFEQ/IFNE/IFDEQ/IFDNE; DELEX hanterar villkorlig radering. För lämpliga fall med enstaka nycklar krävs därmed inget separat jämförelseskript. I Redis 8.2, 8.0 och 7.x finns dessa nya SET-alternativ och DELEX inte tillgängliga; där är lämpliga WATCH- eller Lua-mönster fortfarande relevanta.

För optimistisk ”Compare-and-Set” kan WATCH vara lämpligt före MULTI och EXEC: Om en övervakad nyckel ändras före EXEC avbryts transaktionen, och klienten avgör om ett nytt försök ska göras. Transaktioner erbjuder inte heller någon allmän återställning vid fel under EXEC. WATCH förblir därför ett alternativ när det nödvändiga villkoret inte kan åstadkommas med ett enda inbyggt kommando.

EVAL-skript är kopplade till skriptcachen och tar emot sina indata via KEYS och ARGV. Redis-funktioner Finns från och med Redis 7.0 som namngivna bibliotek: De registreras med FUNCTION LOAD, anropas med FCALL och sparas samt replikeras tillsammans med databasen. Deras nycklar och argument skickas till funktionen som parametrar; detta innebär en annan tillhandahållnings- och anropsmodell än hos EVAL.

För applikationsnära, enkel logik är EVAL därför en direkt ingång. Flera klienter och datalogik som ska underhållas på lång sikt talar ofta för Functions, förutsatt att den använda open source-versionen av Redis stöder detta. Beslutet bör dessutom ta hänsyn till distribution, behörigheter, felhantering och ett tydligt dokumenterat returvärde, inte bara antalet Redis-kommandon.

Kluster, fel och returavtal

I Redis Open Source med kluster aktiverat måste de överförda nycklarna i ett skript med flera nycklar ligga i samma hash-slot. Hash-taggar gör det möjligt att styra detta: Vid account:{4711}:balance och account:{4711}:reservations Innehållet mellan klammerna avgör vilken slot som används. Båda nycklarna kan därför adresseras samtidigt. Kravet på samma slot gäller även för de flernyckeloperationer och MULTI/EXEC-transaktioner som behandlas här. Andra produkt- och klusterkonfigurationer kan avvika för enskilda kommandon. Detta innebär inte någon allmän cross-slot-godkännande för Lua: Dokumentationen för flernyckeloperationer klassificerar EVAL/EVALSHA som en single-slot-operation även i Redis Software med aktiverat kluster och med eller utan OSS Cluster API.

Alla nycklar som används måste deklareras som nyckelargument innan de anropas. Ett skript får inte härleda nyckelnamn från lagrade värden eller sätta ihop dem dynamiskt. Denna regel gör det möjligt för Redis att utföra en korrekt slot-kontroll före körning och förhindrar dolda beroenden som förblir oupptäckta i en fristående instans, men som misslyckas i Redis Open Source med aktiverat kluster.

Med redis.call() vid ett fel i det anropade Redis-kommandot vidarebefordras detta till klienten som ett skriptfel. redis.pcall() återlämnar den däremot till Lua, så att skriptet kan hantera den på ett målinriktat sätt. pcall är endast meningsfullt om en specifik reaktion har definierats, till exempel ett välorganiserat felmeddelande eller ett alternativt tillåtet förlopp. Att tyst ignorera fel döljer data- och integritetsproblem.

En Ogiltigt avtal skiljer tekniska fel från sakliga resultat. WRONGTYPE innebär till exempel att den lagrade Redis-datatypen inte stämmer överens med det förväntade kommandot och måste undersökas. En avvisad bokning på grund av bristande lager är däremot ett förväntat resultat och kan till exempel returnera status och återstående lager. Applikationer bör inte behandla dessa kategorier på samma sätt eller upprepa båda generellt.

Säkerställa en stabil drift av skriptdistributionen

EVAL lämpar sig för direkta anrop: Klienten överför hela Lua-källkoden tillsammans med nyckel- och argumentvärden. För ett ofta använt, oförändrat skript kan applikationen istället använda SCRIPT LOAD ladda in i skriptcachen. Redis returnerar ett SHA1-digest för detta; EVALSHA kör därefter just den tillhörande källkoden. Detta sparar upprepade överföringar, men påverkar varken atomisiteten eller det tekniska ansvaret för skriptet.

Der Skriptcache är inte permanent. Efter en omstart, en failover eller SCRIPT FLUSH kan ett anrop via Digest göras med NOSCRIPT misslyckas. Applikationen bör hantera detta fall på vanligt sätt: ladda om skriptet och upprepa det tekniskt korrekta anropet, förutsatt att den egna logiken för omförsök tillåter det. En digest får därför inte tolkas som en garanti för att skriptet redan finns på varje målserver.

När det gäller pipeliner är denna fallback-funktion begränsad. Om flera kommandon redan har skickats tillsammans kan applikationen stöta på en NOSCRIPT-Ersätt inte fel retroaktivt genom att ladda och köra om på samma ställe. Redis rekommenderar i sådana fall parametriserad EVAL som en reservstrategi. Den som planerar replikering och failover bör dessutom förstå vilken roll replikeringsbuffert spelar vid återanslutning av en replik: Att förstå Redis-replikeringens backlog.

Variabla värden hör inte hemma i Lua-källkoden, utan i ARGV. Annars genererar varje gränsvärde ett eget skript och gör cachen onödigt stor. Sedan Redis 7.4 kan man via EVAL eller . EVAL_RO laddade skript tas bort vid en cachegräns enligt LRU-principen; detta ersätter varken parametriseringen eller hanteringen av NOSCRIPT.

Att hantera långa skript och stavfel

Ett Lua-skript blockerar andra serveraktiviteter under sin normala körning. Detta skapar isolering, men vid långa körningstider blir det till Verksamhetsrisk. Om ett skript överskrider den konfigurerade busy-reply-threshold, svarar Redis på vanliga kommandon med BUSY; det avslutar inte skriptet automatiskt. Begränsa därför skripten till ett fåtal kända nycklar och små, begränsade beräkningar.

Skrivoperationer som utförs innan ett fel eller en oändlig loop inträffar är särskilt kritiska. Om ett skript redan har ändrat data kan SCRIPT KILL avsluta det inte säkert. Kontrollera därför inmatningarna innan du skriver ut för första gången och undvik obegränsade loopar samt SCAN om totala bestånd. Testerna bör återspegla datamängden och felvägarna i den planerade driften.

Med maxminne beror förloppet på den första skrivoperationen. Om Redis redan har överskridit gränsen kan ett minneskrävande kommando vid redis.call avbryta skriptet; redis.pcall returnerar felet till Lua och kräver en medvetet utformad felhanteringskedja. Ändringar som redan har genomförts återställs inte på detta sätt.

En första operation utan behov av ytterligare lagringsutrymme, till exempel DEL eller . LREM, kan man däremot låta skriptet fortsätta köras; senare skrivoperationer kan öka förbrukningen via maxmemory öka. Tekniska fel såsom WRONGTYPE eller . CROSSSLOT I Redis Open Source med aktiverad klusterfunktion krävs korrigeringar av datamodellen respektive nyckelutformningen, medan endast skriptet självt kan definiera ett tekniskt avslag som stabil status.

Att medvetet välja lämpliga användningsområden

Vid en villkorad reservation kan ett skript kontrollera lagerstatusen, avvisa ett för lågt värde och, om det lyckas, returnera återstående lager. Den atomär reservation omfattar dock endast Redis. Betalningar, relationsdatabaser, e-post och externa API:er kräver separat samordning och, vid behov, kompensationslogik.

Valet beror på Redis-versionen och datamodellen. Från och med Redis Open Source 8.4 kan jämförelsealternativen från SET en villkorlig satsning och DELEX hantera jämförelse och radering av en enskild strängnyckel. Före Redis 8.4 eller vid ett mer komplext villkor gäller WATCH med MULTI/EXEC Ett alternativ: Om en övervakad nyckel ändras före EXEC avbryts transaktionen och klienten avgör om den ska läsas om och upprepas. Ett kort Lua-skript är lämpligt när flera kommandon eller datastrukturer, inklusive deras affärsregler, måste samverka på serversidan.

För distribuerade spärrar räcker varken det enskilda kommandot eller Lua-mönstret som helhetskoncept. Leasetid, processpauser, avbrott, upprepningar, failover och scenarier med flera instanser måste utvärderas separat. Använd helst ett inbyggt kommando om den version som används och dess semantik täcker hela regeln. I annat fall gäller WATCH och att överväga ett kort skript beroende på felhantering och var den specifika logiken ska placeras. För återanvändbar logik på serversidan kan en Redis-funktion vara lämplig. Skript som endast är skrivskyddade får från och med Redis 7.0 via EVAL_RO eller . EVALSHA_RO fungerar, men endast om logiken garanterat är skrivskyddad.