Redis-transaktioner og langvarige Lua-scripts

Redis tilbyder to mekanismer til håndtering af transaktioner – MULTI/EXEC baserede transaktioner og Lua scripts evaluering. Redis Lua scripting er den anbefalede tilgang og er ret populær i brug.

Vores Redis™-kunder, der har Lua-scripts installeret, rapporterer ofte denne fejl – "BUSY Redis har travlt med at køre et script. Du kan kun kalde SCRIPT KILL eller SHUTDOWN NOSAVE ”. I dette indlæg vil vi forklare scripts Redis-transaktionelle egenskaber, hvad denne fejl handler om, og hvorfor vi skal være ekstra forsigtige med den på Sentinel-administrerede systemer, der kan failover.

Transaktionelle karakter af Redis Lua-scripts

Redis "transaktioner" er egentlig ikke transaktioner som konventionelt forstået - i tilfælde af fejl er der ingen tilbagerulning af skrivninger lavet af scriptet.

“Atomicitet” af Redis-scripts er garanteret på følgende måde:

• Når et script begynder at køre, blokeres alle andre kommandoer/scripts, indtil scriptet er færdigt. Så andre klienter ser enten ændringerne foretaget af scriptet, eller også gør de det ikke. Dette skyldes, at de kun kan udføre enten før scriptet eller efter scriptet.
• Men Redis foretager ikke rollbacks, så ved en fejl i et script vil alle ændringer, der allerede er foretaget af scriptet, blive bibeholdt, og fremtidige kommandoer/scripts vil se disse delvise ændringer.
• Da alle andre klienter er blokeret, mens scriptet køres, er det afgørende, at scriptet er velopdragent og afsluttes i tide.

Værdien 'lua-time-limit'

Det anbefales stærkt, at scriptet fuldføres inden for en tidsgrænse. Redis håndhæver dette på en svag måde med 'lua-time-limit'-værdien. Dette er den maksimalt tilladte tid (i ms), som scriptet må køre. Standardværdien er 5 sekunder. Dette er virkelig lang tid for CPU-bundet aktivitet (scripts har begrænset adgang og kan ikke køre kommandoer, der får adgang til disken).

Scriptet dræbes dog ikke, når det udføres efter dette tidspunkt. Redis begynder at acceptere klientkommandoer igen, men svarer på dem med en BUSY-fejl.

Hvis du skal dræbe scriptet på dette tidspunkt, er der to tilgængelige muligheder:

• DRÆB AF SCRIPT kommandoen kan bruges til at stoppe et script, der endnu ikke har skrevet noget.
• Hvis scriptet allerede har udført skrivninger til serveren og stadig skal dræbes, skal du bruge SHUTDOWN NOSAVE for at lukke serveren helt ned.

Det er normalt bedre bare at vente på, at scriptet fuldfører sin handling. Den komplette information om metoder til at dræbe scriptudførelsen og relateret adfærd er tilgængelige i dokumentationen.

Adfærd på Sentinel-monitorerede systemer med høj tilgængelighed

Sentinel-administrerede systemer med høj tilgængelighed tilføjer en ny rynke til dette. Faktisk gælder denne diskussion for ethvert system med høj tilgængelighed, der er afhængigt af polling af Redis-servere for sundhed:

• Langevarende scripts vil i første omgang blokere klientkommandoer. Senere, når 'lua-time-limit' er overskredet, vil serveren begynde at svare med BUSY-fejl.
• Sentinels vil betragte en sådan node som utilgængelig, og hvis dette fortsætter ud over den ned-efter-millisekunder-værdi, der er konfigureret på Sentinels, vil de bestemme, at noden er nede.
• Hvis en sådan node er masteren, vil en failover blive startet. En replikaknude kan blive forfremmet og kunne begynde at acceptere nye forbindelser fra klienter.
• I mellemtiden vil den ældre master i sidste ende fuldføre eksekveringen af ​​scriptet og komme online igen. Sentinel vil dog i sidste ende omkonfigurere den som en replika, og den vil begynde at synkronisere med den nye master. Alle data skrevet af scriptet vil gå tabt.

