Conceitos
Fencing tokens e leases
Intuição
Imagine que você empresta a chave de uma sala por um tempo combinado: passado o prazo, a chave deixa de valer e outra pessoa pode receber a sala. O problema é que quem ficou com a chave velha pode não ter percebido que o prazo acabou e entrar mesmo assim. A solução é a sala exigir, a cada entrada, um crachá numerado com o número do turno atual, e recusar crachás de turnos antigos.
Como funciona
Um lease é uma concessão com prazo: a posse do dono só vale enquanto o prazo não expira, e precisa renová-lo periodicamente. No Chubby, o master de uma célula é eleito por maioria das réplicas, que prometem não eleger outro durante alguns segundos (o master lease), renovado enquanto ele continuar vencendo a votação; por isso o master pode responder leituras sozinho, já que nenhum outro master pode existir enquanto o lease vale. A relação entre cliente e célula também é um lease de sessão, estendido pelas respostas aos KeepAlives (12 s por padrão); se o lease local expira, o cliente entra em jeopardy e espera um período de graça (45 s por padrão) antes de dar a sessão por perdida. Só o prazo, porém, não protege contra mensagens atrasadas ou fora de ordem, que podem fazer um processo que já perdeu o lock agir indevidamente. Por isso o Chubby oferece o sequencer: uma cadeia opaca de bytes com o nome do lock, o modo e um número de geração, obtida logo após a aquisição. O cliente a anexa às requisições, e o servidor do recurso verifica se ela ainda é válida, rejeitando quem segura uma geração antiga; essa é a ideia do fencing token. Para servidores que não verificam sequencers, o Chubby usa o lock-delay, um mecanismo imperfeito: se o lock é liberado porque o dono falhou ou ficou inacessível, ninguém pode pegá-lo por um período limitado a no máximo um minuto (valor da época). No ZooKeeper, a presença do dono é atrelada à sessão por meio de znodes efêmeros, removidos quando a sessão termina, e o lock usa znodes efêmeros sequenciais, em que quem tem o menor número detém o lock.
Na prática
Eleição de líder e locks distribuídos aparecem assim em sistemas reais: no Chubby, o GFS usa um lock para designar seu master e o Bigtable o usa para eleger o master; o ZooKeeper vem sendo usado para eleição de líder e detecção de falhas em sistemas como Hadoop e HBase. Ao projetar um lock com lease, não confie só no prazo: faça o recurso protegido validar o token ou a geração a cada operação e, se isso não for possível, use um atraso após a liberação como defesa parcial. Lembre também que o lock do Chubby é consultivo, então a proteção só vale se os servidores efetivamente checarem o token.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.