Utilizar corretamente os scripts Lua do Redis para operações atómicas

Organizar scripts Lua do Redis de forma atómica

Os scripts Lua do Redis executam a lógica de dados específica diretamente no servidor Redis. Enquanto um script está a ser executado, o Redis não processa outras atividades do servidor; os comandos nele contidos estão, portanto, isolados em relação a outros clientes. Isto permite agrupar vários comandos simples num único operação atómica combinar, por exemplo, uma verificação de limite seguida de uma atualização do contador ou uma débito apenas se houver saldo suficiente.

Sem um script, um cliente pode, numa primeira fase, ler um contador com um pedido GET, verificar o limite no código da aplicação e, em seguida, enviar um pedido INCR. No entanto, entre estas etapas, outro cliente pode alterar o mesmo contador. Um script, por outro lado, lê, verifica e aumenta o contador sem esse estado intermédio observável. Isso resolve a condição de corrida da regra composta, mas não resolve automaticamente questões como valores-limite adequados, tempos de execução ou formatos de retorno.

«Atómico» e «isolado» não significa que Scripts Lua do Redis As transações de base de dados com reversão automática. Se ocorrer um erro de execução após uma operação de gravação já ter sido realizada, as alterações anteriores não são revertidas de forma generalizada. Por isso, os scripts devem verificar as entradas, os tipos de dados e os pré-requisitos funcionais antes da primeira gravação; os percursos de erro após as alterações requerem um tratamento cuidadosamente concebido.

Algumas regras típicas são: permitir o acesso apenas dentro de um limite ou reduzir um stock apenas se a quantidade for suficiente. Verifica primeiro se um único comando Redis já expressa a regra na íntegra. Um script faz sentido quando várias operações Redis, incluindo as respetivas condições, têm de funcionar em conjunto de forma atómica.

Um padrão Lua para «comparar e eliminar» compara o valor armazenado com um token de propriedade passado como parâmetro e só o elimina se houver correspondência. Desta forma, um processo atrasado não pode eliminar uma chave que entretanto tenha sido reocupada apenas por causa do seu token antigo.

Este modelo comparativo descreve exclusivamente a sequência segura para uma única chave do Redis. Não resolve as questões mais complexas relacionadas com bloqueios distribuídos, tais como durações adequadas de lease, pausas de processos, falhas ou a coordenação de várias instâncias do Redis. Além disso, a atomicidade de um comando ou script abrange apenas os dados do Redis envolvidos, não incluindo pagamentos, bases de dados, e-mails ou APIs externas.

Lua Sandbox e limites claros

O Redis Open Source integra o Lua 5.1 para scripts. Este ambiente de execução não deve ser equiparado a uma versão principal do Lua instalada localmente ou à versão mais recente: o conjunto de funcionalidades da linguagem e as regras de segurança são determinados pelo Redis. Quem desenvolve scripts Lua para o Redis deve, por isso, testá-los em relação à versão do Redis efetivamente utilizada e não partir do princípio de que existem características de um ambiente Lua externo qualquer.

A execução é realizada numa Sandbox com limites deliberadamente restritos. Um script deve processar dados do Redis e argumentos passados, mas não deve utilizar o sistema de ficheiros, a rede nem os serviços do sistema operativo. Por conseguinte, as chamadas HTTP externas, o envio de mensagens ou o acesso a ficheiros locais devem ser integrados no código da aplicação ou num serviço destinado a esse fim, e não no cache scripting.

O Redis disponibiliza KEYS e ARGV como variáveis de âmbito global. Por outro lado, para valores intermédios próprios e funções auxiliares, deves utilizar variáveis locais com local. Desta forma, fica claro quais os valores que se aplicam apenas a esta chamada, e a lógica do script não cria dependências evitáveis. Podes chamar os comandos do Redis de forma específica através de redis.call ou redis.pcall sobre.

A sandbox não substitui o planeamento de capacidade. Durante a execução normal, um script bloqueia outros clientes no servidor; por isso, loops longos, volumes de dados ilimitados e avaliações que exigem grande capacidade de processamento não são adequados. Limite o trabalho a um número reduzido de chaves conhecidas de antemão e a pequenos cálculos. Análises abrangentes, inventários globais baseados em SCAN ou comunicação com sistemas externos aumentariam os riscos operacionais, sem ampliar de forma significativa a atomicidade.

Compreender EVAL, KEYS e ARGV

A execução direta de um script utiliza o formato EVAL script numkeys [key …] [arg …]. De acordo com o código-fonte, `numkeys` determina quantos dos parâmetros seguintes são chaves. O script acede a elas através de KEYS com indexação baseada em 1; todos os restantes valores encontram-se em ARGV. Esta separação é essencial: as chaves descrevem os dados do Redis, enquanto os argumentos descrevem as entradas específicas, tais como valores-limite, montantes ou tokens esperados.

