Confirmação atômica - Atomic commit

No campo da ciência da computação , um commit atômico é uma operação que aplica um conjunto de mudanças distintas como uma única operação. Se as alterações forem aplicadas, a confirmação atômica foi considerada bem-sucedida. Se houver uma falha antes que o commit atômico possa ser concluído, todas as alterações concluídas no commit atômico serão revertidas. Isso garante que o sistema sempre seja deixado em um estado consistente. A outra propriedade fundamental do isolamento vem de sua natureza como operações atômicas . O isolamento garante que apenas um commit atômico seja processado por vez. Os usos mais comuns de commits atômicos são em sistemas de banco de dados e sistemas de controle de versão .

O problema com commits atômicos é que eles requerem coordenação entre vários sistemas. Como as redes de computadores são serviços não confiáveis, isso significa que nenhum algoritmo pode coordenar com todos os sistemas, conforme comprovado no Problema dos Dois Gerais . Conforme os bancos de dados se tornam mais e mais distribuídos, essa coordenação aumentará a dificuldade de fazer commits verdadeiramente atômicos.

Uso

Os commits atômicos são essenciais para atualizações de dados em várias etapas. Isso pode ser claramente demonstrado em um exemplo simples de transferência de dinheiro entre duas contas correntes.

Este exemplo é complicado por uma transação para verificar o saldo da conta Y durante uma transação de transferência de 100 dólares da conta X para Y. Para começar, primeiros 100 dólares são removidos da conta X. Em segundo lugar, 100 dólares são adicionados à conta Y. Se a operação inteira não é concluída como um commit atômico, então vários problemas podem ocorrer. Se o sistema falhar no meio da operação, após remover o dinheiro de X e antes de adicionar em Y, então 100 dólares simplesmente desapareceram. Outro problema é se o saldo de Y for verificado antes de adicionar 100 dólares, o saldo incorreto de Y será informado.

Com commits atômicos nenhum desses casos pode acontecer, no primeiro caso de falha do sistema, o commit atômico seria revertido e o dinheiro devolvido para X. No segundo caso, a solicitação do saldo de Y não pode ocorrer até que o atômico o commit está totalmente concluído.

Sistemas de banco de dados

Os commits atômicos em sistemas de banco de dados cumprem duas das principais propriedades do ACID , atomicidade e consistência . A consistência só é alcançada se cada mudança no commit atômico for consistente.

Conforme mostrado no exemplo, as confirmações atômicas são críticas para operações de várias etapas em bancos de dados. Devido ao design de hardware moderno do disco físico no qual o banco de dados reside, os verdadeiros commits atômicos não podem existir. A menor área que pode ser gravada no disco é conhecida como setor. Uma única entrada de banco de dados pode abranger vários setores diferentes. Apenas um setor pode ser gravado por vez. Este limite de gravação é o motivo pelo qual os verdadeiros commits atômicos não são possíveis. Depois que as entradas do banco de dados na memória foram modificadas, elas são enfileiradas para serem gravadas no disco. Isso significa que os mesmos problemas identificados no exemplo voltaram a ocorrer. Qualquer solução algorítmica para este problema ainda encontrará o Problema dos Dois Generais. O protocolo de confirmação de duas fases e o protocolo de confirmação de três fases tentam resolver este e alguns dos outros problemas associados a confirmações atômicas.

O protocolo two-phase commit requer que um coordenador mantenha todas as informações necessárias para recuperar o estado original do banco de dados se algo der errado. Como o nome indica, existem duas fases, votação e confirmação .

Durante a fase de votação , cada nó grava as alterações no commit atômico em seu próprio disco. Os nós, então, relatam seu status ao coordenador. Se algum nó não relatar ao coordenador ou sua mensagem de status for perdida, o coordenador assume que a gravação do nó falhou. Assim que todos os nós reportarem ao coordenador, a segunda fase começa.

Durante a fase de confirmação , o coordenador envia uma mensagem de confirmação para cada um dos nós para registrar em seus logs individuais. Até que esta mensagem seja adicionada ao log de um nó, todas as alterações feitas serão registradas como incompletas. Se algum dos nós relatou uma falha, o coordenador enviará uma mensagem de rollback. Isso removerá todas as alterações que os nós gravaram no disco.

O protocolo de confirmação de três fases busca remover o problema principal com o protocolo de confirmação de duas fases, que ocorre se um coordenador e outro nó falham ao mesmo tempo durante a fase de confirmação e nenhum deles pode dizer qual ação deve ocorrer. Para resolver este problema, uma terceira fase é adicionada ao protocolo. A fase de preparação para confirmação ocorre após a fase de votação e antes da fase de confirmação .

