Qual é o raciocínio por trás do teorema CAP?

OK, vamos imaginar que você tenha um banco de dados distribuído. Digamos que você tenha um nó no Oregon e outro na Califórnia. A teoria CAP diz que você terá problemas ao configurar esse tipo de banco de dados.

Por exemplo, se você consultar dados de um banco de dados, eles precisam ser iguais aos dados do outro banco de dados. Isso garante que qualquer valor que você tenha em um banco de dados esteja garantido no outro ( consistência da teoria CAP). Isso permite atualizar os dados em um banco de dados e consultá-los em outro, obtendo os mesmos resultados.

Quando atualizamos os dados no nó Oregon, os dados são enviados para o nó Califórnia para que os bancos de dados fiquem consistentes. Para realmente manter a consistência, temos que garantir que ambos os bancos de dados obtenham a atualização antes que qualquer um deles possa realmente salvar os dados (confirmação de duas fases usando transações distribuídas). Em outras palavras, se o banco de dados da Califórnia não puder salvar os dados por algum motivo (por exemplo, falha no disco rígido), o banco de dados do Oregon não salvará os dados e falhará na transação.

O problema com transações distribuídas como a acima surge quando queremos ter alta disponibilidade. No cenário acima, o processo de tentar sincronizar os dois bancos de dados é um processo muito, muito lento. (Imagine, temos que enviar os dados do Oregon para a Califórnia, garantir que eles cheguem lá, garantir que os dois bancos de dados tenham bloqueios nos dados etc.) Isso causa grandes problemas quando queremos um sistema rápido e responsivo mesmo durante momentos de grande demanda. (Esta é a Disponibilidade do teorema CAP.)

Normalmente, o que fazemos para garantir alta disponibilidade é usar replicação em vez de transações distribuídas. Então, em vez de garantir que a Califórnia pode aceitar os dados, nós apenas vamos em frente e os armazenamos no nó do Oregon e então enviamos os dados para a Califórnia quando chegarmos lá. Isso garante que sempre podemos armazenar os dados, independentemente de a Califórnia estar pronta para armazenar os dados ou não.

Isso melhora a Disponibilidade, mas ao custo da Consistência. Veja, se alguém atualiza os dados em Oregon e então alguém (ao mesmo tempo) lê os dados na Califórnia, eles não estão obtendo os novos dados - os bancos de dados não são mais consistentes. Na verdade, eles não serão consistentes até que o Oregon envie os dados para a Califórnia!

Portanto, essa é a compensação entre Disponibilidade e Consistência.

A tolerância à partição é o terceiro aspecto da teoria CAP. O particionamento é, neste contexto, a ideia de que um banco de dados (ou outro sistema distribuído) pode ser dividido em seções separadas e ainda funcionar corretamente.

A questão é: o que acontece quando os dois bancos de dados estão funcionando corretamente, mas o link do Oregon para a Califórnia foi interrompido?

Se atualizarmos o banco de dados no Oregon, precisamos levar os dados para a Califórnia de uma forma ou de outra (transação distribuída ou replicação). No entanto, se o link entre os dois for interrompido, o sistema tornou-se particionado e os bancos de dados não estão mais vinculados.

Quando isso acontece, suas escolhas são parar de permitir atualizações (para manter a Consistência) ao custo da Disponibilidade ou permitir as atualizações (para manter a Disponibilidade) ao custo da consistência.

Como você pode ver, a tolerância à partição cria compensações diretas entre consistência e disponibilidade.

Obviamente, há mais do que isso, mas esses são alguns exemplos de como esses três principais aspectos dos sistemas distribuídos funcionam uns contra os outros. A explicação de Julian Browne sobre a teoria CAP é um excelente lugar para aprender mais.