Um script de limite recebe, por exemplo, o contador como KEYS[1] e o valor máximo como ARGV[1]. Lê o valor atual, converte o valor limite com tonumber(ARGV[1]) converte-o num número e compara ambos os valores antes de o aumentar. A conversão torna explícita a regra aritmética pretendida, em vez de depender de um tratamento implícito dos valores dos argumentos. Se faltar um contador, o script pode tratar especificamente o valor lido como zero.

Cada chave que o script lê ou escreve tem de ser especificada previamente como argumento de chave. Compor nomes de chaves no script a partir de prefixos ou derivá-los de dados armazenados não é uma prática recomendável. O Redis, especialmente na versão Open Source com o cluster ativado, não consegue determinar, antes da execução, de que dados o script necessita. Por isso, passe as chaves conhecidas na íntegra através de KEYS e os valores variáveis exclusivamente através de ARGV.

No Redis Open Source com o cluster ativado, as chaves passadas a um script têm, além disso, de estar no mesmo slot de hash. A declaração anterior permite essa verificação, mas não a substitui. Para dados relacionados, uma tag de hash escolhida deliberadamente pode ajudar, por exemplo, account:{4711}:balance e account:{4711}:reservations. A parte entre chaves determina aqui a atribuição de slots; as chaves determinadas dinamicamente comprometeriam este planeamento.

Atualizar o contador de janela fixa de forma atómica

O exemplo seguinte é um Contador de janela fixa para uma instância de teste local. Verifica o valor do contador e o limite numa execução do servidor e define o tempo de expiração apenas no primeiro acesso bem-sucedido dentro da janela de tempo. Desta forma, elimina-se a janela de tempo entre um GET no código da aplicação e um INCR posterior, durante a qual outro cliente poderia alterar o contador.

A chamada passa a chave do contador, o limite e a duração da janela em segundos. O estado 1 significa «aprovado», o estado 0 significa «limite atingido». O estado 2 indica uma entrada inválida detetada nas verificações prévias, um valor de contador de cadeia de caracteres rejeitado nessas verificações ou a existência de um contador de cadeia de caracteres sem TTL. Se a chave contiver outro tipo de dados Redis, a chamada GET falhará devido a um erro técnico de tipo; nesse caso, o script não devolve o estado 2. Outros erros de tempo de execução do Redis também devem ser distinguidos do estado de retorno funcional. O exemplo não constitui um modelo para dados de acesso, limites em produção ou testes de carga.

Antes de cada operação de escrita, o script valida todos os números como números inteiros positivos finitos dentro de um limite máximo deliberadamente baixo. Isto é mais do que uma verificação com tonumber: Valores como 1.5 ou 1e3 são rejeitados. O limite de um milhão impede, além disso, que a precisão numérica do Lua ou a de INCR A cadeia de caracteres inteiros esperada pode tornar-se relevante fora do âmbito do exemplo. A duração máxima da janela, de 86 400 segundos, também limita o EXPIRE Número de segundos transmitido.

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

A expressão regular aceita apenas algarismos decimais; em seguida, a função auxiliar verifica o valor numérico, se é um número inteiro e o limite superior. Um contador já existente só pode ser um número inteiro não negativo dentro do mesmo intervalo limitado. Desta forma, um valor negativo, fracionário ou excessivamente grande não pode alterar a semântica dos limites sem ser detetado. Só após estas verificações é que se segue INCR.

Se a chave não existir, o script começa em 0. Se já existir um contador de cadeias válido sem prazo de validade, o script devolve o estado 2 e não grava nada. Após o primeiro INCR conjuntos EXPIRE o TTL, que foi previamente verificado na íntegra. Em ocorrências posteriores, este permanece inalterado, pelo que a janela não é prolongada continuamente.

O Contrato de devolução faz parte da interface: o primeiro elemento da matriz descreve o estado; o segundo fornece, consoante o estado, o valor do contador ou um código de erro. O código que efetua a chamada deve tratar uma rejeição técnica com o estado 0 de forma diferente do estado 2, que indica uma condição prévia não cumprida. Para mais informações sobre a seleção e monitorização de tempos de execução, consulte o artigo Analisar e otimizar a expiração das chaves do Redis uma base complementar.

O TTL é aqui definido deliberadamente apenas na primeira correspondência. Um padrão que fosse renovado a cada acesso teria uma semântica temporal diferente e deixaria de ser uma «janela fixa». Atomicidade do Lua apenas elimina a condição de corrida. Se o «Fixed Window», o «Sliding Window» ou o «Token Bucket» se adequam à equidade e à distribuição de carga pretendidas, isso é determinado pelo algoritmo escolhido, e não pela linguagem de script.

Selecionar o modelo de atomização adequado

