Considerações Sobre o Carregador em uma Topologia Multimestre

Quando estiver usando os carregadores em uma topologia multimestre, você deve considerar a possibilidade de colisão e desafios de manutenção das informações de revisão. A grade de dados mantém as informações de revisão sobre os itens nela para que colisões possam ser detectadas quando outros shards primários na configuração gravarem entradas na grade de dados. Quando as entradas são incluídas a partir de um carregador, essas informações de revisão não são incluídas e a entrada assume uma nova revisão. Como a revisão da entrada parece ser uma nova inserção, uma colisão false poderá ocorrer se outro shard primário também alterar esse estado ou obtiver as mesmas informações a partir de um carregador.

As mudanças na replicação chamam o método get no carregador com uma lista das chaves que ainda não estão na grade de dados, porém serão alteradas durante a transação da replicação. Quando a replicação ocorre, essas entradas são entradas de colisão. Quando as colisões são definidas e a revisão é aplicada, uma atualização em lote é chamada no carregador para aplicar as mudanças no banco de dados. Todos os mapas que foram alterados na janela de revisão são atualizados na mesma transação.

Desafio do Pré-Carregamento

Considere uma topologia de dois datacenters, com o datacenter A e o datacenter B. Ambos os datacenters possuem bancos de dados independente, mas apenas o datacenter A possui uma grade de dados em execução. Quando você estabelece um link entre os datacenters por uma configuração multimestre, as grades de dados no datacenter A começam a enviar dados para as novas grades de dados do datacenter B, causando uma colisão com cada entrada. Outro maior problema que ocorre é com os dados que estão no banco de dados do datacenter B, mas não no banco de dados no datacenter A. Essas linhas não são preenchidas e definidas, resultando em inconsistências que não são resolvidas.

Solução para o Desafio de Pré-Carregamento

Como os dados que residem apenas no banco de dados não podem ter revisões, a grade de dados sempre deve ser pré-carregada completamente a partir do banco de dados local antes de estabelecer o link multimestre. Em seguida, ambas as grades de dados podem revisar e definir os dados, eventualmente chegando a um estado consistente.

Desafio de Cache Disperso

Com um cache disperso, o primeiro aplicativo tenta localizar os dados na grade de dados. Se os dados não estiverem na grade de dados, eles serão procurados no banco de dados usando o carregador. As entradas são despejadas da grade de dados periodicamente para manter um tamanho de cache pequeno.

Este tipo de cache pode ser problemático em um cenário de configuração multimestre porque as entradas dentro da grade de dados possuem metadados de revisão que ajudam a detectar quando colisões ocorrem e qual lado fez as mudanças. Quando os links entre os datacenters não estiverem funcionando, um datacenter pode atualizar uma entrada e depois, eventualmente, atualizar o banco de dados e invalidar a entrada na grade de dados. Quando o link é recuperado, os datacenters tentam sincronizar as revisões entre si. No entanto, como o banco de dados foi atualizado e a entrada da grade de dados foi invalidada, a mudança é perdida a partir da perspectiva do datacenter que ficou inativo. Como resultado, os dois lados da grade de dados estão fora de sincronização e não estão consistentes.

Solução para o Desafio de Cache Disperso

Topologia Hub e Spoke:

É possível executar o carregador apenas no hub de uma topologia de hub e spoke, mantendo a consistência dos dados, enquanto a escala da grade de dados é ajustada. No entanto, se você estiver considerando essa implementação, observe que os carregadores podem permitir que a grade de dados seja parcialmente carregada, significando que um evictor foi configurado. Se o spokes de sua configuração forem caches dispersos, mas não possuírem nenhum carregador, quaisquer perdas de cache não terão como recuperar dados do banco de dados. Devido a esta restrição, você deve usar uma topologia de cache totalmente preenchida com uma configuração de hub e spoke.

Invalidações e Despejo

Uma invalidação cria inconsistência entre a grade de dados e o banco de dados. Os dados podem ser removidos da grade de dados, seja de modo programático ou com o despejo. Ao desenvolver seu aplicativo, você deve estar ciente de que a manipulação de revisão não replica mudanças que são invalidadas, resultando em inconsistências entre os shards primários.

Os eventos de invalidação não são mudanças de estado de cache e não resultam em replicação. Todos os evictors configurados são executados independentemente de outros evictors na configuração. Por exemplo, você pode ter um evictor configurado para um limite de memória em um domínio do serviço de catálogo, e um tipo diferente de evictor menos agressivo no outro domínio do serviço de catálogo vinculado. Quando as entradas da grade dedados são removidas devido à política de limite de memória, as entradas no outro domínio do serviço de catálogo não são afetadas.

Atualizações do banco de dados e invalidação da grade de dados

Problemas ocorrem quando o banco de dados é atualizado diretamente no plano de fundo ao chamar a invalidação na grade de dados para as entradas atualizadas em uma configuração multimestre. Esse problema ocorre porque a grade de dados não pode replicar a mudança para os outros shards primários até que algum tipo de acesso ao cache mova a entrada para a grade de dados.

Diversos Gravadores para um Único Banco de Dados Lógico

Quando um banco de dados único é usado com diversos shards primários conectados por meio de um carregador, isso pode resultar em conflitos transacionais. Sua implementação do carregador deve manipular especialmente esses tipos de cenários.

Espelhando Dados Usando Replicação Multimestre

É possível configurar bancos de dados independentes que estão conectados a domínios do serviço de catálogo independentes. Nessa configuração, o carregador pode enviar mudanças de um datacenter para o outro.