O Redis oferece dois mecanismos para lidar com transações – transações baseadas em MULTI/EXEC e avaliação de scripts Lua. O script Redis Lua é a abordagem recomendada e é bastante popular em uso.
Nossos clientes Redis™ que têm scripts Lua implantados geralmente relatam esse erro – “BUSY Redis está ocupado executando um script. Você só pode chamar SCRIPT KILL ou SHUTDOWN NOSAVE ”. Nesta postagem, explicaremos a propriedade transacional dos scripts do Redis, do que se trata esse erro e por que devemos ter muito cuidado com isso em sistemas gerenciados pelo Sentinel que podem fazer failover.
Natureza Transacional dos Scripts Lua Redis
As “transações” do Redis não são realmente transações como entendidas convencionalmente – em caso de erros, não há rollback das gravações feitas pelo script.
A “atomicidade” dos scripts Redis é garantida da seguinte maneira:
- Quando um script começa a ser executado, todos os outros comandos/scripts são bloqueados até que o script seja concluído. Assim, outros clientes veem as alterações feitas pelo script ou não. Isso ocorre porque eles só podem ser executados antes ou depois do script.
- No entanto, o Redis não faz reversões, portanto, em caso de erro em um script, todas as alterações já feitas pelo script serão mantidas e os comandos/scripts futuros verão essas alterações parciais.
- Como todos os outros clientes são bloqueados durante a execução do script, é fundamental que o script seja bem comportado e termine a tempo.
O valor 'lua-time-limit'
É altamente recomendável que o script seja concluído dentro de um limite de tempo. O Redis impõe isso de maneira fraca com o valor «lua-time-limit». Este é o tempo máximo permitido (em ms) que o script pode ser executado. O valor padrão é 5 segundos. Este é um tempo muito longo para a atividade vinculada à CPU (os scripts têm acesso limitado e não podem executar comandos que acessam o disco).
No entanto, o script não é encerrado quando executado além desse tempo. O Redis começa a aceitar os comandos do cliente novamente, mas responde a eles com um erro BUSY.
Se você precisar matar o script neste momento, há duas opções disponíveis:
- CRIPT KILL O comando pode ser usado para parar um script que ainda não fez nenhuma gravação.
- Se o script já executou gravações no servidor e ainda deve ser eliminado, use o SHUTDOWN NOSAVE para encerrar o servidor completamente.
Geralmente é melhor esperar que o script complete sua operação. As informações completas sobre os métodos para encerrar a execução do script e o comportamento relacionado estão disponíveis na documentação.
Transações Redis e scripts Lua de longa duraçãoClique para Tweet
Comportamento em sistemas de alta disponibilidade monitorados pelo Sentinel
Os sistemas de alta disponibilidade gerenciados pelo Sentinel adicionam um novo problema. Na verdade, essa discussão se aplica a qualquer sistema de alta disponibilidade que dependa da pesquisa de integridade dos servidores Redis:
- Scripts de longa duração bloquearão inicialmente os comandos do cliente. Mais tarde, quando o 'lua-time-limit' tiver passado, o servidor começará a responder com erros BUSY.
- Os Sentinels considerarão esse nó como indisponível e, se isso persistir além do valor de inatividade após milissegundos configurado nos Sentinels, eles determinarão que o nó está inativo.
- Se esse nó for o mestre, um failover será iniciado. Um nó de réplica pode ser promovido e começar a aceitar novas conexões de clientes.
- Enquanto isso, o mestre mais antigo terminará de executar o script e voltará a ficar online. No entanto, o Sentinel eventualmente o reconfigurará como uma réplica e começará a sincronizar com o novo mestre. Quaisquer dados escritos pelo script serão perdidos.
|
Demonstração
Configuramos um sistema de alta disponibilidade sensível para demonstrar esse comportamento de failover. A configuração tem 2 servidores Redis em execução em uma configuração mestre/réplica que está sendo monitorada por um quórum de 3 sentinelas.
O valor lua-time-limit foi definido como 500 ms para que comece a responder aos clientes com erros se um script for executado por mais de 500 ms. O valor down-after-milliseconds nos Sentinels é definido como 5 segundos para que um nó que relata erros seja marcado como DOWN após 5 segundos.
Executamos o seguinte script Lua no mestre:
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
Isso continua gravando entradas no mestre Redis. Subscrevemos os eventos em uma das sentinelas para observar o comportamento.
O script é iniciado no mestre:
$ redis-cli -a --eval test.lua Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
Aqui está uma sequência truncada de atividades como visto no 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"
Mais tarde, quando o antigo mestre é colocado online, ele é alterado para uma réplica:
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"
Todos os dados gravados no antigo mestre por meio do script são perdidos.
Recomendações
- Você deve conhecer as características de seus scripts de longa duração antes de implantá-los na produção.
- Se seu script violar regularmente o limite de tempo de lua, você deve revisar o script completamente para possíveis otimizações. Você também pode dividi-lo em partes que terminam em durações aceitáveis.
- Se você precisar executar scripts que violam o limite de tempo de lua, considere agendar esses scripts durante períodos em que a atividade de outros clientes seja baixa.
- O valor de lua-time-limit também pode ser aumentado. Essa seria uma solução aceitável se outros aplicativos cliente executados em paralelo com o script pudessem tolerar receber respostas extremamente atrasadas em vez de um erro BUSY e tentar novamente mais tarde.
Considerações adicionais sobre sistemas de alta disponibilidade monitorados pelo Sentinel:
- Se os scripts estiverem realizando apenas operações de leitura e você tiver réplicas disponíveis, poderá mover esses scripts para as réplicas.
Altere o parâmetro Sentinel down-after-milliseconds para um valor que garanta que os failovers não sejam iniciados. Você deve fazer isso somente após uma análise cuidadosa, pois aumentar o valor drasticamente comprometerá as características de alta disponibilidade do seu sistema. Isso também pode fazer com que falhas genuínas do servidor sejam ignoradas.
|
