Teorema da CAP - Disponibilidade e tolerância a partições


207

Enquanto tento entender a "Disponibilidade" (A) e "Tolerância de partição" (P) no CAP, achei difícil entender as explicações de vários artigos.

Tenho a sensação de que A e P podem andar juntos (sei que não é esse o caso, e é por isso que não entendo!).

Explicando em termos simples, o que são A e P e a diferença entre eles?


1
aqui está um artigo que explica CAP na planície Inglês ksat.me/a-plain-english-introduction-to-cap-theorem
Tushar Saha

2
não vá para as perguntas prontas. Leia, visualize e compreenda cada C, A, P separadamente. Projete uma arquitetura de cluster distribuído (talvez 3 DB) e agora aplique seu entendimento. Veja o que acontece com C, A, P quando ocorrem falhas dos distribuídos (DBs). Depois de entender, verifique as respostas e aplique com sua lógica. Lembre-se - Mesmo que você entenda, pode não estar claro. então, pense e aplique sua compreensão. Obrigado
Maiden

1
De alguma forma, o link acima do ksat.me vai para o URL 404, porque termina com '/'. ksat.me/a-plain-english-introduction-to-cap-theorem Isso funciona bem e é uma explicação muito detalhada de cada um dos 'C', 'A', 'P'
vivek.m

Respostas:


402

Consistência significa que os dados são iguais no cluster, para que você possa ler ou gravar de / para qualquer nó e obter os mesmos dados.

Disponibilidade significa a capacidade de acessar o cluster, mesmo se um nó no cluster ficar inativo.

Tolerância de partição significa que o cluster continua funcionando mesmo se houver uma "partição" (quebra de comunicação) entre dois nós (os dois nós estão ativos, mas não podem se comunicar).

Para obter disponibilidade e tolerância à partição, você precisa renunciar à consistência. Considere se você possui dois nós, X e Y, em uma configuração mestre-mestre. Agora, há uma interrupção entre a comunicação de rede entre X e Y, para que eles não possam sincronizar atualizações. Nesse ponto, você pode:

A) Permitir que os nós fiquem fora de sincronia (perdendo a consistência) ou

B) Considere o cluster "inativo" (desistindo da disponibilidade)

Todas as combinações disponíveis são:

  • CA - os dados são consistentes entre todos os nós - desde que todos os nós estejam online - e você pode ler / gravar em qualquer nó e ter certeza de que os dados são os mesmos, mas se você desenvolver uma partição entre nós, os dados serão fora de sincronia (e não será sincronizada novamente depois que a partição for resolvida).
  • CP - os dados são consistentes entre todos os nós e mantêm a tolerância da partição (impedindo a dessincronização de dados), ficando indisponíveis quando um nó é desativado.
  • Os nós de ponto de acesso permanecem on-line, mesmo que não possam se comunicar e ressincronizam os dados assim que a partição for resolvida, mas você não garante que todos os nós tenham os mesmos dados (durante ou após a partição)

Você deve observar que os sistemas CA praticamente não existem (mesmo que alguns sistemas afirmem existir).


1
No AP, por que não garantimos que todos os nós terão os mesmos dados? Ok, por causa da não temos "C", mas .. isso não está claro para mim ... Eu quero saber por que isso acontece ...
grep

3
@ GREP Desculpe pela resposta tardia. Se você tiver disponibilidade (o cluster não fica inativo) e tolerância à partição (o banco de dados pode sobreviver aos nós que não conseguem se comunicar), não será possível garantir que todos os nós sempre terão todos os dados (consistência), porque os nós estão prontos para aceitar gravações, mas não podem comunicar essas gravações entre si.
precisa

4
Tarde para a festa, mas vale a pena mostrar alguns exemplos em cada categoria, por exemplo. blog.nahurst.com/visual-guide-to-nosql-systems
bitinn

realmente ajudaria a incluir uma ilustração / exemplo simples sobre clusters de nós aqui. é um sistema ou uma tabela de dados / coleções espalhadas por um sistema diferente ou algo mais?
shrotavre

Pragmaticamente, os nós geralmente são sistemas individuais (ou software em execução nesses sistemas) conectados por algum mecanismo de rede.
21718 Chris Heald

43

Considerando P em termos iguais a C e A é um erro, mas a noção '2 de 3' entre C, A, P é enganosa. A maneira sucinta que eu explicaria o teorema do CAP é: "Em um armazenamento de dados distribuído, no momento da partição de rede, você precisa escolher Consistência ou Disponibilidade e não pode obter os dois". Os sistemas NoSQL mais recentes estão tentando se concentrar na disponibilidade, enquanto os bancos de dados ACID tradicionais tiveram um foco maior na consistência.

