Micheal Haggerty, engenheiro de infraestrutura do GitHub, publicou em um blog explicando como o GitHub criou Spokes, seu sistema de replicação, para funcionar em grandes distâncias. Isso inclui a redução de round trips (viagens de ida e volta), a introdução de um commit em 3 fases three-phase commit (uma confirmação em três fases), otimização de desempenho de atualização e vários outros ajustes.
Haggerty explica que o GitHub exige que os repositórios sejam replicados em data centers para maximizar a resiliência e reduzir a latência. No caso de um desastre, uma réplica precisa estar disponível em outra localização geográfica e, para melhorar o desempenho, a réplica mais próxima precisa ser atendida ao usuário.
O Spokes é o sistema desenvolvido pelo GitHub para executar esta replicação de repositórios de usuários e garantir que eles estejam sincronizados. Ele funciona como um proxy, executando de forma transparente essa replicação no nível do aplicativo Git. Haggerty explica que originalmente exigia que as réplicas estivessem próximas para funcionar, mas ao longo do tempo isso foi superado ao reduzir a latência e otimizar as atualizações.
Um dos problemas originais de distribuir as réplicas em diferentes locais foi o aumento da latência, isso limitaria a taxa máxima de atualizações do Git que o Spokes poderia sustentar. Haggerty ressalta que, embora isso não seja um problema para a maioria dos usuários, certos fluxos de trabalho Git levam a esse requisito como decisivo na utilização ou não:
Bem, a maioria dos usuários não faz o push (envia o código pro servidor) com frequência. Mas se você hospedar quase 70 milhões de repositórios, você descobrirá que alguns projetos usam fluxos de trabalho que você nunca teria previsto. Trabalhamos muito para fazer o GitHub funcionar para todos, exceto os casos de uso mais absurdos.
Ele também explica como o GitHub gera muitas de suas próprias atualizações. Por exemplo, quando o site diz quando um pull request pode ser mergeada ou vai ter que fazer um rebase, ela é baseada em tentativas internas de teste. Além disso, se houver muitos pedidos de pull request contra uma determinada branch, e esse branch for pushada, então cada um desses testes deve ser repetido para todos os pull requests.
Uma maneira de superar a latência foi reduzindo roundtrips da rede, escreve Haggerty. O GitHub faz uso do protocolo de commit em 3 fases para atualizar réplicas e também um bloqueio distribuído para garantir a ordem de atualização correta. Ele explica que isso produz quatro roundtirps(viagens de ida e volta), e que não é muito caro. Eles também pretendem garantir que o trabalho esteja sendo feito enquanto aguarda a conclusão das chamadas de rede.
Haggerty também explica que os engenheiros do GitHub fizeram contribuições de código aberto para o projeto Git. Isso incluiu transações para atualizações, que permitem que as transações sejam comprometidas ou revertidas com base na capacidade das réplicas para realizar uma atualização. Outra foi a aceleração para uma série de atualizações relacionadas à operações próprias.
Para comparar as réplicas, Haggerty explica como o Spokes compara checksums personalizados de cada uma delas. Se eles combinarem, eles contêm o mesmo conteúdo. Os checksums em si também são simples para calcular, em vez de calculá-los a partir do zero, eles são feitos de forma incremental.
As atualizações de "booking keeping" (manutenção de reservas) também gera menos transações. Haggerty explica que isso ajuda em situações em que um único commit poderia causar centenas de booking keepings, mantendo as atualizações de referência, pois uma única pode demorar um terço de segundo.
O blog completo está disponível para ler online, explicando ainda mais o trabalho realizado.