Conceitos
TrueTime e consistência externa
Intuição
Imagine um cartório com filiais em vários continentes, cada uma com seu relógio de parede, e nenhum deles marca exatamente a mesma hora. Para carimbar documentos de modo que a ordem dos carimbos sempre bata com a ordem real em que as coisas aconteceram, cada filial admite que seu relógio tem uma margem de erro conhecida, algo como 'agora são 10h00, com erro de até 4 milésimos de segundo para mais ou para menos'. Depois de carimbar, ela espera o tempo da margem passar antes de avisar que terminou. Assim, qualquer documento que comece depois desse aviso, em qualquer filial do mundo, vai receber um carimbo posterior. O custo é uma pequena espera a cada carimbo, e o ganho é que a ordem dos carimbos nunca contradiz a realidade.
Como funciona
O Spanner garante consistência externa, equivalente a linearizabilidade: se a transação T1 faz commit antes de T2 começar, o timestamp de commit de T1 é menor que o de T2, mesmo quando as transações são distribuídas. A base é a API TrueTime, que representa o tempo como um intervalo de incerteza limitada. TT.now() devolve um TTinterval com extremos earliest e latest, garantidos de conter o tempo absoluto da chamada, e TT.after(t) e TT.before(t) dizem se t definitivamente já passou ou ainda não chegou. O intervalo vem de time masters com GPS e relógios atômicos, que têm modos de falha diferentes, e de um daemon em cada máquina que consulta vários masters e anuncia uma incerteza que cresce entre sincronizações (em produção, epsilon fica em torno de 1 a 7 ms, média perto de 4 ms). Duas regras sustentam a garantia. Na regra Start, o líder coordenador atribui à escrita um timestamp de commit não menor que TT.now().latest. Na regra Commit Wait, o coordenador só deixa clientes enxergarem os dados quando TT.after(timestamp de commit) é verdadeiro, ou seja, quando o timestamp já está garantidamente no passado. A espera esperada é de pelo menos duas vezes a incerteza média e costuma se sobrepor à comunicação do Paxos. Cada tablet é replicado por um grupo Paxos. Transações em um único grupo usam só o líder, e transações em vários grupos usam commit em duas fases (2PC) entre os líderes: cada participante registra via Paxos um prepare, o coordenador escolhe o timestamp final, espera o commit wait e registra o commit. Como todo timestamp respeita a ordem de serialização, leituras somente leitura e de snapshot rodam em um timestamp sem locks, em qualquer réplica cujo safe time já o alcançou. Se a incerteza aumenta, o sistema fica mais lento por esperar mais, mas continua correto.
Na prática
É a escolha para bancos globais que precisam de transações e ordem real preservada entre regiões, como o F1, o backend de anúncios do Google, que usa cinco réplicas em duas costas dos EUA e relata failover quase invisível. Em troca, você paga latência de escrita (cerca de 14 ms nos benchmarks do paper), infraestrutura de relógios com GPS e relógios atômicos, e uma recuperação de cerca de 10 segundos se uma zona inteira cair, ligada à duração dos leases dos líderes. Ao contrário das garantias fracas aceitas em sistemas como o GFS, aqui a coordenação cara é assumida de propósito para evitar que a aplicação tenha que lidar com anomalias de ordem.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.