Como implementar bloqueio distribuído (2016)

Como implementar bloqueio distribuído

• O autor encontrou o algoritmo Redlock no site do Redis, que afirma implementar um bloqueio distribuído tolerante a falhas sobre o Redis.
• Já existem várias implementações independentes do Redlock, e como pode haver pessoas que dependem desse algoritmo, o autor decidiu compartilhar suas observações.
• O Redis é útil para compartilhar entre servidores dados temporários e que mudam rapidamente, mas é preocupante expandi-lo para o gerenciamento de dados que exige consistência forte e durabilidade.

Objetivo do bloqueio

• O bloqueio serve para garantir que apenas um entre vários nós execute uma determinada tarefa.
• Quando o bloqueio é usado por eficiência, pode ser melhor usar uma única instância do Redis.
• Quando o bloqueio é usado por correção, o Redlock não é adequado.

Protegendo recursos com bloqueio

• O bloqueio em sistemas distribuídos é diferente de um mutex em aplicações multithread.
• Ele impede que outro cliente execute a mesma operação enquanto um cliente lê um arquivo, o modifica e depois o grava novamente.

Implementando bloqueio seguro com fencing

• É possível implementar um bloqueio seguro usando tokens de fencing e incluindo-os nas requisições de escrita.
• O Redlock não é seguro porque não tem a capacidade de gerar tokens de fencing.

Uso do tempo para consenso

• O Redlock, diferentemente de algoritmos no modelo assíncrono, faz muitas suposições sobre o tempo.
• Se o relógio do sistema se comportar de forma anormal, a expiração da chave pode ocorrer mais cedo ou mais tarde do que o esperado.

Quebrando as suposições de tempo do Redlock

• O Redlock assume um modelo de sistema síncrono e só funciona corretamente quando atraso de rede, pausas de processo e erros de relógio são limitados.
• Casos como o incidente de atraso de pacotes de 90 segundos no GitHub podem ameaçar a segurança do Redlock.

Conclusão

• O Redlock é desnecessariamente pesado para bloqueios voltados à otimização de eficiência e não é seguro o suficiente para situações que exigem correção.
• Se for necessário um bloqueio por correção, é melhor usar um sistema de consenso apropriado, como o ZooKeeper.

Resumo do GN⁺

• O algoritmo Redlock oferece uma discussão importante sobre a implementação de bloqueios em sistemas distribuídos.
• Este texto destaca os problemas de segurança e as suposições de tempo em sistemas distribuídos, explicando a importância de uma implementação correta de bloqueio.
• Recomenda sistemas alternativos, como o ZooKeeper, e ajuda a entender a complexidade dos sistemas distribuídos.

[GN⁺]

Comentários do Hacker News

• Já implementei bloqueio distribuído usando Temporal, e até agora tem funcionado bem. Aproveitando os recursos do Temporal, a implementação do bloqueio distribuído é simples
• Deixei um comentário no blog dizendo que foi ignorado um ponto importante do algoritmo, apontando que ele se baseia em uma fraqueza da rejeição do algoritmo
• Com computadores e APIs modernos, é possível fazer esperas aproximadas de tempo; pausas de GC são limitadas e relógios monotônicos funcionam. Essa é uma premissa aceitável
• Criticar o mecanismo de liberação automática é uma questão diferente de criticar os objetivos do algoritmo e o modelo do sistema
• O Redlock tem sido usado com sucesso em vários casos de uso, e com timeouts configurados adequadamente é difícil provocar condições de corrida. Configurar timeouts muito curtos é um erro de projeto
• Estou atualizando meus conhecimentos de baixo nível e de algoritmos, e quero criar algo por diversão, mas a maior parte do material é de nível de brinquedo ou extremamente complexa
• Implemento bloqueio distribuído usando PostgreSQL: inicio uma transação, obtenho um advisory lock e mantenho o estado de bloqueio até a transação ser liberada
• Percebi que eu não estava verificando o estado da conexão com o banco de dados, e talvez tenha perdido o bloqueio em casos que não envolviam trabalho relacionado ao banco
• Implementei bloqueio distribuído usando Deno e Deno KV, que se baseia no FoundationDB
• Analisei o Redis, mas resolvi a questão da correção usando PostgreSQL para transformar requisições em operações SET
• Muitos engenheiros não consideram os problemas de correção importantes, e existem casos de borda em que mensagens podem ser perdidas ou chegar fora de ordem
• Definir um timeout para o bloqueio é uma boa ideia, e se o cliente travar, o SO ou o supervisor libera o bloqueio
• Quando o bloqueio não é necessário, é possível manter a integridade dos dados usando um token de versão. Pode-se usar um valor único como um UUID