Na fase de votação , semelhante à confirmação de duas fases, o coordenador solicita que cada nó esteja pronto para confirmação. Se algum nó falhar, o coordenador atingirá o tempo limite enquanto espera pelo nó com falha. Se isso acontecer, o coordenador enviará uma mensagem de aborto para cada nó. A mesma ação será realizada se qualquer um dos nós retornar uma mensagem de falha.

Ao receber mensagens de sucesso de cada nó na fase de votação, a fase de preparação para confirmação começa. Durante esta fase, o coordenador envia uma mensagem de preparação para cada nó. Cada nó deve reconhecer a mensagem de preparação e responder. Se alguma resposta for perdida ou algum nó retornar que não está preparado, o coordenador enviará uma mensagem de aborto. Qualquer nó que não receber uma mensagem de preparação antes que o tempo limite expire aborta a confirmação.

Depois que todos os nós tiverem respondido à mensagem de preparação, a fase de confirmação começa. Nesta fase, o coordenador envia uma mensagem de confirmação para cada nó. Quando cada nó recebe essa mensagem, ele executa o commit real. Se a mensagem de confirmação não alcançar um nó devido à perda da mensagem ou falha do coordenador, eles executarão a confirmação se o tempo limite expirar. Se o coordenador falhar na recuperação, ele enviará uma mensagem de confirmação para cada nó.

Controle de revisão

Os commits atômicos são um recurso comum do software de controle de versão e cruciais para manter um estado consistente no repositório. A maioria dos softwares de controle de versão não aplicará nenhuma parte de um commit que falhe. Exceções notáveis ​​são CVS , VSS e IBM Rational ClearCase (quando no modo UCM).

Por exemplo, se o software de controle de versão encontrar um conflito de mesclagem que não possa ser resolvido automaticamente, nenhuma parte do conjunto de alterações será mesclada. Em vez disso, o desenvolvedor tem a oportunidade de reverter suas alterações ou resolver manualmente o conflito.

Isso evita que todo o projeto entre em um estado interrompido devido a um conjunto de mudanças parcialmente aplicado, onde um arquivo de uma confirmação é confirmado com sucesso, mas outro arquivo com mudanças dependentes falha.

Os commits atômicos também podem se referir à capacidade de fazer alterações simultaneamente em vários projetos usando software de controle de versão em uma única operação, usando uma estratégia de desenvolvimento de software de controle de versão conhecida como monorepo .

Convenção de commit atômico

Ao usar um sistema de controle de revisão, uma convenção comum é usar pequenos commits. Às vezes, eles são chamados de commits atômicos, pois (idealmente) afetam apenas um único aspecto do sistema. Esses commits atômicos permitem maior compreensão, menos esforço para reverter as alterações, identificação de bug mais fácil.

A maior compreensibilidade vem do tamanho pequeno e da natureza focada do commit. É muito mais fácil entender o que mudou e raciocinar por trás das mudanças se alguém estiver procurando por apenas um tipo de mudança. Isso se torna especialmente importante ao fazer alterações de formato no código-fonte. Se as mudanças de formato e funcionais forem combinadas, torna-se muito difícil identificar mudanças úteis. Imagine se o espaçamento em um arquivo fosse alterado de tabulações para três espaços, cada tabulação no arquivo mostraria como tendo sido alterada. Isso se torna crítico se algumas mudanças funcionais também forem feitas, pois um revisor pode simplesmente não ver as mudanças funcionais.

Se apenas commits atômicos forem feitos, os commits que introduzem erros se tornam muito mais simples de identificar. Não é necessário examinar cada commit para ver se é a causa do erro, apenas os commits que lidam com essa funcionalidade precisam ser examinados. Se o erro deve ser revertido, os commits atômicos novamente tornam o trabalho muito mais simples. Em vez de ter que reverter para a revisão ofensiva e remover as alterações manualmente antes de integrar quaisquer alterações posteriores; o desenvolvedor pode simplesmente reverter quaisquer mudanças no commit identificado. Isso também reduz o risco de um desenvolvedor remover acidentalmente alterações não relacionadas que estavam no mesmo commit.

Os commits atômicos também permitem que as correções de bug sejam facilmente revisadas se apenas uma única correção de bug for confirmada por vez. Em vez de ter que verificar vários arquivos potencialmente não relacionados, o revisor deve apenas verificar os arquivos e alterações que afetam diretamente o bug que está sendo corrigido. Isso também significa que as correções de bug podem ser facilmente empacotadas para teste, pois apenas as mudanças que corrigem o bug estão no commit.

Veja também

Referências