O Teorema CAP e Modelos de Consistência

O teorema CAP afirma que um armazenamento de dados distribuído que enfrenta uma partição de rede deve sacrificar a consistência ou a disponibilidade, e os modelos de consistência especificam exatamente quais garantias um sistema oferece sobre a visibilidade e a ordenação das atualizações.

Definition

O teorema CAP afirma que um sistema de dados compartilhados em rede pode garantir no máximo dois de consistência, disponibilidade e tolerância a partição simultaneamente; um modelo de consistência é um contrato que especifica o que uma aplicação pode observar sobre a ordem e a visibilidade de leituras e escritas entre réplicas.

Scope

Este tópico abrange o teorema CAP e sua formalização, a leitura prática de que o verdadeiro trade-off surge apenas durante partições de rede, e o refinamento PACELC resultante. Abrange o espectro de modelos de consistência — desde a consistência forte (linearizável) passando pela consistência causal até a consistência eventual — e o estilo BASE que contrasta com ACID. Trata de como esses modelos guiam o design de armazenamentos de dados replicados. Exclui os protocolos de consenso e commit usados para implementar consistência forte, que são abordados em bancos de dados distribuídos.

Core questions

• O que exatamente significam consistência, disponibilidade e tolerância a partição no CAP?
• Por que a escolha real entre consistência e disponibilidade é forçada apenas durante uma partição?
• Como a consistência forte, causal e eventual diferem em suas garantias?
• O que a consistência eventual promete e o que não promete?
• Como a filosofia BASE contrasta com ACID?

Key concepts

• consistência, disponibilidade, tolerância a partição
• partição de rede
• linearizabilidade / consistência forte
• consistência causal
• consistência eventual
• PACELC
• BASE versus ACID
• resolução de conflitos

Key theories

O teorema CAP

Formalizado por Gilbert e Lynch, o CAP mostra que, quando a rede se particiona, um armazenamento replicado deve escolher entre retornar dados possivelmente desatualizados (disponibilidade) e recusar o serviço para preservar um único valor consistente (consistência); a tolerância a partição não é opcional em redes reais.

Espectro de consistência

Os modelos de consistência variam desde a consistência forte (linearizável), onde as leituras sempre veem a escrita mais recente, passando pela consistência causal, que preserva a ordem de causa e efeito, até a consistência eventual, onde as réplicas convergem ao longo do tempo na ausência de novas escritas.

BASE versus ACID

Sistemas altamente disponíveis frequentemente adotam um estilo BASE — basicamente disponível, estado flexível (soft state), eventualmente consistente — relaxando deliberadamente as fortes garantias ACID para permanecer responsivos sob partições e em escala.

Clinical relevance

Os modelos CAP e de consistência enquadram a escolha central de design em sistemas de dados distribuídos: se um armazenamento prioriza sempre responder (disponibilidade) ou sempre responder corretamente (consistência) quando a rede falha, uma decisão que molda o comportamento e as garantias de cada aplicação distribuída globalmente.

History

Eric Brewer conjecturou o trade-off CAP por volta de 2000; Gilbert e Lynch o provaram formalmente em 2002. O Dynamo da Amazon (2007) e o ensaio de Vogels de 2009 popularizaram a consistência eventual na prática. A retrospectiva de Brewer de 2012 esclareceu que o CAP proíbe consistência e disponibilidade perfeitas apenas durante partições, e a formulação PACELC adicionou posteriormente o trade-off latência-consistência no caso sem partição.

Debates

Quão fundamental é o trade-off consistência-disponibilidade

Leituras iniciais tratavam o CAP como impondo uma escolha permanente entre consistência e disponibilidade; análises posteriores, incluindo a retrospectiva de Brewer, argumentam que o trade-off só se manifesta durante partições e que os sistemas podem ser amplamente consistentes e disponíveis de outra forma, reformulando quão estritamente o CAP restringe o design.

Key figures

• Eric Brewer
• Seth Gilbert
• Nancy Lynch
• Werner Vogels

Seminal works

• gilbert2002
• brewer2012
• vogels2009

Frequently asked questions

O CAP significa que só posso ter duas das três propriedades?

A frase popular 'escolha duas' é enganosa. A tolerância a partição não é realmente opcional em um sistema distribuído, então a escolha genuína é entre consistência e disponibilidade, e essa escolha só precisa ser feita enquanto uma partição está realmente ocorrendo. Quando a rede está saudável, um sistema pode fornecer consistência e disponibilidade.

O que a consistência eventual realmente garante?

Ela garante que, se nenhuma nova atualização for feita em um item de dados, todas as réplicas eventualmente convergirão para o mesmo valor. Não garante quando, nem que uma leitura refletirá a escrita mais recente, então as aplicações que usam consistência eventual devem tolerar leituras temporariamente desatualizadas ou conflitantes e frequentemente lidar com a resolução de conflitos por conta própria.