\nVoc\u00ea pode fazer o download do Couchbase Mobile 2.0 em aqui<\/a>.<\/p>\n
<\/p>\n
Hist\u00f3rico<\/h2>\n
O Plataforma m\u00f3vel do Couchbase <\/a> compreende o Couchbase Lite<\/a> Banco de dados incorporado NoSQL em execu\u00e7\u00e3o nos clientes; o Gateway de sincroniza\u00e7\u00e3o<\/a> respons\u00e1vel pela sincroniza\u00e7\u00e3o de dados, roteamento de dados e autentica\u00e7\u00e3o\/autoriza\u00e7\u00e3o de usu\u00e1rios; e Servidor Couchbase<\/a> para persist\u00eancia e gerenciamento de dados. Na vers\u00e3o 1.x do Couchbase Mobile, a replica\u00e7\u00e3o foi implementada usando um protocolo baseado em REST originado por CouchDB<\/a> por HTTP(s). De fato, a l\u00f3gica de replica\u00e7\u00e3o foi implementada como uma s\u00e9rie de chamadas de API por HTTP.<\/p>\n O Replication Protocol 2.0 \u00e9 implementado como um novo protocolo de mensagens<\/a> em camadas WebSockets<\/a>. Ele \u00e9 compat\u00edvel com todos os suportado <\/a> Plataformas Couchbase Lite 2.0 e Sync Gateway 2.0.<\/p>\n O protocolo WebSocket permite a passagem de mensagens full-duplex entre hosts remotos por meio de uma \u00fanica conex\u00e3o de soquete TCP. O protocolo WebSocket come\u00e7a como uma conex\u00e3o HTTP(s) e muda para Websockets se o host remoto for compat\u00edvel.<\/p>\n O novo protocolo de mensagens, inventado por Jens Alfke<\/a>A nova arquitetura em camadas \u00e9 mais limpa e permite a separa\u00e7\u00e3o de preocupa\u00e7\u00f5es entre a l\u00f3gica de replica\u00e7\u00e3o e o transporte de mensagens subjacente. A nova arquitetura em camadas \u00e9 mais limpa e permite uma separa\u00e7\u00e3o de preocupa\u00e7\u00f5es entre a l\u00f3gica de replica\u00e7\u00e3o e o transporte de mensagens subjacente. O novo protocolo \u00e9 mais r\u00e1pido e requer menos largura de banda e recursos de soquete. A economia de recursos de soquete permitiria maior suporte a conex\u00f5es simult\u00e2neas no servidor. Por fim, a natureza bidirecional do protocolo WebSocket se presta bem a configura\u00e7\u00f5es ponto a ponto.<\/p>\n O novo protocolo de replica\u00e7\u00e3o \u00e9 compat\u00edvel com os clientes Couchbase Lite 2.0 e Sync Gateway 2.0. Confira a guia de compatibilidade<\/a> para obter detalhes.<\/p>\n Esse \u00e9 o protocolo de replica\u00e7\u00e3o padr\u00e3o que ser\u00e1 usado no Couchbase Mobile 2.0. Voc\u00ea n\u00e3o precisa ativ\u00e1-lo especificamente na configura\u00e7\u00e3o do Sync Gateway. No caso de clientes Couchbase Lite 1.x, o Sync Gateway mudar\u00e1 automaticamente para o protocolo de replica\u00e7\u00e3o mais antigo.<\/p>\n Aqui est\u00e3o alguns termos que usaremos nesta discuss\u00e3o<\/p>\n O processo de replica\u00e7\u00e3o pode ser \"cont\u00ednuo<\/em>\" ou \"um tiro<\/em>“.<\/p>\n Antes de analisarmos o protocolo, precisamos entender alguns conceitos-chave.<\/p>\n O Couchbase usa um sistema de controle de simultaneidade de v\u00e1rias vers\u00f5es (MVCC) para gerenciar documentos. Nesse sistema, cada documento no Couchbase Mobile \u00e9 armazenado como uma sequ\u00eancia de revis\u00f5es. Uma nova revis\u00e3o \u00e9 criada automaticamente quando um documento \u00e9 criado. Cada atualiza\u00e7\u00e3o do documento, seja uma edi\u00e7\u00e3o ou uma exclus\u00e3o, resultar\u00e1 na cria\u00e7\u00e3o de uma nova revis\u00e3o para o documento. A revis\u00e3o especial que marca uma exclus\u00e3o \u00e9 chamada de l\u00e1pide<\/em> revis\u00e3o. A revis\u00e3o atual<\/em> \u00e9 a revis\u00e3o da folha do documento e, no caso de revis\u00f5es conflitantes, corresponde \u00e0 vencedor<\/em> revis\u00e3o. Para obter mais detalhes sobre \u00e1rvores de revis\u00e3o e resolu\u00e7\u00e3o de conflitos na vers\u00e3o 2.0, fique atento a uma pr\u00f3xima postagem do blog sobre esse t\u00f3pico.<\/p>\n A revis\u00e3o atual que existe no banco de dados de origem, mas n\u00e3o no banco de dados de destino, \u00e9 chamada de mudan\u00e7a<\/em>. Assim, efetivamente, o processo de replica\u00e7\u00e3o sincroniza as altera\u00e7\u00f5es<\/em> entre bancos de dados remotos.<\/p>\n Cada altera\u00e7\u00e3o est\u00e1 associada a um \u00fanico ID da sequ\u00eancia<\/em> que est\u00e1 em ordem cronol\u00f3gica crescente. \u00c9 semelhante a um carimbo de data\/hora da \u00faltima modifica\u00e7\u00e3o, exceto pelo fato de n\u00e3o ser uma hora de rel\u00f3gio de parede, mas um contador que aumenta automaticamente. Os IDs de sequ\u00eancia s\u00e3o espec\u00edficos de um determinado banco de dados, portanto, quando um documento \u00e9 replicado, ele n\u00e3o termina com o mesmo ID de sequ\u00eancia.<\/p>\n Observa\u00e7\u00e3o:<\/strong> Enquanto os IDs de sequ\u00eancia do Couchbase Lite s\u00e3o n\u00fameros inteiros simples, os do Sync Gateway podem ser cadeias longas de base64. Os motivos s\u00e3o complexos e t\u00eam a ver com a concorr\u00eancia interna entre os n\u00f3s em um cluster do Couchbase Server. O conte\u00fado exato de um ID de sequ\u00eancia remota depende da implementa\u00e7\u00e3o e um cliente nunca deve fazer suposi\u00e7\u00f5es sobre ele.<\/p>\n O ponto de verifica\u00e7\u00e3o \u00e9 um registro do \u00faltimo ID da sequ\u00eancia<\/em> replicado pelo replicador. No final de cada ciclo de replica\u00e7\u00e3o, o replicador far\u00e1 o checkpoint da fonte ID da sequ\u00eancia<\/em> correspondente \u00e0 \u00faltima altera\u00e7\u00e3o enviada ao destino. O primeiro ciclo de replica\u00e7\u00e3o n\u00e3o ter\u00e1 pontos de verifica\u00e7\u00e3o.<\/p>\n Agora que voc\u00ea j\u00e1 entendeu os principais conceitos, a replica\u00e7\u00e3o pode ser descrita como o processo pelo qual o replicador de origem envia todos os arquivos de dados de um replicador. mudan\u00e7as<\/em>cujos IDs de sequ\u00eancia s\u00e3o maiores do que o \u00faltimo ponto de verifica\u00e7\u00e3o, para o replicador de destino. Os corpos de revis\u00e3o do atual<\/em> revis\u00f5es, juntamente com as bolhas<\/em>\/anexos e o hist\u00f3rico de revis\u00e3o s\u00e3o replicados.<\/p>\n Observa\u00e7\u00e3o<\/strong>: \u00c9 poss\u00edvel que o mesmo documento seja editado simultaneamente no banco de dados de origem e de destino, resultando em um conflito. Discutiremos conflitos e replica\u00e7\u00e3o um pouco mais adiante nesta postagem.<\/p>\n Couchbase Lite clients must use the `ws` URL scheme to connect to the Sync Gateway<\/p>\n Aqui est\u00e3o alguns exemplos<\/p>\n <\/p>\n Um \u00fanico soquete pode suportar simultaneamente uma replica\u00e7\u00e3o 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\u00e1 descrito primeiro.<\/p>\n As replica\u00e7\u00f5es push e pull armazenam e buscam pontos de controle no servidor.<\/p>\n Durante a replica\u00e7\u00e3o push, uma s\u00e9rie de altera\u00e7\u00f5es \u00e9 enviada automaticamente pelo replicador ativo<\/em> para o replicador passivo<\/em><\/p>\n Durante a replica\u00e7\u00e3o pull, uma s\u00e9rie de altera\u00e7\u00f5es \u00e9 enviada pelo servidor replicador passivo<\/em> em resposta a uma solicita\u00e7\u00e3o pull do cliente replicador ativo<\/em>.<\/p>\n Observa\u00e7\u00e3o<\/strong> que as etapas 2 a 4 s\u00e3o id\u00eanticas \u00e0s etapas 1 a 3 da replica\u00e7\u00e3o por push, apenas com as fun\u00e7\u00f5es \"cliente\" e \"servidor\" trocadas. O protocolo de replica\u00e7\u00e3o \u00e9 bastante sim\u00e9trico, ao contr\u00e1rio de uma API baseada em HTTP, em que as fun\u00e7\u00f5es de cliente e servidor exigem c\u00f3digos totalmente diferentes. Isso ajuda a simplificar o projeto e a implementa\u00e7\u00e3o, especialmente para a replica\u00e7\u00e3o ponto a ponto entre clientes.<\/p>\n Os conflitos ocorrem quando h\u00e1 concomitante<\/em> atualiza\u00e7\u00f5es para o mesmo<\/em> revis\u00e3o de documentos de v\u00e1rias fontes. Aqui, \"simult\u00e2neo\" significa \"entre replica\u00e7\u00f5es\": se um cliente ficar off-line por uma hora e voltar, todas as altera\u00e7\u00f5es feitas nesse cliente durante essa hora<\/em> seria efetivamente simult\u00e2neo \u00e0s altera\u00e7\u00f5es feitas por todos os outros clientes. Em um sistema distribu\u00eddo como esse, a simultaneidade n\u00e3o \u00e9 uma condi\u00e7\u00e3o de corrida rara, mas um fato da vida.<\/p>\n O Couchbase Mobile 2.0 oferece suporte a um novo livre de conflitos<\/em> modo. Os detalhes de como os conflitos s\u00e3o tratados na vers\u00e3o 2.0 est\u00e3o fora do escopo desta postagem do blog, mas voc\u00ea pode ler mais sobre isso aqui<\/a>. Em um alto n\u00edvel, quando o cliente encontra um conflito ao salvar uma revis\u00e3o, o retorno de chamada do resolvedor de conflitos associado ao documento \u00e9 chamado e a revis\u00e3o mesclada resultante \u00e9 usada. Assim, o documento nunca existe visivelmente em um estado conflituoso. Voc\u00ea pode ler mais sobre isso em uma pr\u00f3xima postagem do blog.<\/p>\n Durante a replica\u00e7\u00e3o, se o cliente n\u00e3o conseguir se conectar ao servidor ou se a conex\u00e3o com o servidor for perdida, o cliente tentar\u00e1 se reconectar usando um algoritmo de backoff exponencial, no qual ele espera cada vez mais tempo a cada nova tentativa.<\/p>\n O replicador cancelar\u00e1 seu cron\u00f4metro e tentar\u00e1 novamente de imediato se for notificado de que a conex\u00e3o de rede do dispositivo foi alterada (ele se conectou a uma rede WiFi ou celular). Por\u00e9m, devido \u00e0 forma como a rede IP funciona, o dispositivo s\u00f3 pode detectar altera\u00e7\u00f5es em suas pr\u00f3prias interfaces de rede, e n\u00e3o altera\u00e7\u00f5es que estejam ocorrendo em outros lugares no caminho para o servidor, nem mesmo no roteador WiFi local. Portanto, conectar o cabo ou a conex\u00e3o Ethernet novamente ao roteador n\u00e3o<\/em> ser\u00e1 detectado imediatamente. No entanto, o desligamento do roteador ser\u00e1 detectado, pois a interface de rede WiFi do dispositivo ficar\u00e1 inativa.<\/p>\n A detec\u00e7\u00e3o de uma conex\u00e3o perdida tamb\u00e9m pode ser problem\u00e1tica. Quando uma conex\u00e3o TCP est\u00e1 ociosa, nenhum pacote est\u00e1 sendo enviado em nenhuma dire\u00e7\u00e3o, portanto, nenhum dos pares pode saber se o outro foi desconectado abruptamente ou se uma conex\u00e3o ao longo do caminho entre eles foi cortada (por exemplo, se o cabo ou a Ethernet do roteador foi desconectado). Se o remetente n\u00e3o receber um pacote TCP ACK em resposta \u00e0 sua mensagem dentro de alguns segundos, ele saber\u00e1 que a conex\u00e3o caiu.<\/p>\n A arquitetura de replica\u00e7\u00e3o 2.0 no Couchbase Mobile 2.0 \u00e9 mais limpa, mais simples e mais eficiente em termos de recursos do que as vers\u00f5es anteriores baseadas em REST API\/HTTP.<\/p>\n Se tiver d\u00favidas ou coment\u00e1rios, deixe um coment\u00e1rio abaixo ou sinta-se \u00e0 vontade para entrar em contato comigo pelo Twitter @rajagp ou por e-mail priya.rajagopal@couchbase.com<\/a>. O F\u00f3runs do Couchbase<\/a> s\u00e3o outro bom lugar para entrar em contato com perguntas. In a distributed system, updates to a shared database from multiple clients will have to be synchronized. The goal of the replication process is to ensure that all the mobile clients and the server(s) have a consistent view of the […]<\/p>","protected":false},"author":1423,"featured_media":13873,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[1815,1821,7667,1810,2366],"tags":[2034,2004,1562,1782],"ppma_author":[8948],"class_list":["post-3919","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-best-practices-and-tutorials","category-couchbase-architecture","category-couchbase-lite","category-couchbase-mobile","category-sync-gateway","tag-blip","tag-couchbase-mobile-2-0","tag-replication","tag-websocket"],"acf":[],"yoast_head":"\n
\n![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2017\/08\/NoSQL_for_iOS_Platform.png\")
<\/p>\nNova arquitetura em camadas<\/h2>\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/02\/replication2.0.png\")
<\/p>\nCompatibilidade<\/h2>\n
Terminologia<\/h2>\n
\n
Modos de replica\u00e7\u00e3o<\/h2>\n
\n
Conceitos<\/h2>\n
\u00c1rvores de revis\u00e3o<\/h3>\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2017\/08\/revision-tree.png\")
<\/p>\nMudan\u00e7a<\/h3>\n
ID da sequ\u00eancia<\/h3>\n
Ponto de controle<\/h3>\n
O que a replica\u00e7\u00e3o realmente faz?<\/h2>\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2017\/08\/replication_video.gif\")
\nObserve que, se um documento for purgado<\/a> do banco de dados, o expurgo n\u00e3o ser\u00e1 replicado. A elimina\u00e7\u00e3o remove todos os rastros do documento do banco de dados.<\/p>\nO esquema de URL<\/h2>\n
\r\n\tws:\/\/sync-gw-address:4984\r\n wss:\/\/sync-gw-address:4984\r\n<\/code><\/pre>\nO protocolo<\/h2>\n
Estabelecimento de conex\u00e3o<\/h3>\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2017\/08\/handshake_websocket.png\")
<\/p>\n\n
_blipsync<\/code> relativo ao URL do banco de dados.<\/li>\nGerenciamento de pontos de controle<\/h3>\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2017\/08\/checkpoint-management.png\")
<\/p>\n\n
getCheckpoint<\/code> mensagem para o servidor a fim de determinar a \u00faltima ID de sequ\u00eancia de origem conhecida no servidor. A solicita\u00e7\u00e3o inclui:\n\n
getCheckpoint<\/code> inclui o \u00faltimo ponto de verifica\u00e7\u00e3o registrado para o cliente. O ponto de controle \u00e9 um objeto JSON criado e armazenado anteriormente pelo cliente; ele pode conter quaisquer dados que o cliente desejar, mas \u00e9 atualmente<\/em> do formul\u00e1rio:\n\n
setCheckpoint<\/code> para registrar a \u00faltima ID de sequ\u00eancia local que foi enviada e\/ou a \u00faltima ID de sequ\u00eancia remota que foi recebida.<\/li>\n<\/ol>\nReplica\u00e7\u00e3o por push<\/h3>\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/03\/push_replication_2-2.png\")
<\/p>\n\n
proposeChanges<\/code> para o servidor com uma matriz de mudan\u00e7a<\/code> correspondentes a cada revis\u00e3o atual que foi alterada. Isso inclui revis\u00f5es com t\u00famulos. A altera\u00e7\u00e3o em si \u00e9 codificada como uma matriz JSON aninhada e inclui:\n\n
proposeChanges<\/code> A solicita\u00e7\u00e3o inclui um objeto JSON que cont\u00e9m:\n\n
proposeChanges<\/code> solicita\u00e7\u00e3o.\n\n
rev<\/code> mensagem para cada uma das revis\u00f5es<\/em> solicitado na proposeChanges<\/code> resposta na etapa 2. O rev<\/code> O corpo da mensagem cont\u00e9m o documento no formato JSON, e os cabe\u00e7alhos da mensagem cont\u00eam metadados:\n\n
id<\/code> campo cujo valor \u00e9 o ID do documento cujo corpo est\u00e1 inclu\u00eddo<\/li>\nrev<\/code> campo com valor correspondente \u00e0 revis\u00e3o inclu\u00edda<\/li>\nsequ\u00eancia<\/code> com a ID de sequ\u00eancia da altera\u00e7\u00e3o<\/li>\nhist\u00f3rico<\/code> que inclui uma lista separada por v\u00edrgulas de IDs de revis\u00e3o desde o revis\u00e3o de ancestrais conhecidos<\/em> conforme especificado no mudan\u00e7as<\/code> resposta<\/li>\n<\/ul>\n<\/li>\nrev<\/code> mensagens foram enviadas, em cont\u00ednuo<\/em> o cliente aguarda a altera\u00e7\u00e3o do banco de dados local e retorna \u00e0 Etapa 1. Em um tiro<\/em> a conex\u00e3o \u00e9 desconectada e a replica\u00e7\u00e3o termina.<\/li>\n<\/ol>\nReplica\u00e7\u00e3o pull<\/h3>\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2017\/08\/pull-replication.png\")
<\/p>\n\n
subaltera\u00e7\u00f5es<\/code> mensagem para o servidor que inclui cabe\u00e7alhos:\n\n
desde<\/code> com o valor do campo ID de sequ\u00eancia remota<\/em><\/li>\ncont\u00ednuo<\/code> para indicar se est\u00e1 no modo cont\u00ednuo. Um valor de verdadeiro<\/code> indica que o cliente deseja ser notificado continuamente sobre as altera\u00e7\u00f5es.<\/li>\nlote<\/code> campo com valor que indica o n\u00famero m\u00e1ximo de altera\u00e7\u00f5es a serem enviadas em uma \u00fanica mensagem<\/li>\n<\/ul>\n<\/li>\nmudan\u00e7as<\/code> para o cliente com uma matriz de mudan\u00e7a<\/code> correspondentes a cada revis\u00e3o atual que foi alterada. Isso inclui revis\u00f5es com t\u00famulos. A altera\u00e7\u00e3o em si \u00e9 codificada como uma matriz JSON aninhada e inclui:\n\n
mudan\u00e7as<\/code> A solicita\u00e7\u00e3o inclui um objeto JSON que cont\u00e9m:\n\n
maxHistory<\/code> campo cujo valor \u00e9 o tamanho m\u00e1ximo do hist\u00f3rico que o cliente aceitar\u00e1<\/li>\nmudan\u00e7as<\/code> solicita\u00e7\u00e3o. Um valor nulo para uma entrada indica que o cliente n\u00e3o est\u00e1 interessado na revis\u00e3o correspondente.<\/li>\n<\/ul>\n<\/li>\nrev<\/code> mensagem para cada uma das revis\u00f5es<\/em> solicitado na mudan\u00e7as<\/code> resposta na etapa 3. O rev<\/code> O corpo da mensagem cont\u00e9m o documento no formato JSON, e os cabe\u00e7alhos da mensagem cont\u00eam metadados:\n\n
id<\/code> campo cujo valor corresponde ao ID do documento cujo corpo est\u00e1 inclu\u00eddo<\/li>\nrev<\/code> campo com valor correspondente \u00e0 revis\u00e3o inclu\u00edda<\/li>\nsequ\u00eancia<\/code> com o valor correspondente \u00e0 ID de sequ\u00eancia da altera\u00e7\u00e3o<\/li>\nhist\u00f3rico<\/code> que inclui uma lista separada por v\u00edrgulas de IDs de revis\u00e3o desde o revis\u00e3o de ancestrais conhecidos<\/em> conforme especificado em mudan\u00e7as<\/code> resposta<\/li>\n<\/ul>\n<\/li>\nmudan\u00e7as<\/code> para indicar que n\u00e3o h\u00e1 mais altera\u00e7\u00f5es a serem enviadas.<\/li>\nComo lidar com conflitos<\/h2>\n
Perda de conex\u00e3o com o servidor<\/h2>\n
\n
O que vem a seguir<\/h2>\n
\nPor fim, um agradecimento especial a Jens Alfke (https:\/\/github.com\/snej<\/a>), por seu feedback.<\/p>","protected":false},"excerpt":{"rendered":"