Apresentando o novo protocolo de replicação de dados no Couchbase Mobile 2.0

Em um sistema distribuído, as atualizações em um banco de dados compartilhado de vários clientes terão de ser sincronizadas. O objetivo do processo de replicação é garantir que todos os clientes móveis e o(s) servidor(es) tenham uma visão consistente dos dados, sincronizando as alterações nos bancos de dados locais e remotos. No Couchbase Mobile, a replicação ocorre entre os clientes que executam o Couchbase Lite e o Sync Gateway do servidor.

O Couchbase Mobile 2.0 liberação traz uma infinidade de Novos recursos e aprimoramentos. Um aprimoramento importante é o novo e aprimorado protocolo de replicação. Esta postagem apresentará a você os fundamentos do novo protocolo de replicação no Couchbase Mobile 2.0.
Você pode fazer o download do Couchbase Mobile 2.0 em aqui.

Histórico

O Plataforma móvel do Couchbase compreende o Couchbase Lite Banco de dados incorporado NoSQL em execução nos clientes; o Gateway de sincronização responsável pela sincronização de dados, roteamento de dados e autenticação/autorização de usuários; e Servidor Couchbase para persistência e gerenciamento de dados.

Na versão 1.x do Couchbase Mobile, a replicação foi implementada usando um protocolo baseado em REST originado por CouchDB por HTTP(s). De fato, a lógica de replicação foi implementada como uma série de chamadas de API por HTTP.

Nova arquitetura em camadas

O Replication Protocol 2.0 é implementado como um novo protocolo de mensagens em camadas WebSockets. Ele é compatível com todos os suportado Plataformas Couchbase Lite 2.0 e Sync Gateway 2.0.

O protocolo WebSocket permite a passagem de mensagens full-duplex entre hosts remotos por meio de uma única conexão de soquete TCP. O protocolo WebSocket começa como uma conexão HTTP(s) e muda para Websockets se o host remoto for compatível.

O novo protocolo de mensagens, inventado por Jens AlfkeA nova arquitetura em camadas é mais limpa e permite a separação de preocupações entre a lógica de replicação e o transporte de mensagens subjacente. A nova arquitetura em camadas é mais limpa e permite uma separação de preocupações entre a lógica de replicação e o transporte de mensagens subjacente. O novo protocolo é mais rápido e requer menos largura de banda e recursos de soquete. A economia de recursos de soquete permitiria maior suporte a conexões simultâneas no servidor. Por fim, a natureza bidirecional do protocolo WebSocket se presta bem a configurações ponto a ponto.

Compatibilidade

O novo protocolo de replicação é compatível com os clientes Couchbase Lite 2.0 e Sync Gateway 2.0. Confira a guia de compatibilidade para obter detalhes.

Esse é o protocolo de replicação padrão que será usado no Couchbase Mobile 2.0. Você não precisa ativá-lo especificamente na configuração do Sync Gateway. No caso de clientes Couchbase Lite 1.x, o Sync Gateway mudará automaticamente para o protocolo de replicação mais antigo.

Terminologia

Aqui estão alguns termos que usaremos nesta discussão

• "Cliente" : Cliente Couchbase Lite 2.0
• "Servidor" : Sync Gateway 2.0
• "Banco de dados de origem" : O banco de dados local a partir do qual as alterações são replicadas
• "Banco de dados de destino" : O banco de dados remoto para o qual as alterações são replicadas
• "Replicador de origem" : O replicador que está enviando alterações no banco de dados
• "Replicador de Alvo" : O replicador que está recebendo alterações no banco de dados
• "Replicação por push" : Processo pelo qual os clientes fazem upload das alterações do banco de dados de origem local para o banco de dados de destino remoto (servidor)
• "Replicação pull" : Processo pelo qual os clientes fazem download das alterações do banco de dados de origem remota (servidor) para o banco de dados de destino local
• "Replicador Ativo" : Replicador do Couchbase Lite que faz push ou pull automaticamente das alterações no banco de dados
• "Replicador Passivo" : Replicador do Sync Gateway que responde a solicitações push ou pull de alterações

Modos de replicação

O processo de replicação pode ser "contínuo" ou "um tiro“.

• No modo de replicação "Contínuo", as alterações são continuamente sincronizadas entre o cliente e o Sync Gateway.
• No modo "One shot", as alterações são sincronizadas uma vez e a conexão entre o cliente e o servidor é desconectada. Quando qualquer alteração futura precisar ser enviada para cima ou para baixo, o cliente deverá iniciar uma nova replicação.

