Você tem várias opções diferentes ao escolher a topologia para sua implementação que incorpora replicação multimaster.
Uma infraestrutura de grade de dados de replicação é um gráfico conectado de domínios de serviço de catálogo com links bidirecionais entre eles. Com um link, dois domínios de serviço de catálogo podem comunicar as mudanças de dados. Por exemplo, a topologia mais simples é um par de domínios de serviço de catálogo com um único link entre eles. Os domínios de serviço de catálogo são nomeados em ordem alfabética: A, B, C e assim por diante, a partir da esquerda. Um link pode cruzar uma rede de longa distância (WAN), expandindo-se para grandes distâncias. Mesmo se o link for interrompido, os dados ainda poderão ser alterados em qualquer domínio de serviço de catálogo. A topologia reconcilia as mudanças quando o link reconecta os domínios de serviço de catálogo. Os links tentarão automaticamente reconectar se a conexão com a rede for interrompida.
Depois que você configura os links, o produto tenta primeiro tornar cada domínio de serviço de catálogo idêntico. Em seguida, o eXtreme Scale tenta manter as condições idênticas conforme as mudanças ocorrem em qualquer domínio de serviço de catálogo. O objetivo é que cada domínio de serviço de catálogo seja um espelho exato de qualquer outro domínio de serviço de catálogo conectado pelos links. Os links de replicação entre os domínios de serviço de catálogo ajudam a assegurar que as mudanças feitas em um domínio de serviço de catálogo sejam copiadas para os outros domínios de serviço de catálogo.
Embora esta seja uma implementação muito simples, uma topologia em linha demonstra algumas qualidades dos links. Primeiro, não é necessário que um domínio de serviço de catálogo esteja conectado diretamente a outro domínio de serviço de catálogo para receber as mudanças. O domínio de serviço de catálogo B extrai as mudanças do domínio de serviço de catálogo A. O domínio de serviço de catálogo C recebe mudanças do domínio de serviço de catálogo A por meio do domínio de serviço de catálogo B, que conecta os domínios de serviço de catálogo A e C. De modo semelhante, o domínio de serviço de catálogo D recebe mudanças dos outros domínios de serviço de catálogo por meio do domínio de serviço de catálogo C. Essa capacidade difunde o carregamento de distribuição de mudanças para fora da origem das mudanças.
As topologias em anel são um exemplo de uma topologia mais resiliente. Quando um domínio de serviço de catálogo ou um único link falha, os domínios de serviço de catálogo sobreviventes ainda podem obter as mudanças. Os domínios de serviço de catálogo se deslocam ao redor do anel, longe da falha. Cada domínio de serviço de catálogo tem no máximo dois links para outros domínios de serviço de catálogo, não importa o tamanho da topologia em anel. A latência para propagar as mudanças pode ser grande. As mudanças a partir de um domínio de serviço de catálogo particular podem precisar percorrer vários links antes que todos os domínios de serviço de catálogo possuam as mudanças. Uma topologia em linha tem a mesma característica.
Também é possível implementar uma topologia em anel mais sofisticada, com um domínio de serviço de catálogo raiz no centro do anel. O domínio de serviço de catálogo raiz funciona como o ponto central da reconciliação. Os outros domínios de serviço de catálogo agem como pontos remotos de reconciliação para mudanças que ocorrem no domínio de serviço de catálogo raiz. O domínio de serviço de catálogo raiz pode arbitrar mudanças entre os domínios de serviço de catálogo. Se uma topologia em anel contiver mais de um anel ao redor de um domínio de serviço de catálogo raiz, o domínio de serviço de catálogo poderá arbitrar apenas as mudanças entre o anel mais interno. No entanto, os resultados da arbitragem se difundem por todos os domínios de serviço de catálogo nos outros anéis.
Com uma topologia hub-and-spoke, as mudanças percorrem um domínio de serviço de catálogo hub. Como o hub é apenas o domínio de serviço de catálogo intermediário especificado, as topologias hub-and-spoke possuem latência inferior. O domínio de serviço de catálogo hub é conectado a cada domínio de serviço de catálogo spoke por meio de um link. O hub distribui as mudanças entre os domínios de serviço de catálogo. O hub atua como um ponto de reconciliação de colisões. Em um ambiente com uma alta taxa de atualização, o hub pode precisar executar em mais hardware do que os spokes devem permanecer sincronizados. O WebSphere eXtreme Scale é projetado para escalar linearmente, o que significa que é possível aumentar o hub, conforme necessário, sem dificuldade. No entanto, se o hub falhar, as mudanças não são distribuídas até ele ser reiniciado. Quaisquer mudanças nos domínios de serviço de catálogo spoke serão distribuídas depois que o hub for reconectado.
Também é possível usar uma estratégia com clientes totalmente replicados, uma variação de topologia que usa um par de servidores sendo executados como um hub. Cada cliente cria uma grade de dados autocontida de contêiner único com um catálogo na JVM do cliente. Um cliente usa a grade de dados para se conectar com o catálogo do hub. Esta conexão faz com que o cliente seja sincronizado com o hub assim que o cliente estabelecer uma conexão com o hub.
Todas as mudanças feitas pelo cliente são locais para o cliente e são replicadas de forma assíncrona para o hub. O hub age como um domínio de serviço de catálogo de arbitragem, distribuindo mudanças para todos os clientes conectados. A topologia de clientes totalmente replicados fornece um cache L2 confiável para um mapeador relacional de objeto, como OpenJPA. As mudanças serão distribuídas rapidamente entre as JVMs de cliente por meio do hub. Se o tamanho do cache puder estar contido no espaço de heap disponível, a topologia será uma arquitetura confiável para este estilo de L2.
Use diversas partições para escalar o domínio de serviço de catálogo hub em diversas JVMs, se necessário. Como todos os dados ainda devem se ajustar em uma única JVM de cliente, diversas partições aumentam a capacidade do hub para distribuir e arbitrar as mudanças. No entanto, ter diversas partições não altera a capacidade de um único domínio de serviço de catálogo.
Também é possível usar uma árvore direcionada acíclica. Uma árvore acíclica não tem ciclos ou loops e uma configuração direcionada limita a criação de links apenas entre pais e filhos. Essa configuração é útil para topologias que possuem vários domínios de serviço de catálogo. Nestas topologias, não é viável ter um hub central conectado a cada spoke possível. Esse tipo de topologia também pode ser útil quando você deve incluir domínios de serviço de catálogo filhos sem atualizar o domínio de serviço de catálogo raiz.
Uma topologia em árvore ainda pode ter um ponto central de reconciliação no domínio de serviço de catálogo raiz. O segundo nível pode ainda funcionar como um ponto de reconciliação remoto para mudanças que ocorrem no domínio de serviço de catálogo abaixo dele. O domínio de serviço de catálogo raiz pode arbitrar as mudanças entre os domínios de serviço de catálogo apenas no segundo nível. Também é possível usar N árvores, cada uma delas possuindo N filhos em cada nível. Cada domínio de serviço de catálogo se conecta com n links.
Essa variação de topologia envolve um par de servidores sendo executados como um hub. Cada cliente cria uma grade de dados autocontida de contêiner único com um catálogo na JVM do cliente. Um cliente usa a grade de dados para se conectar com o catálogo do hub, fazendo com que o cliente seja sincronizado com o hub assim que estabelecer uma conexão com o hub.
Todas as mudanças feitas pelo cliente são locais para o cliente e são replicadas de forma assíncrona para o hub. O hub age como um domínio de serviço de catálogo de arbitragem, distribuindo mudanças para todos os clientes conectados. A topologia de clientes totalmente replicada fornece um bom cache L2 para um mapeador relacional de objeto, como OpenJPA. As mudanças serão distribuídas rapidamente entre as JVMs de cliente por meio do hub. Contanto que o tamanho do cache possa estar contido no espaço de heap disponível dos clientes, esta topologia será uma boa arquitetura para este estilo de L2.
Use diversas partições para escalar o domínio de serviço de catálogo hub em diversas JVMs, se necessário. Como todos os dados ainda devem se ajustar a uma única JVM de cliente, usar diversas partições aumenta a capacidade do hub para distribuir e arbitrar mudanças, mas não altera a capacidade de um único domínio de serviço de catálogo.