Consistência eventual - Eventual consistency
Consistência eventual é um modelo de consistência usado na computação distribuída para atingir alta disponibilidade que garante informalmente que, se nenhuma nova atualização for feita em um determinado item de dados, eventualmente todos os acessos a esse item retornarão o último valor atualizado. A consistência eventual, também chamada de replicação otimista , é amplamente implantada em sistemas distribuídos e tem origens nos primeiros projetos de computação móvel. Geralmente, diz-se que um sistema que atingiu a consistência eventual convergiu ou alcançou a convergência da réplica . A consistência eventual é uma garantia fraca - a maioria dos modelos mais fortes, como a linearizabilidade , são trivialmente eventualmente consistentes.
Os serviços eventualmente consistentes são frequentemente classificados como fornecendo semântica BASE (basicamente disponível, soft-state, consistência eventual), em contraste com o ACID tradicional (atomicidade, consistência, isolamento, durabilidade) . Na química, uma base é o oposto de um ácido, o que ajuda a lembrar a sigla. De acordo com o mesmo recurso, estas são as definições aproximadas de cada termo em BASE:
- Basicamente disponível : as operações de leitura e gravação estão disponíveis tanto quanto possível (usando todos os nós de um cluster de banco de dados), mas podem não ser consistentes (a gravação pode não persistir após os conflitos serem reconciliados, a leitura pode não obter a gravação mais recente)
- Soft-state : sem garantias de consistência, após algum tempo, só temos alguma probabilidade de conhecer o estado, uma vez que pode ainda não ter convergido
- Eventualmente consistente : se executarmos algumas gravações e, em seguida, o sistema funcionar por tempo suficiente, podemos saber o estado dos dados; qualquer leitura posterior desse item de dados retornará o mesmo valor
A consistência eventual é às vezes criticada por aumentar a complexidade dos aplicativos de software distribuídos. Em parte, isso ocorre porque a consistência eventual é puramente uma garantia de vitalidade (as leituras eventualmente retornam o mesmo valor) e não garante a segurança : um sistema eventualmente consistente pode retornar qualquer valor antes de convergir.
Resolução de conflitos
Para garantir a convergência da réplica, um sistema deve reconciliar as diferenças entre várias cópias de dados distribuídos. Isso consiste em duas partes:
- troca de versões ou atualizações de dados entre servidores (frequentemente conhecido como anti-entropia ); e
- escolher um estado final apropriado quando ocorreram atualizações simultâneas, chamado de reconciliação .
A abordagem mais apropriada para a reconciliação depende do aplicativo. Uma abordagem comum é "o último escritor vence" . Outra é invocar um manipulador de conflitos especificado pelo usuário. Os timestamps e os relógios vetoriais costumam ser usados para detectar a simultaneidade entre as atualizações. Algumas pessoas usam "ganha o primeiro escritor" em situações em que "ganha o último escritor" é inaceitável.
A reconciliação de gravações simultâneas deve ocorrer algum tempo antes da próxima leitura e pode ser agendada em diferentes instantes:
- Reparo de leitura: a correção é feita quando uma leitura encontra uma inconsistência. Isso retarda a operação de leitura.
- Reparo de gravação: A correção ocorre durante uma operação de gravação, se uma inconsistência for encontrada, tornando a operação de gravação mais lenta.
- Reparo assíncrono: a correção não faz parte de uma operação de leitura ou gravação.
Consistência forte eventual
Considerando consistência eventual é apenas uma liveness garantia (atualizações serão observados eventualmente), forte consistência eventual (SEC) adiciona a segurança garantia de que quaisquer dois nós que receberam o mesmo conjunto (não-ordenada) de atualizações estarão no mesmo estado. Se, além disso, o sistema for monotônico , a aplicação nunca sofrerá rollbacks. Uma abordagem comum para garantir a SEC é os tipos de dados replicados livres de conflitos .