Nem todos os requisitos compostos necessitam de um script. Se existir um único comando Redis que já expresse a regra de negócio na íntegra, este é, na maioria das vezes, mais fácil de executar e de verificar. Por outro lado, no caso de regras com várias etapas, é necessário considerar em conjunto as condições, os tipos de dados e a contracção de retorno.

A partir do Redis Open Source 8.4, existem operações nativas «Compare-and-Set» e «Compare-and-Delete» para chaves de tipo string individuais: SET suporta as opções de comparação IFEQ/IFNE/IFDEQ/IFDNE; DELEX suporta a eliminação condicional. Assim, para casos específicos de chaves únicas, não é necessário um script de comparação específico. No Redis 8.2, 8.0 e 7.x, estas novas opções SET e DELEX não estão disponíveis; nessas versões, continuam a ser relevantes os padrões WATCH ou Lua adequados.

Para um «Compare-and-Set» otimista, o WATCH pode ser adequado antes do MULTI e do EXEC: se uma chave observada for alterada antes do EXEC, a transação é interrompida e o cliente decide se deve tentar novamente. Além disso, as transações não oferecem um rollback geral em caso de erros durante a instrução EXEC. Por isso, a instrução WATCH continua a ser uma opção quando a condição necessária não pode ser representada por uma única instrução nativa.

Os scripts EVAL estão ligados à cache de scripts e recebem os seus dados de entrada através de KEYS e ARGV. Funções do Redis A partir do Redis 7.0, existem como bibliotecas nomeadas: são registadas com FUNCTION LOAD, chamadas com FCALL e, além disso, são persistidas e replicadas juntamente com a base de dados. As suas chaves e argumentos chegam à função como parâmetros; daí resulta um modelo de disponibilização e chamada diferente do utilizado pelo EVAL.

Para lógica simples e orientada para a aplicação, o EVAL é, por isso, uma porta de entrada direta. A existência de vários clientes e de lógicas de dados mantidas a longo prazo justifica frequentemente o uso de funções, desde que a versão de código aberto do Redis utilizada as suporte. A decisão deve ainda ter em conta a implementação, as autorizações, o tratamento de erros e um retorno claramente documentado, e não apenas o número de comandos Redis.

Clusters, erros e contratos de devolução

No Redis Open Source com o cluster ativado, as chaves passadas num script com várias chaves têm de estar no mesmo slot de hash. As etiquetas de hash permitem controlar isso: No caso de account:{4711}:balance e account:{4711}:reservations O conteúdo entre chaves define o slot. Por conseguinte, ambas as chaves podem ser acedidas em conjunto. O requisito de «Same Slot» aplica-se também às operações com várias chaves e às transações MULTI/EXEC aqui consideradas. Outras configurações de produto e de cluster podem variar em comandos específicos. Daí não decorre qualquer autorização geral de «cross-slot» para o Lua: a documentação sobre chaves múltiplas classifica o EVAL/EVALSHA como uma operação de «single-slot», mesmo no Redis Software com o cluster ativado e com ou sem a API de cluster OSS.

Todas as chaves utilizadas têm de ser declaradas como argumentos de chave antes da sua invocação. Um script não pode derivar nomes de chaves a partir de valores armazenados nem compô-los dinamicamente. Esta regra permite que o Redis efetue a verificação correta dos slots antes da execução e evita dependências ocultas que passam despercebidas numa instância autónoma, mas que falham no Redis Open Source com o cluster ativado.

Com redis.call() um erro no comando Redis executado é transmitido ao cliente como um erro de script. redis.pcall() Em contrapartida, devolve-o à Lua, para que o script o possa tratar de forma específica. A função pcall só faz sentido se estiver definida uma reação específica, como uma resposta de erro bem estruturada ou um fluxo alternativo válido. Ignorar silenciosamente os erros oculta problemas de dados e de integridade.

A Contrato com erros distingue erros técnicos de resultados funcionais. WRONGTYPE significa, por exemplo, que o tipo de dados Redis armazenado não corresponde ao comando esperado e deve ser analisado. Por outro lado, uma reserva recusada devido à falta de stock é um resultado esperado e pode, por exemplo, devolver o estado e o stock restante. As aplicações não devem tratar estas categorias da mesma forma nem repetir ambas de forma genérica.

Garantir um funcionamento robusto da distribuição de scripts

EVAL é adequado para chamadas diretas: o cliente transmite o código-fonte Lua completo, juntamente com os valores das chaves e dos argumentos. No caso de um script frequentemente utilizado e inalterado, a aplicação pode, em vez disso, utilizá-lo com SCRIPT LOAD carregar no cache de scripts. Para tal, o Redis devolve um resumo SHA1; EVALSHA em seguida, executa exatamente o código-fonte correspondente. Isto evita a transmissão repetida, mas não altera nem a atomicidade nem a responsabilidade técnica do script.

