Teorema CAP

Teorema CAP

No mundo em que vivemos hoje, recebendo, a cada dia, uma avalanche de tecnologias, é difícil parar para entender os porquês de cada coisa e como cada mecanismo funciona. Muitas vezes, quando nos é solicitado o desenvolvimento de um sistema, o cliente sempre vai desejar receber tudo o que ele imagina que seja possível desenvolver - dentro da sua inocência e desconhecimento do funcionamento de cada um dos componentes que são responsaveis por fazer funcionar um sistema. Mas onde está a relação do Teorema CAP com o que o cliente está solicitando?

É isso que vamos tratar neste post de hoje, mas antes gostaria de esclarecer a diferença entre Teoria e Teorema:

Teoria, do grego θεωρία , é o conhecimento descritivo puramente racional. O substantivo theoría significa ação de contemplar, olhar, examinar, especular. Também pode ser entendido como forma de pensar e entender algum fenômeno a partir da observação. Na Grécia antiga, teoria significava "festa solene, procissão ou embaixada que as cidades helênicas enviavam para representá-las nos jogos olímpicos ou para consultar os oráculos".

Na matemática, um Teorema é uma afirmação que pode ser provada como verdadeira, por meio de outras afirmações já demonstradas, como outros teoremas, juntamente com afirmações anteriormente aceitas, como axiomas. Prova é o processo de mostrar que um teorema está correto. O termo teorema foi introduzido por Euclides, em Elementos, para significar "afirmação que pode ser provada". Em grego, originalmente significava "espetáculo" ou "festa". Atualmente, é mais comum deixar o termo "teorema" apenas para certas afirmações que podem ser provadas e de grande "importância matemática", o que torna a definição um tanto subjetiva.

Bom, agora que já sabemos a diferença entre as duas palavras, vamos ao que interessa. CAP é um Teorema, o qual foi criado por Dr. Eric Brewer, pela ACM - Association for Computing Machinery, no qual descreve o comportamento de um sistema distribuido. Seu comportamento, elucida uma coleção de nós interconectados que compartilham todos os dados.

Esse comportamento, mostra que uma aplicação cliente pode se conectar, primeiramente, com um dos nós que estão interconectados para uma ação de escrita e, em seguida, conectar-se com o mesmo nó ou com outro nó diferente do primeiro para efetuar uma leitura de dados. Ou seja, o Teorema CAP fala sobre a reação de sistemas distribuidos quando eles tem a necessidade de requisitar um comando de escrita, seguido de uma requisição de leitura de dados.

O Teorema CAP afirma que, um dado par de requisições, uma escrita seguida por uma leitura, em um panorama de sistemas distribuídos, promete garantir que apenas 2 entre os 3 comportamentos presentes no Teorema.

Um sistema distribuido, em sua concepção, pode trabalhar com apenas 2 comportamentos, mas nunca com os 3 ao mesmo tempo.

Consistency (Consistência)

Esse comportamento significa que o sistema garante a leitura do dado mais atualizando, quanto ele foi escrito. Isso significa que, o cliente pode ler o dado no mesmo nó que este dado foi escrito ou de um nó diferente, o mesmo dado será retornado para a aplicação cliente. Mesmo que alguém tenha mudado o estado do domínio da aplicação com novas informações, o comportamento de consistência, garantirá que o cliente não verá dados velhos, apenas os novos dados serão visualizados.

Availability/Scalability (Disponibilidade / Escalabilidade)

O comportamento de Disponibilidade, significa que quando o cliente lê ou escreve um dados em um dos nós, o nó que está sendo utilizado pelo cliente, pode estar indisponível. O que aconceteria (ou acontece) na maioria dos sistemas? Na maioria dos sistemas aparece um erro com a famosa frase: O sistema encontra-se indisponível no momento. Retorne mais tarde! Esta é uma frase interessante e que retorna um feedback (retorno) par ao usuário final da aplicação, porém não é algo que o usuário tem que se preocupar, certo? Afinal, ele só precisa ler ou enviar comandos de escrita para que a aplicação possa executar. Sendo assim, nenhuma das requisições pode retornar um erro e, muito menos deixar o usuário da aplicação aguardando indefinidamente, até que o sistema volte.