Demonstration

Vi har opsat et følsomt system med høj tilgængelighed for at demonstrere denne failover-adfærd. Opsætningen har 2 Redis-servere, der kører i en master/replika-konfiguration, der overvåges af et quorum på 3 vagter.

Værdien for lua-time-limit blev sat til 500 ms, så den begynder at reagere på klienter med fejl, hvis et script kører i mere end 500 ms. Ned-efter-millisekunder-værdien på Sentinels er sat til 5 sekunder, så en node, der rapporterer fejl, er markeret NED efter 5 sekunder.

Vi udfører følgende Lua-script på masteren:

local i = 0
while (true)
do
local key = "Key-" .. i
local value = "Value-" .. i
redis.call('set', key, value)
i = i + 1
redis.call('time')
end

Dette bliver ved med at skrive indlæg i Redis-masteren. Vi abonnerer på begivenhederne på en af ​​vagtposterne for at observere adfærden.

Scriptet startes på masteren:

$ redis-cli -a  --eval test.lua
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.

Her er en afkortet sekvens af aktiviteter som set på Sentinel:

3) "+vote-for-leader"
4) "9096772621089bb885eaf7304a011d9f46c5689f 1"
1) "pmessage"
2) "*"
3) "+sdown" <<< master marked DOWN
4) "master test 172.31.2.48 6379"
1) "pmessage"
2) "*"
3) "+odown"
4) "master test 172.31.2.48 6379 #quorum 3/2"
1) "pmessage"
2) "*"
3) "-role-change" << role change initiated
4) "slave 172.31.28.197:6379 172.31.28.197 6379 @ test 172.31.2.48 6379 new reported role is master"
1) "pmessage"
2) "*"
3) "+config-update-from"
4) "sentinel 9096772621089bb885eaf7304a011d9f46c5689f 172.31.2.48 26379 @ test 172.31.2.48 6379"
1) "pmessage"
2) "*"
3) "+switch-master"
4) "test 172.31.2.48 6379 172.31.28.197 6379"

Senere, når den gamle mester bringes online, ændres den til en replika:

3) "-role-change"
4) "slave 172.31.2.48:6379 172.31.2.48 6379 @ test 172.31.28.197 6379 new reported role is master"
1) "pmessage"
2) "*"
3) "-sdown"
4) "slave 172.31.2.48:6379 172.31.2.48 6379 @ test 172.31.28.197 6379"
1) "pmessage"
2) "*"
3) "+role-change"
4) "slave 172.31.2.48:6379 172.31.2.48 6379 @ test 172.31.28.197 6379 new reported role is slave"

Alle data, der er skrevet til den gamle master via scriptet, går tabt.

Anbefalinger

• Du skal kende karakteristikaene for dine langvarige scripts på forhånd, før du implementerer dem i produktionen.
• Hvis dit script regelmæssigt overtræder lua-tidsgrænsen, skal du gennemgå scriptet grundigt for mulige optimeringer. Du kan også dele det op i stykker, der fuldfører i acceptabel varighed.
• Hvis du skal køre scripts, der overtræder lua-tidsgrænsen, kan du overveje at planlægge disse scripts i perioder, hvor anden klientaktivitet vil være lav.
• Værdien af ​​lua-tidsgrænsen kan også øges. Dette ville være en acceptabel løsning, hvis andre klientapplikationer, der kører parallelt med scriptet, kan tåle at modtage ekstremt forsinkede svar i stedet for en BUSY-fejl og prøve igen senere.

Yderligere overvejelser om Sentinel-overvågede systemer med høj tilgængelighed:

• Hvis scripts kun udfører læsehandlinger, og du har replikaer tilgængelige, kan du flytte disse scripts til replikaerne.

Rediger Sentinel-parameteren ned-efter-millisekunder til en værdi, der sikrer, at failovers ikke påbegyndes. Du må kun gøre dette efter nøje overvejelse, fordi en drastisk forøgelse af værdien vil kompromittere dit systems høje tilgængelighedsegenskaber. Dette kan også forårsage, at ægte serverfejl ignoreres.