Na Conferência Internacional da IEEE sobre Engenharia de Dados (ICDE) 2019, os engenheiros do eBay apresentaram um documento sobre um protocolo para transações distribuídas ACID usando múltiplas bases de dados, GRIT. O suporte a vários bancos de dados é essencial para permitir o uso do GRIT a microservices, que geralmente são implementados em diferentes idiomas e podem usar vários bancos de dados subjacentes.
O GRIT visa preencher uma lacuna nas tecnologias existentes para transações ACID, que não podem ser facilmente estendidas no caso de vários bancos de dados, segundo os engenheiros do eBay.
Em ambientes que envolvem vários bancos de dados independentes, o protocolo tradicional two-phase commit (2PC) era essencialmente a única opção para transações distribuídas pelo sistema sem esforço adicional na aplicação. No entanto, não funciona bem em uma plataforma que precisa escalar, devido aos longos caminhos de potencialmente muitos participantes coordenando e ao bloqueio necessário ao longo das fases. Por outro lado, o uso de um log de transações executado por uma estrutura como o Saga incorrerá em lógica de compensação complexa por aplicativos e poderá ter implicações nos negócios devido a transações parcialmente bem-sucedidas irreversíveis.
A arquitetura GRIT é exibida na figura a seguir no contexto de uma aplicação em microservice com duas bases de dados.
Como mostra a imagem acima, o GRIT inclui dois blocos principais: um grupo de componentes específicos para cada banco de dados - um Database Transaction Manager (DBTM), um Database Transaction Log (DBTL) e um LogPlayer para cada banco de dados - e dois componentes globais responsáveis pela coordenação - o Global Transaction Manager (GTM) e o Global Transaction Log (GTL).
Uma transação GRIT ocorre em três fases. Durante a execução de uma transação, os serviços de banco de dados coletam o conjunto de leitura e gravação da transação, sem modificar nenhum dado. Quando a transação é confirmada, cada banco de dados envia seu conjunto de leitura e gravação para seu DBTM, que toma uma decisão de confirmação local analisando-os. Todos os DBTM envolvidos enviam suas decisões locais ao GTM, que toma a decisão de confirmação global. Por fim, se a transação for bem-sucedida, os LogPlayers enviarão as entradas coletadas no DBTL para os bancos de dados, que armazenam os dados.
No geral, nossa abordagem evita bloqueios pessimistas durante o processo de execução e confirmação e evita a espera de confirmação física. Adotamos a abordagem otimista e também tornamos o processo de confirmação muito eficiente, aproveitando os logs lógicos de confirmação e removendo as alterações físicas do banco de dados do processo de decisão de confirmação com a tecnologia determinística do banco de dados, que é semelhante à reprodução de log na replicação.
Vale ressaltar que o GRIT também pode ser aplicado a aplicações com um único banco de dados. Nesses casos, os componentes globais não são necessários e a transação de confirmação é de menor complexidade. Os engenheiros do eBay mostram uma configuração GRIT destinada a estender um banco de dados existente para suportar transações ACID em várias zonas de disponibilidade. Não perca o post original se estiver interessado em todos os detalhes.