Isso não quer dizer que um nó não pode falhar, o que esse comportamento quer dizer é que, um nó pode sim ficar offline/cair/falhar, mas o sistema/aplicação continuaria disponível. Ou seja, isso significa que, se um sistema é capaz de obter acesso de leitura/escrita em um nó que não possui falhas e este responde em um tempo razoável, temos aqui a garantia de disponibilidade.

Partition Tolerance (Tolerância a Partição de Rede / Tolerância a Falhas)

Esse comportamento significa que o sistema continua operando, mesmo que aconteça alguma falha na rede (quebra de conectividade). Isso garante que, Por exemplo: Temos um banco de dados distribuido em alguns nós da rede (Ex.: 10 NÓS) e, estes nós, estão ligados através de um cluster. Caso uma das partes do cluster falhe, o sistema continuaria operando sem nenhuma falha, porque a outra parte, que se encontra operacional do cluster, garantirá que, pelo menos, as operações de leitura, continue funcionando normalmente.

Tipos de combinações CAP

1º) CA

Sistemas que implementam este tipo de abordagem, normalmente necessitam de forte consistência e altíssima disponibilidade. Quando um sistema implementa esse tipo de abordagem, isso representa um risco para a aplicação que não sabe lidar com falhas em algum dos nós. Caso essa falha aconteça, o sistema fica indisponível até que os membros do cluster se reestabeleçam novamente.

Esse tipo de abordagem é chamda de Otimista, ou seja: Escritas NUNCA falham.

Exemplos de sistemas implementados com esta abordagem: SQL Server, Oracle, Postgre, MySQL e outros banco de dados relacionais.

2º) AP

Sistemas que implementam este tipo de abordagem, onde requer alta disponibilidade e escalabilidade e tolerância a particionamento, precisa abrir mão da consistência e aplicar o conceito chamando: Consistência Eventual (Eventual-Consistency). A intenção desse tipo de implementação é que esse tipo de sistemas permitam mais escritas e tenham seus dados sincronizados em um momento posterior; o que pode ter uma janela tempo de inconsistência. Aqui vão alguns Bancos de dados NoSQL que implementam esse tipo de comportamento: MongoDB, Cassandra, Riak, Voldemort, RavenDB, DocumentDB.

3º) CP

Abordagem pessimista, o que significa dizer que: Escritas PODEM ser negadas. Sistemas que optam por essa estratégia, precisam abrir mão da disponibilidade - mesmo que seja um pouco. Existe uma palavra, bastante importante nesse contexto, chamada: Conscenso. Em sistemas do tipo CP, caso exista um particionamento e o sistema não entre num conscenso, a escrita - como mencionado anteriormente, pode sim ser rejeitada/negada. Há um forte trabalho feito nas plataformas que implementam essa abordagem, para que nada de errado aconteça ou seja, há a implementação de protocolos de conscenso chamado: Praxos, garantindo a Forte Consistência. Exemplos desses tipos de sistemas são: MongoDB, Hadoop.

As três variações, advindas do Teorema CAP, podem ser aplicadas em cenários do mundo real, ou seja, nos seus sistemas do dia a dia. Assimilados esses conceitos, abordagens e formas de implementações, sabendo quais são os Tradeoff's de cada uma das variações. Você será capaz, de ofertar melhores soluções para os seus clientes.

Espero que este post te seja útil.

Quer continuar o bate-papo sobre Design de Software, Arquitetura de Soluções, Arquitetura de Sistemas, Código Limpo, Domain-Driven-Design? Deixe seu comentário e vamos enriquecer o bate-papo.

Comments