Transazioni Redis e script Lua di lunga durata

Redis offre due meccanismi per la gestione delle transazioni:transazioni basate su MULTI/EXEC e valutazione degli script Lua. Lo scripting Redis Lua è l'approccio consigliato ed è abbastanza diffuso nell'uso.

I nostri clienti Redis™ che hanno implementato script Lua segnalano spesso questo errore:"BUSY Redis è impegnato nell'esecuzione di uno script. Puoi chiamare solo SCRIPT KILL o SHUTDOWN NOSAVE ”. In questo post, spiegheremo la proprietà transazionale Redis degli script, di cosa tratta questo errore e perché dobbiamo prestare molta attenzione a riguardo sui sistemi gestiti da Sentinel che possono eseguire il failover.

Natura transazionale degli script Redis Lua

Le "transazioni" Redis non sono realmente transazioni come intese convenzionalmente:in caso di errori, non c'è il rollback delle scritture effettuate dallo script.

L'"atomicità" degli script Redis è garantita nel modo seguente:

• Una volta avviata l'esecuzione di uno script, tutti gli altri comandi/script vengono bloccati fino al completamento dello script. Quindi, altri client vedono le modifiche apportate dallo script oppure no. Questo perché possono essere eseguiti solo prima dello script o dopo lo script.
• Tuttavia, Redis non esegue rollback, quindi in caso di errore all'interno di uno script, tutte le modifiche già apportate dallo script verranno mantenute e i comandi/script futuri vedranno tali modifiche parziali.
• Poiché tutti gli altri client vengono bloccati durante l'esecuzione dello script, è fondamentale che lo script si comporti correttamente e termini in tempo.

Il valore "lua-time-limit"

Si consiglia vivamente di completare lo script entro un limite di tempo. Redis lo applica in un modo debole con il valore "lua-time-limit". Questo è il tempo massimo consentito (in ms) per l'esecuzione dello script. Il valore predefinito è 5 secondi. Questo è un tempo davvero lungo per l'attività legata alla CPU (gli script hanno un accesso limitato e non possono eseguire comandi che accedono al disco).

Tuttavia, lo script non viene ucciso quando viene eseguito oltre questo tempo. Redis ricomincia ad accettare i comandi del client, ma risponde con un errore BUSY.

Se devi terminare lo script a questo punto, sono disponibili due opzioni:

• SCRIPT KILL il comando può essere utilizzato per interrompere uno script che non ha ancora eseguito alcuna scrittura.
• Se lo script ha già eseguito scritture sul server e deve ancora essere terminato, utilizzare SHUTDOWN NOSAVE per spegnere completamente il server.

Di solito è meglio aspettare che lo script completi la sua operazione. Le informazioni complete sui metodi per terminare l'esecuzione dello script e il relativo comportamento sono disponibili nella documentazione.

Comportamento sui sistemi ad alta disponibilità monitorati da Sentinel

I sistemi ad alta disponibilità gestiti da Sentinel aggiungono una nuova ruga a questo. In effetti, questa discussione si applica a qualsiasi sistema ad alta disponibilità che dipende dal polling dei server Redis per verificare l'integrità:

• Gli script di lunga durata inizialmente bloccheranno i comandi del client. Successivamente, quando il "lua-time-limit" è trascorso, il server inizierà a rispondere con errori BUSY.
• Le Sentinelle considereranno tale nodo come non disponibile e, se questo persiste oltre il valore di riduzione dopo millisecondi configurato sulle Sentinelle, determineranno che il nodo è inattivo.
• Se tale nodo è il master, verrà avviato un failover. Un nodo di replica potrebbe essere promosso e potrebbe iniziare ad accettare nuove connessioni dai client.
• Nel frattempo, il master più vecchio alla fine completerà l'esecuzione dello script e tornerà online. Tuttavia, Sentinel alla fine lo riconfigura come una replica e inizierà a sincronizzarsi con il nuovo master. Tutti i dati scritti dallo script andranno persi.

Dimostrazione

Abbiamo impostato un sistema sensibile ad alta disponibilità per dimostrare questo comportamento di failover. La configurazione prevede 2 server Redis in esecuzione in una configurazione master/replica monitorata da un quorum a 3 sentinelle.

Il valore lua-time-limit è stato impostato su 500 ms in modo che inizi a rispondere ai client con errori se uno script viene eseguito per più di 500 ms. Il valore down-after-milliseconds su Sentinels è impostato su 5 secondi in modo che un nodo che segnala errori venga contrassegnato DOWN dopo 5 secondi.

Eseguiamo il seguente script Lua sul master:

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

Questo continua a scrivere voci nel master Redis. Ci iscriviamo agli eventi su una delle sentinelle per osservarne il comportamento.

Lo script viene avviato sul master:

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

Ecco una sequenza troncata di attività vista su 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"

In seguito, quando il vecchio master viene portato online, viene cambiato in una replica:

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"

Tutti i dati scritti nel vecchio master tramite lo script vengono persi.

Consigli

• Devi conoscere in anticipo le caratteristiche dei tuoi script di lunga durata prima di implementarli in produzione.
• Se il tuo script supera regolarmente il limite di tempo lua, devi rivedere lo script accuratamente per possibili ottimizzazioni. Puoi anche scomporlo in parti che si completano in durate accettabili.
• Se devi eseguire script che violano il limite di tempo lua, valuta la possibilità di programmare questi script durante i periodi in cui l'attività di altri client sarà bassa.
• Il valore del lua-time-limit può anche essere aumentato. Questa sarebbe una soluzione accettabile se altre applicazioni client eseguite in parallelo con lo script possono tollerare di ricevere risposte estremamente ritardate anziché un errore BUSY e riprovare in seguito.

Ulteriori considerazioni sui sistemi ad alta disponibilità monitorati da Sentinel:

• Se gli script eseguono solo operazioni di lettura e hai repliche disponibili, puoi spostare questi script nelle repliche.

Modifica il parametro Sentinel dopo millisecondi a un valore che assicuri che i failover non vengano avviati. Devi farlo solo dopo un'attenta considerazione perché un aumento drastico del valore comprometterà le caratteristiche di alta disponibilità del tuo sistema. Ciò potrebbe anche far sì che i guasti del server autentico vengano ignorati.