Locks distribuídos e leases de líder: expiração, fencing tokens e o que um lock não consegue garantir

O que é

Um lock distribuído é um lease: o cliente adquire o direito exclusivo sobre um nome por um tempo limitado e precisa renová-lo antes que expire. A documentação do Kubernetes (citada) descreve os objetos Lease do grupo de API coordination.k8s.io, usados para heartbeats de nós e para a eleição de líder de componentes do control plane. A documentação do Redis (citada) apresenta o Redlock como uma proposta de algoritmo de lock com várias instâncias e convida à sua análise. No aviso sobre consistência, ela diz que fencing tokens devem ser implementados e que o Redis não usa um relógio monotônico para a expiração de chaves.

A análise de Kleppmann (citada) destaca o ponto central: depois de adquirir o lease, um cliente pode sofrer uma pausa (garbage collection, page faults, disputa de CPU, um pacote atrasado). O lease expira, um segundo cliente o adquire, e o primeiro cliente retoma a execução e escreve como se ainda detivesse o lock. Nenhum serviço de lock consegue evitar isso sozinho. A solução é um fencing token: um número que aumenta a cada concessão do lock e é enviado em toda escrita ao recurso protegido, que rejeita qualquer escrita com um token menor do que um já visto. O zxid ou a versão de um znode do ZooKeeper pode servir como esse token; Kleppmann observa que o Redlock não tem nenhum mecanismo para gerá-lo.

Por que importa

Kleppmann distingue locks por eficiência (evitar executar duas vezes o mesmo trabalho caro; uma duplicata ocasional é inofensiva) de locks por correção (uma duplicata corrompe dados ou cobra em dobro). Com frequência, as equipes implantam o primeiro tipo e passam a depender dele como se fosse o segundo.

Como aplicar

• Decida de qual tipo de lock você precisa. Para eficiência, basta um único armazenamento de locks com TTL e um token de dono na liberação.
• Para correção, obtenha do serviço de lock um token monotonicamente crescente (a revisão de um armazenamento baseado em consenso, ou uma sequence de banco de dados atualizada na mesma transação) e faça o recurso verificá-lo: uma coluna de fence com um UPDATE ... SET fence = $held WHERE fence <= $held condicional (zero linhas atualizadas significa que o lease foi perdido), ou uma API de armazenamento com escritas condicionais.
• Defina o intervalo de renovação bem abaixo da duração do lease e interrompa o trabalho imediatamente quando uma renovação falhar; não "termine primeiro o item atual".
• Libere o lock somente com o token que você detém, para que um detentor expirado não libere o lease do sucessor.
• Prefira tornar o trabalho idempotente a bloqueá-lo; o lock passa então apenas a reduzir esforço desperdiçado.

Armadilhas

A duração de um lease é uma suposição baseada no relógio de parede sobre quanto tempo um processo pode ficar pausado, e as pausas não têm limite superior. Um lock que protege um recurso sem verificação de token é uma dica, não uma garantia. Um runner de cron singleton cujo "só uma instância executa" é imposto por um lock ainda precisa de jobs idempotentes.