Introdução aos princípios da PAC
O princípio do CAP, também conhecido como teorema do CAP, refere-se à consistência, disponibilidade e tolerância de partição em um sistema distribuído. O princípio da PAC significa que esses três elementos podem atingir apenas dois pontos ao mesmo tempo, e é impossível equilibrar os três.
Três indicadores da PAC
Consistência
"Todos os nós veem os mesmos dados ao mesmo tempo", ou seja, depois que a operação de atualização é bem-sucedida e retorna ao cliente, os dados de todos os nós ao mesmo tempo ficam completamente consistentes, o que é consistência distribuída. O problema de consistência é inevitável em sistemas concorrentes.Para os clientes, consistência refere-se ao problema de como obter dados atualizados durante o acesso simultâneo. Da perspectiva do servidor, é como atualizar a distribuição para todo o sistema para garantir que os dados sejam eventualmente consistentes
Disponibilidade
Disponibilidade refere-se a "Lê e grava sempre com êxito", ou seja, o serviço está sempre disponível e o tempo de resposta normal. A boa usabilidade refere-se principalmente a que o sistema pode atender bem aos usuários e não há falha na experiência do usuário, como falha na operação do usuário ou tempo limite de acesso.
Tolerância de partição
Ou seja, quando um sistema distribuído encontra uma falha no nó ou na partição de rede, ainda pode fornecer serviços que atendem à consistência ou disponibilidade.
Prova do teorema da PAC
O que se segue explica por que os três elementos do princípio da PAC só podem atingir no máximo dois pontos ao mesmo tempo e é impossível equilibrar os três.
Suponha que exista um cliente C, usuário A e dois servidores, dois nós de serviço idênticos S1 e S2 são implantados e os dados armazenados são todos V0. A rede entre eles pode se comunicar, o que equivale a dois do sistema distribuído. Seções.
Processo de operação
1. O cliente A atualizou os dados V1 para S1
2. Esta mensagem do nó S1 informa ao nó S2 que a página S2 deseja atualizar os dados, mas ocorreu uma falha na rede e a V2 ainda está salva no S2.
3. O cliente solicita dados de S2 e S2 retorna dados V0
Análise
(1) A rede do sistema falha, mas o sistema ainda está acessível e, portanto, é tolerante a falhas.
(2) Quando o cliente A acessa o nó S1, V0 para V1 é alterado. Quando o cliente A acessa o nó S2, é V1. Portanto, é necessário aguardar a falha na rede para recuperar e atualizar os dados do nó S2.
(3) É impossível para o sistema atender à disponibilidade durante o período de recuperação de falhas na rede. Como os requisitos de disponibilidade são corretos e eficazes para acessar o sistema a qualquer momento, em qualquer lugar. Isso é uma contradição.
É essa contradição que as três características da PAC não devem ser satisfeitas ao mesmo tempo. Como não estamos satisfeitos, faremos uma escolha.
Existem duas opções:
Primeiro, sacrifique a consistência dos dados e responda aos dados antigos V0 para o cliente;
Segundo, às custas da disponibilidade, bloqueando e aguardando até que a conexão de rede seja restaurada e, após a conclusão da operação de atualização de dados, o usuário responde aos dados mais recentes V1.
Estratégia de trade-off
CA sem P : Se P (não é permitido particionamento) não for necessário, C (consistência forte) e A (disponibilidade) podem ser garantidas. Mas desistir de P ao mesmo tempo significa renunciar à escalabilidade do sistema, ou seja, os nós distribuídos são limitados e não há como implantar nós filhos, o que é contrário à intenção original do design do sistema distribuído.
CP sem A : Se A (disponível) não for necessário, significa que cada solicitação precisa ser fortemente consistente entre os servidores e P (partição) fará com que o tempo de sincronização seja infinitamente estendido (ou seja, aguarde a sincronização de dados para concluir o acesso normal ao serviço) Depois que ocorre uma falha na rede ou perda de mensagens, você deve sacrificar a experiência do usuário e aguardar que todos os dados sejam consistentes antes de permitir que os usuários acessem o sistema. Na verdade, existem muitos sistemas projetados como CPs. Os mais comuns são bancos de dados distribuídos, como Redis e HBase. Para esses bancos de dados distribuídos, a consistência dos dados é o requisito mais básico, porque, mesmo que esse padrão não seja atendido, é bom usar diretamente um banco de dados relacional e não há necessidade de desperdiçar recursos para implantar bancos de dados distribuídos.
AP sem C : para estar altamente disponível e permitir o particionamento, você precisa desistir da consistência. Quando o particionamento ocorre, os nós podem perder o contato.Para alta disponibilidade, cada nó pode usar apenas dados locais para fornecer serviços, o que levará a inconsistências nos dados globais. Um aplicativo típico é como um cenário de compra rápida de um determinado medidor.Você pode ser solicitado a ter inventário ao procurar o produto há alguns segundos atrás.Quando você selecionou o produto e pronto para fazer um pedido, o sistema solicitará que o pedido falhe e o produto tenha sido vendido . Na verdade, é para garantir o serviço normal do sistema em A (disponibilidade) e, em seguida, fazer alguns sacrifícios na consistência dos dados.Embora afete alguma experiência do usuário, não causará um bloqueio sério do processo de compra do usuário.
De um modo geral, a tolerância a falhas da partição não pode ser evitada, portanto, pode-se considerar que P do CAP sempre é válido. O teorema da CAP nos diz que o restante C e A não podem ser feitos ao mesmo tempo.