Conceitos

Antes de analisarmos o protocolo, precisamos entender alguns conceitos-chave.

Árvores de revisão

O Couchbase usa um sistema de controle de simultaneidade de várias versões (MVCC) para gerenciar documentos. Nesse sistema, cada documento no Couchbase Mobile é armazenado como uma sequência de revisões. Uma nova revisão é criada automaticamente quando um documento é criado. Cada atualização do documento, seja uma edição ou uma exclusão, resultará na criação de uma nova revisão para o documento. A revisão especial que marca uma exclusão é chamada de lápide revisão. A revisão atual é a revisão da folha do documento e, no caso de revisões conflitantes, corresponde à vencedor revisão. Para obter mais detalhes sobre árvores de revisão e resolução de conflitos na versão 2.0, fique atento a uma próxima postagem do blog sobre esse tópico.

Mudança

A revisão atual que existe no banco de dados de origem, mas não no banco de dados de destino, é chamada de mudança. Assim, efetivamente, o processo de replicação sincroniza as alterações entre bancos de dados remotos.

ID da sequência

Cada alteração está associada a um único ID da sequência que está em ordem cronológica crescente. É semelhante a um carimbo de data/hora da última modificação, exceto pelo fato de não ser uma hora de relógio de parede, mas um contador que aumenta automaticamente. Os IDs de sequência são específicos de um determinado banco de dados, portanto, quando um documento é replicado, ele não termina com o mesmo ID de sequência.

Observação: Enquanto os IDs de sequência do Couchbase Lite são números inteiros simples, os do Sync Gateway podem ser cadeias longas de base64. Os motivos são complexos e têm a ver com a concorrência interna entre os nós em um cluster do Couchbase Server. O conteúdo exato de um ID de sequência remota depende da implementação e um cliente nunca deve fazer suposições sobre ele.

Ponto de controle

O ponto de verificação é um registro do último ID da sequência replicado pelo replicador. No final de cada ciclo de replicação, o replicador fará o checkpoint da fonte ID da sequência correspondente à última alteração enviada ao destino. O primeiro ciclo de replicação não terá pontos de verificação.

O que a replicação realmente faz?

Agora que você já entendeu os principais conceitos, a replicação pode ser descrita como o processo pelo qual o replicador de origem envia todos os arquivos de dados de um replicador. mudançascujos IDs de sequência são maiores do que o último ponto de verificação, para o replicador de destino. Os corpos de revisão do atual revisões, juntamente com as bolhas/anexos e o histórico de revisão são replicados.

Observação: É possível que o mesmo documento seja editado simultaneamente no banco de dados de origem e de destino, resultando em um conflito. Discutiremos conflitos e replicação um pouco mais adiante nesta postagem.

Observe que, se um documento for purgado do banco de dados, o expurgo não será replicado. A eliminação remove todos os rastros do documento do banco de dados.

O esquema de URL

Os clientes do Couchbase Lite devem usar o ws Esquema de URL para conectar-se ao Sync Gateway

Aqui estão alguns exemplos

O protocolo

Estabelecimento de conexão

1. Quando a replicação é iniciada, o cliente envia uma solicitação de handshake do WebSocket para o servidor por HTTP(s), indicando que deseja mudar para o WebSocket. Essa é uma solicitação HTTP GET, com cabeçalhos especiais, para o recurso _blipsync relativo ao URL do banco de dados.
2. O servidor responde indicando que concorda com a troca de protocolo.
3. Uma vez que o Handshake de Websockets é feito, o soquete deixa de ser usado para HTTP e todas as comunicações posteriores são mensagens WebSocket.

Um único soquete pode suportar simultaneamente uma replicação push e pull. Ambos os tipos armazenam e recuperam pontos de controle e exigem esses pontos de controle para prosseguir, portanto, o gerenciamento de pontos de controle será descrito primeiro.

Gerenciamento de pontos de controle

As replicações push e pull armazenam e buscam pontos de controle no servidor.

1. Após o estabelecimento da conexão, o cliente envia um getCheckpoint mensagem para o servidor a fim de determinar a última ID de sequência de origem conhecida no servidor. A solicitação inclui:
   • ID do cliente que identifica o cliente