Você realmente não pode escolher a CA, a partição de rede não é algo que alguém gostaria de ter, é apenas uma realidade indesejável de um sistema distribuído, as redes podem falhar. A questão é que escolha você escolhe para o seu aplicativo quando isso acontece. Este artigo do homem que formulou esse termo pela primeira vez parece explicar isso muito claramente.


18

Aqui está como eu estou discutindo o CAP, principalmente em relação a P.

A CA só é possível se você estiver de acordo com um banco de dados monolítico de servidor único (talvez com replicação, mas todos os dados em um "bloco de falha" - não se considera que os servidores falhem parcialmente).

Se o seu problema exigir dimensionamento, distribuição e multi-servidor, podem ocorrer partições de rede. Você já está solicitando P. Poucos problemas que abordo são passíveis de paradigmas de servidor único sempre (ou, como disse Stonebraker, "distribuir é estaca da mesa"). Se você encontrar um problema de autoridade de certificação, soluções como um RDBMS tradicional sem dimensionamento proporcionam muitos benefícios.

Para mim, raro: passamos a discutir AP vs CP.

Você só escolhe entre as operações AP e CP quando possui uma partição. Se a rede e o hardware estiverem funcionando corretamente, você pega o seu bolo e também o come.

Vamos discutir a distinção AP / CP.

AP - quando houver uma partição de rede, deixe as partes independentes operarem livremente.

CP - quando houver uma partição de rede, desligue os nós ou desautorize leituras e gravações para que ocorram falhas determinísticas.

Eu gosto de arquiteturas que podem fazer as duas coisas, porque alguns problemas são AP e alguns são CP - e alguns bancos de dados podem fazer as duas coisas. Entre as soluções de CP e AP, também existem sutilezas.

Por exemplo, em um conjunto de dados AP, você tem a possibilidade de leituras inconsistentes e geração de conflitos de gravação - esses são dois modos possíveis de AP diferentes. Seu sistema pode ser configurado para AP com alta disponibilidade de leitura, mas não permite conflitos de gravação? Ou seu sistema AP pode aceitar conflitos de gravação, com um sistema de resolução forte e flexível? Você precisará dos dois eventualmente ou poderá escolher um sistema que faça apenas um?

Em um sistema CP, quanta indisponibilidade você obtém com partições pequenas (servidor único), se houver? Maior replicação pode aumentar a indisponibilidade em um sistema CP, como o sistema lida com essas compensações?

Essas são todas as perguntas a serem feitas com CP vs AP.

Uma ótima leitura nesta área no momento é a publicação "12 anos depois" de Brewer. Penso que isto avança o debate da PAC com clareza e recomendo vivamente.

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed


O sistema da CA é realmente confuso. Eu tenho uma pergunta sobre o exemplo da CA de um banco de dados monolítico. Se é apenas um servidor, de onde vem o "A", uma vez que me parece que a falha do servidor mencionado resultará em nenhum serviço disponível?
chaooder

1
Boa pergunta. Os servidores podem ter uma falha no disco, ou até os DIMMs, ou as fontes de alimentação, se forem projetadas para alta disponibilidade. Imagine até estar em várias redes de energia. Você obtém uma disponibilidade cada vez maior, mas nunca existe uma "rede" interna com capacidade para particionar e executar com componentes que discordam. Embora exista mais hardware esotérico (consulte SQL NON-STOP), exemplos de matrizes RAID com falha e retomada de componentes ainda são comuns atualmente e fornecem disponibilidade muito alta em um único servidor.
Brian Bulkowski

13

Teorema da CAP

Consistência:

Uma leitura é garantida para retornar a gravação mais recente (como ACID) para um determinado cliente. Se alguma solicitação ocorrer durante esse período, será necessário aguardar a conclusão da sincronização de dados no (s) nó (s).


Disponibilidade:

todo nó (se não falhou) sempre executa consultas e sempre deve responder às solicitações. Não importa se retorna a cópia mais recente ou não.


Tolerância de partição:

O sistema continuará funcionando quando ocorrerem partições de rede.


Em relação ao AP , a disponibilidade (sempre acessível) pode existir com ( Cassendra ) ou sem tolerância de partição ( RDBMS )

fonte da foto


2

Eu sinto que a tolerância da partição não é explicada bem em nenhuma das respostas, então, para explicar as coisas com mais detalhes, o teorema do CAP significa:

C : (linearidade ou consistência forte) significa aproximadamente

Se a operação B for iniciada após a operação A ser concluída com êxito, a operação B deverá ver o sistema no mesmo estado em que estava na conclusão da operação A ou em um estado mais recente (mas nunca no estado antigo).

A :

“Toda solicitação recebida por um nó [de banco de dados] que não falha no sistema deve resultar em uma resposta [sem erro]”. Não é suficiente para que um nó possa lidar com a solicitação: qualquer nó que não falhe precisa ser capaz de lidar com isso. Muitos dos chamados sistemas "altamente disponíveis" (ou seja, baixo tempo de inatividade), na verdade, não atendem a essa definição de disponibilidade.

