O CAP é bem conhecido por muitos, portanto não vou perder tempo explicando o material de introdução aqui, mas gostaria de identificar corretamente um equívoco que surgiu algumas vezes em conversas recentes. Aqui está o ponto principal desta postagem: O comportamento "CAP" do Couchbase Server como um único cluster versus o Couchbase Server com XDCR é diferente.
Vamos começar com a implantação de cluster único do Couchbase Server: Em geral, o CAP é um nível muito alto para descrever todas as cores de um sistema, mas o Couchbase Server é chamado principalmente de sistema CP com opções para substituir o C em favor do A (por exemplo, failover automático).
No entanto, com uma implantação de vários clusters com o XDCR, o Couchbase Server fornece AP. Você pode gravar em um dos clusters e nós detectaremos e resolveremos o conflito, proporcionando consistência eventual entre vários clusters (é altamente recomendável que você entenda como detectamos e resolvemos esses conflitos para ter certeza de que o efeito é o esperado). O Couchbase Server pode ser um sistema mais CP ou mais AP, dependendo da topologia de implantação.
Vou fazer uma advertência e essa discussão também aparece em várias opiniões que temos aqui na engenharia: CAP é uma definição de alto nível. É uma boa primeira introdução para entender a abordagem de um sistema. No entanto, não é excelente para descrever todas as cores do sistema. Com isso, a tabela anexa deve fornecer mais detalhes sobre como funciona o CAP Balance do Couchbase Server. Um rápido tour pelas colunas: A tabela analisa várias topologias de implementação com XDCR. Os domínios de falha descrevem o domínio de falha para a topologia em questão. O Balanço de CAP descreve as necessidades de AP versus as necessidades de CP do sistema.
Por fim, se você ainda não analisou o XDCR como um recurso de disponibilidade, a tabela a seguir é um bom ponto de partida. Se quiser ler mais sobre o XDCR e seu comportamento, recomendo também fazer o download do seguinte documento: Desenvolvimento de aplicativos com o XDCR
Obrigado pela leitura e, como sempre, comentários são bem-vindos.
Cihan Biyikoglu - Gerenciamento de produtos @ Couchbase
Topologia de implantação |
Domínio de falhas |
Balanço do CAP |
Comentários |
|
Cluster único do Couchbase Server |
Domínio de falhas no nível do nó (por exemplo, falhas de hardware, falhas de comunicação entre nós) |
Pode ser configurado como CP e pode ser ajustado para estar disponível por meio de failover automático ou com leituras de réplicas e muito mais. |
O Couchbase Server permite a leitura de vbuckets ativos ou de réplicas e, portanto, pode ser ajustado com o failover automático para oferecer disponibilidade de gravação após um breve tempo limite de failover. |
|
Clusters do Couchbase Server com XDCR unidirecional para HA/DR |
Falhas em todo o nó e cluster (exemplos: falhas de DC causadas por desastres naturais) |
AP entre clusters com XDCR unidirecional com proteção contra falhas em todo o cluster ou nos nós. O mesmo "equilíbrio CAP" dentro de cada cluster para falhas de nós. |
Unidirecional com capacidade computacional passiva em um segundo local/centro de dados. O cluster de destino pode ser usado para leituras eventualmente consistentes durante o estado estável e pode ser promovido para leitura/gravação quando o cluster de origem falhar. |
|
Clusters do Couchbase Server com XDCR bidirecional para HA/DR |
Falhas em todo o nó e cluster (exemplos: falhas de DC causadas por desastres naturais) |
AP em clusters com XDCR bidirecional com proteção contra falhas em todo o cluster ou nos nós. O mesmo "equilíbrio CAP" dentro de cada cluster para falhas de nós. |
Bi-direcional com capacidade computacional ativa/dividida entre sites/centros de dados. O cluster de destino pode ser usado para leituras e gravações eventualmente consistentes durante o estado estável. Você pode ter conflitos de gravação se a mesma chave sofrer mutação em ambos os clusters. Muitos clientes minimizam os conflitos de gravação segmentando o tráfego de gravação para intervalos de chaves não sobrepostos nos clusters de origem e destino. |