O Cache de scripts não é permanente. Após um reinício, uma transição de failover ou SCRIPT FLUSH é possível efetuar uma chamada por meio de um resumo com NOSCRIPT falhar. A aplicação deve tratar este caso de forma normal: recarregar o script e repetir a chamada correta, desde que a sua própria lógica de repetição o permita. Um «digest» não deve, portanto, ser interpretado como uma garantia de que o script já se encontra disponível em todos os servidores de destino.

No caso dos pipelines, esta opção de recurso é limitada. Se já tiverem sido enviadas várias ordens em conjunto, a aplicação pode encontrar um NOSCRIPT- Não substituir erros retroativamente carregando e executando novamente no mesmo ponto. O Redis recomenda, para esses casos, o uso de EVAL como estratégia alternativa. Quem planeia a replicação e o failover deve também compreender o papel que o buffer de replicação desempenha na reconexão de uma réplica: Compreender o backlog de replicação do Redis.

Os valores das variáveis não devem constar no código-fonte Lua, mas sim em ARGV. Caso contrário, cada valor limite gera um script diferente e aumenta desnecessariamente o cache. A partir do Redis 7.4, é possível, através de EVAL ou EVAL_RO os scripts carregados sejam removidos quando se atingir o limite da cache segundo o critério LRU; isto não substitui nem a parametrização nem o tratamento de NOSCRIPT.

Dominar scripts longos e erros ortográficos

Um script Lua bloqueia outras atividades do servidor durante a sua execução normal. Isto proporciona isolamento, mas, em caso de tempos de execução prolongados, torna-se Risco operacional. Se um script exceder o valor configurado busy-reply-threshold, o Redis responde aos comandos normais com BUSY; não encerra o script automaticamente. Por isso, limita os scripts a algumas chaves conhecidas e a cálculos pequenos e limitados.

As operações de gravação que antecedem um erro ou um ciclo infinito são particularmente críticas. Se um script já tiver alterado dados, pode SCRIPT KILL não o encerra de forma segura. Por isso, verifica os dados introduzidos antes da primeira gravação e evita loops ilimitados, bem como SCAN sobre os stocks totais. Os testes devem refletir o volume de dados e os percursos de erro da implementação prevista.

Em memória máxima o processo depende da primeira operação de gravação. Se o Redis já tiver ultrapassado o limite, um comando que consuma muita memória pode, em caso de redis.call interromper o script; redis.pcall retorna o erro ao Lua e requer um fluxo de erros deliberadamente concebido. As alterações já efetuadas não são, por isso, revertidas.

Uma primeira operação que não requer memória adicional, por exemplo DEL ou LREM, por outro lado, pode deixar o script a continuar a executar-se; operações de gravação posteriores podem aumentar o consumo através de maxmemory aumentar. Erros técnicos como WRONGTYPE ou CROSSSLOT No Redis Open Source com o cluster ativado, são necessárias correções no modelo de dados ou no desenho das chaves, enquanto apenas o próprio script pode definir uma rejeição técnica como estado estável.

Escolher conscientemente os casos de aplicação adequados

No caso de uma reserva condicional, um script pode verificar o stock, rejeitar um valor demasiado baixo e, em caso de sucesso, devolver o stock restante. O Reserva atómica No entanto, abrange apenas o Redis. O pagamento, a base de dados relacional, o e-mail e as APIs externas requerem uma coordenação específica e, se necessário, uma lógica de compensação.

A escolha depende da versão do Redis e do modelo de dados. A partir do Redis Open Source 8.4, as opções de comparação de SET uma definição condicional e DELEX realizar a comparação e a eliminação de uma única chave de tipo string. Antes do Redis 8.4 ou no caso de uma condição mais complexa, WATCH com MULTI/EXEC Uma alternativa: se uma chave observada se alterar antes do EXEC, a transação é interrompida e o cliente decide se deve proceder a uma nova leitura e repetir o processo. Um pequeno script em Lua é adequado quando vários comandos ou estruturas de dados, incluindo as respetivas regras de negócio, têm de interagir do lado do servidor.

No caso de bloqueios distribuídos, nem o comando individual nem o padrão Lua são suficientes como conceito global. A duração do lease, as pausas de processo, as falhas, as repetições, o failover e os cenários com múltiplas instâncias devem ser avaliados separadamente. Dá preferência a um comando nativo se a versão em uso e a sua semântica abrangerem toda a regra. Caso contrário, WATCH e ponderar a utilização de um script curto, dependendo do contrato de erros e da localização da lógica de negócio. Para lógica reutilizável do lado do servidor, uma função Redis pode ser adequada. Scripts de leitura apenas a partir do Redis 7.0, podem ser utilizados através de EVAL_RO ou EVALSHA_RO funcionam, mas apenas se for garantido que a lógica não envolve gravação.