2. A resposta a getCheckpoint inclui o último ponto de verificação registrado para o cliente. O ponto de controle é um objeto JSON criado e armazenado anteriormente pelo cliente; ele pode conter quaisquer dados que o cliente desejar, mas é atualmente do formulário:
   • ID de sequência local que é a última sequência conhecida enviada pelo cliente
   • ID de sequência remota que é a última ID de sequência recebida pelo cliente
3. À medida que as sequências são replicadas com sucesso, o cliente envia periodicamente um setCheckpoint para registrar a última ID de sequência local que foi enviada e/ou a última ID de sequência remota que foi recebida.

Replicação por push

Durante a replicação push, uma série de alterações é enviada automaticamente pelo replicador ativo para o replicador passivo

1. Depois que o ponto de verificação for recuperado, e quando o replicador do lado do cliente detectar alterações em seu banco de dados local desde o ID de sequência localo cliente envia um proposeChanges para o servidor com uma matriz de mudança correspondentes a cada revisão atual que foi alterada. Isso inclui revisões com túmulos. A alteração em si é codificada como uma matriz JSON aninhada e inclui:
   • ID do documento do documento associado à alteração
   • ID da revisão da revisão atual do documento
   • ID de revisão do servidor de revisão de servidor conhecida, se houver. É omitido se não houver nenhuma ID de revisão do servidor
   • Opcionalmente, o tamanho aproximado do corpo do documento
2. A resposta do servidor à mensagem proposeChanges A solicitação inclui um objeto JSON que contém:
   • uma matriz de códigos de status, com cada entrada correspondendo à ID de revisão especificada no proposeChanges solicitação.
     • Um valor de 0 indica que o servidor está interessado na rev
     • Um valor de 304 indica que o servidor tem essa revisão
     • Um valor de 409 indica que as alterações causariam um conflito
3. O cliente envia um rev mensagem para cada uma das revisões solicitado na proposeChanges resposta na etapa 2. O rev O corpo da mensagem contém o documento no formato JSON, e os cabeçalhos da mensagem contêm metadados:
   • id campo cujo valor é o ID do documento cujo corpo está incluído
   • rev campo com valor correspondente à revisão incluída
   • sequência com a ID de sequência da alteração
   • histórico que inclui uma lista separada por vírgulas de IDs de revisão desde o revisão de ancestrais conhecidos conforme especificado no mudanças resposta
4. Depois de todos os rev mensagens foram enviadas, em contínuo o cliente aguarda a alteração do banco de dados local e retorna à Etapa 1. Em um tiro a conexão é desconectada e a replicação termina.

Replicação pull

Durante a replicação pull, uma série de alterações é enviada pelo servidor replicador passivo em resposta a uma solicitação pull do cliente replicador ativo.

1. Depois que o ponto de verificação é recuperado, o cliente envia um subalterações mensagem para o servidor que inclui cabeçalhos:
   • desde com o valor do campo ID de sequência remota
   • contínuo para indicar se está no modo contínuo. Um valor de verdadeiro indica que o cliente deseja ser notificado continuamente sobre as alterações.
   • lote campo com valor que indica o número máximo de alterações a serem enviadas em uma única mensagem
2. O servidor envia um mudanças para o cliente com uma matriz de mudança correspondentes a cada revisão atual que foi alterada. Isso inclui revisões com túmulos. A alteração em si é codificada como uma matriz JSON aninhada e inclui:
   • ID de sequência remota que é a ID de sequência da alteração no lado do servidor
   • ID do documento do documento associado à alteração
   • ID da revisão da revisão atual do documento
   • isDeleted para indicar se a revisão é um tombstone ou não. Um valor de 1 indica que se trata de uma revisão de tombstone
   • Opcionalmente, o tamanho aproximado do corpo do documento
3. A resposta do cliente ao mudanças A solicitação inclui um objeto JSON que contém:
   • maxHistory campo cujo valor é o tamanho máximo do histórico que o cliente aceitará
   • uma matriz de ancestrais conhecidosuma entrada para cada ID de revisão especificada no mudanças solicitação. Um valor nulo para uma entrada indica que o cliente não está interessado na revisão correspondente.
4. O servidor envia um rev mensagem para cada uma das revisões solicitado na mudanças resposta na etapa 3. O rev O corpo da mensagem contém o documento no formato JSON, e os cabeçalhos da mensagem contêm metadados:
   • id campo cujo valor corresponde ao ID do documento cujo corpo está incluído
   • rev campo com valor correspondente à revisão incluída
   • sequência com o valor correspondente à ID de sequência da alteração
   • histórico que inclui uma lista separada por vírgulas de IDs de revisão desde o revisão de ancestrais conhecidos conforme especificado em mudanças resposta