P :

Tolerância de partição (terrivelmente nomeada) significa basicamente que você está se comunicando em uma rede assíncrona que pode atrasar ou eliminar mensagens. A Internet e todos os nossos centros de dados possuem essa propriedade, portanto você não tem escolha a esse respeito.

Fonte: Awesome de Martin kleppmann trabalho

Só para dar um exemplo: o Cassandra pode no máximo ser um sistema AP. Mas se você configurá-lo para ler ou gravar com base no Quorum, ele não permanece disponível para CAP (disponível conforme a definição do teorema da CAP) e é apenas o sistema P.


1

Em um simples teorema da CAP, é impossível que um sistema distribuído forneça simultaneamente as três garantias:

insira a descrição da imagem aqui

Consistência

Cada nó contém os mesmos dados ao mesmo tempo

Disponibilidade

Pelo menos um nó deve estar disponível para fornecer dados sempre

Tolerância de partição

Falha no sistema é muito rara

Principalmente, todo sistema pode garantir no mínimo dois recursos, CA, AP ou CP .


0

Consistência - Quando estamos enviando a solicitação de leitura, se estiver retornando resultado, ela deve retornar a gravação mais recente fornecida pela solicitação do cliente. Disponibilidade - Sua solicitação de leitura / gravação deve sempre ser bem-sucedida. Tolerância de partição - Quando houver uma partição de rede (problema para algumas máquinas se comunicarem), o sistema ainda deverá funcionar.

Em uma distribuição, há chances de que a partição de rede ocorra e não podemos evitar o "P" do CAP. Então, escolhemos entre "Consistência" e "Disponibilidade".

http://bigdatadose.com/understanding-cap-theorem/


0

Maneira simples de entender o teorema da PAC:

No caso de partição de rede, é preciso escolher entre disponibilidade perfeita e consistência perfeita.

Escolher consistência significa não poder responder à consulta de um cliente, pois o sistema não pode garantir o retorno da gravação mais recente. Isso sacrifica a disponibilidade.

Escolher disponibilidade significa poder responder à solicitação de um cliente, mas o sistema não pode garantir consistência, ou seja, o valor mais recente escrito. Os sistemas disponíveis fornecem a melhor resposta possível sob a circunstância especificada.

Esta explicação é deste excelente artigo . Espero que ajude.


0

Passei por muitos links, mas nenhum deles poderia me dar uma resposta satisfatória, exceto um.

Por isso, estou descrevendo o CAP em formulações muito simples.

  • Consistência : deve retornar os mesmos dados , independentemente de qual nó ele está vindo.

  • Disponibilidade : o deve responder (deve estar disponível).

  • Tolerância de partição : o cluster deve responder (deve estar disponível), mesmo se houver uma partição (ou seja, falha na rede) entre os nós.

(Também uma razão principal confunde mais é ruim convenção de nomenclatura dela Se eu tivesse razão, eu poderia ter dado. DNC teorema vez: consistência de dados , Nó disponibilidade , cluster Disponibilidade , onde cada um corresponde a consistência , disponibilidade e tolerância Partition respectivamente)

Banco de dados CP: um banco de dados CP oferece consistência e tolerância à partição à custa da disponibilidade. Quando uma partição ocorre entre dois nós, o sistema precisa desligar o nó não consistente (ou seja, torná-lo indisponível) até que a partição seja resolvida.

Banco de dados AP: um banco de dados AP oferece disponibilidade e tolerância de partição à custa da consistência. Quando uma partição ocorre, todos os nós permanecem disponíveis, mas aqueles na extremidade incorreta de uma partição podem retornar uma versão mais antiga dos dados que outros. (Quando a partição é resolvida, os bancos de dados AP normalmente ressincronizam os nós para reparar todas as inconsistências no sistema.)

Banco de dados da CA: um banco de dados da CA fornece consistência e disponibilidade em todos os nós. No entanto, ele não poderá fazer isso se houver uma partição entre dois nós no sistema e, portanto, não puder fornecer tolerância a falhas. Em um sistema distribuído, as partições não podem ser evitadas. Portanto, embora possamos discutir um banco de dados distribuído pela CA em teoria, para todos os efeitos práticos, um banco de dados distribuído pela CA pode existir, mas não deveria existir.

Portanto, isso não significa que você não pode ter um banco de dados da CA para seu aplicativo distribuído se precisar de um. Muitos bancos de dados relacionais, como o PostgreSQL, oferecem consistência e disponibilidade e podem ser implantados em vários nós usando a replicação.

Fonte: https://www.ibm.com/cloud/learn/cap-theorem

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.