5. Quando terminar de enviar as alterações, o servidor enviará uma mensagem vazia mudanças para indicar que não há mais alterações a serem enviadas.
6. Depois que todas as alterações tiverem sido enviadas, em contínuo a conexão permanece aberta enquanto o servidor aguarda a alteração do banco de dados e, em seguida, retorna à Etapa 2. Em um tiro a conexão é desconectada e a replicação termina.

Observação que as etapas 2 a 4 são idênticas às etapas 1 a 3 da replicação por push, apenas com as funções "cliente" e "servidor" trocadas. O protocolo de replicação é bastante simétrico, ao contrário de uma API baseada em HTTP, em que as funções de cliente e servidor exigem códigos totalmente diferentes. Isso ajuda a simplificar o projeto e a implementação, especialmente para a replicação ponto a ponto entre clientes.

Como lidar com conflitos

Os conflitos ocorrem quando há concomitante atualizações para o mesmo revisão de documentos de várias fontes. Aqui, "simultâneo" significa "entre replicações": se um cliente ficar off-line por uma hora e voltar, todas as alterações feitas nesse cliente durante essa hora seria efetivamente simultâneo às alterações feitas por todos os outros clientes. Em um sistema distribuído como esse, a simultaneidade não é uma condição de corrida rara, mas um fato da vida.

O Couchbase Mobile 2.0 oferece suporte a um novo livre de conflitos modo. Os detalhes de como os conflitos são tratados na versão 2.0 estão fora do escopo desta postagem do blog, mas você pode ler mais sobre isso aqui. Em um alto nível, quando o cliente encontra um conflito ao salvar uma revisão, o retorno de chamada do resolvedor de conflitos associado ao documento é chamado e a revisão mesclada resultante é usada. Assim, o documento nunca existe visivelmente em um estado conflituoso. Você pode ler mais sobre isso em uma próxima postagem do blog.

Perda de conexão com o servidor

Durante a replicação, se o cliente não conseguir se conectar ao servidor ou se a conexão com o servidor for perdida, o cliente tentará se reconectar usando um algoritmo de backoff exponencial, no qual ele espera cada vez mais tempo a cada nova tentativa.

• No caso de um um tiro replicação, serão feitas no máximo duas tentativas de repetição antes que o cliente desista.
• No caso de replicação contínuao cliente tentará se reconectar indefinidamente, mas o intervalo de tentativas não aumentará além de 10 minutos.

O replicador cancelará seu cronômetro e tentará novamente de imediato se for notificado de que a conexão de rede do dispositivo foi alterada (ele se conectou a uma rede WiFi ou celular). Porém, devido à forma como a rede IP funciona, o dispositivo só pode detectar alterações em suas próprias interfaces de rede, e não alterações que estejam ocorrendo em outros lugares no caminho para o servidor, nem mesmo no roteador WiFi local. Portanto, conectar o cabo ou a conexão Ethernet novamente ao roteador não será detectado imediatamente. No entanto, o desligamento do roteador será detectado, pois a interface de rede WiFi do dispositivo ficará inativa.

A detecção de uma conexão perdida também pode ser problemática. Quando uma conexão TCP está ociosa, nenhum pacote está sendo enviado em nenhuma direção, portanto, nenhum dos pares pode saber se o outro foi desconectado abruptamente ou se uma conexão ao longo do caminho entre eles foi cortada (por exemplo, se o cabo ou a Ethernet do roteador foi desconectado). Se o remetente não receber um pacote TCP ACK em resposta à sua mensagem dentro de alguns segundos, ele saberá que a conexão caiu.

O que vem a seguir

A arquitetura de replicação 2.0 no Couchbase Mobile 2.0 é mais limpa, mais simples e mais eficiente em termos de recursos do que as versões anteriores baseadas em REST API/HTTP.

Se tiver dúvidas ou comentários, deixe um comentário abaixo ou sinta-se à vontade para entrar em contato comigo pelo Twitter @rajagp ou por e-mail priya.rajagopal@couchbase.com. O Fóruns do Couchbase são outro bom lugar para entrar em contato com perguntas.
Por fim, um agradecimento especial a Jens Alfke (https://github.com/snej), por seu feedback.