O Tair (Redis OSS-compatible) oferece instâncias de múltiplas réplicas com arquitetura de cluster. Também é possível ativar a divisão de leitura e escrita para essa arquitetura. Esse design supera o gargalo de thread única do Redis open source para atender às demandas de alta capacidade e desempenho das aplicações modernas. A arquitetura de cluster suporta dois modos de conexão: modo proxy e modo de conexão direta. Este tópico descreve ambos os modos para ajudar na escolha do mais adequado às necessidades do seu negócio.
Modo proxy (recomendado)
O modo proxy simplifica a conexão e o uso de instâncias de cluster, permitindo a conexão da mesma forma que em instâncias de arquitetura padrão. O nó proxy encaminha automaticamente as solicitações do cliente para o shard de dados correto. Esse nó também oferece recursos avançados, como cache de hotkey e failover automático. Para mais informações, consulte Tair Proxy features.
As figuras e tabelas a seguir descrevem a arquitetura de service e os componentes do modo proxy.
Múltiplas réplicas
Arquitetura de service de um cluster de múltiplas réplicas no modo proxy
Componentes da arquitetura de cluster no modo proxy
|
Componente |
Descrição |
|
Nó proxy |
Encaminha as solicitações do cliente para os shards de dados apropriados. Um cluster contém vários nós proxy para fornecer services e garantir redundância para recuperação de desastres. |
|
Shard de dados |
Cada shard de dados usa uma arquitetura de alta disponibilidade com um nó mestre e de um a quatro nós de réplica implantados em servidores físicos diferentes. É possível implantar nós de réplica em uma zona de disponibilidade secundária. O uso de múltiplos nós de réplica melhora as capacidades de recuperação de desastres e reduz o risco de perda de dados. |
|
Alta disponibilidade (HA) |
Se um nó mestre falhar, o sistema faz failover automático para um nó de réplica em até 30 segundos para garantir a disponibilidade do service e a confiabilidade dos dados. Se a instância estiver implantada em duas zonas de disponibilidade e existir um nó de réplica na zona primária, o sistema priorizará o failover para esse nó de réplica. Isso evita o aumento da latência no acesso à aplicação entre zonas. |
Ativar divisão de leitura e escrita
A arquitetura de cluster cloud-native no modo proxy também suporta divisão de leitura e escrita. Ative esse recurso quando o tráfego de leitura for intenso e exceder os limites de desempenho do nó mestre. Para mais informações, consulte Ative a divisão de leitura e escrita para uma instância de cluster.
Modo de conexão direta
No modo de conexão direta, você se conecta ao cluster da mesma forma que a um Redis Cluster nativo. Na conexão inicial, o DNS resolve o endereço de conexão do cliente para o endereço IP virtual (VIP) de um shard de dados aleatório. Em seguida, o cliente usa o protocolo do Redis Cluster para acessar todos os shards de dados. A arquitetura de cluster no modo de conexão direta suporta configurações de múltiplas réplicas , mas não suporta divisão de leitura e escrita. A figura a seguir mostra a arquitetura de service desse modo.
Arquitetura de service de um cluster no modo de conexão direta
O modo de conexão direta difere significativamente do modo proxy. Para notas de uso e exemplos de conexão, consulte Use direct connection mode to connect to an instance.
Casos de uso
-
Grandes volumes de dados
Em comparação com a arquitetura padrão, a arquitetura de cluster permite dimensionar a capacidade de armazenamento em até 16 TB (64 GB × 256 shards). Isso atende às demandas de aplicações em crescimento.
-
Altas cargas de solicitações
A arquitetura padrão não suporta altas cargas de solicitações. É necessária uma implantação com múltiplos shards para superar o gargalo de desempenho de um único shard.
Se o nó mestre estiver sobrecarregado com solicitações de leitura, ative a divisão de leitura e escrita na arquitetura de cluster.
NotaApenas instâncias de cluster cloud-native no modo proxy suportam a divisão de leitura e escrita. Para usar esse recurso, migre os dados de outros tipos de instância criando uma nova instância de cluster e sincronizando os dados por meio do Data Transmission Service (DTS).
-
Aplicações com uso intensivo de throughput
Em comparação com a arquitetura padrão, a arquitetura de cluster permite o dimensionamento linear do throughput ao adicionar mais shards. Isso oferece melhor suporte para a leitura de hot data e o processamento de cargas de trabalho com alto throughput.
-
Aplicações com poucas operações de múltiplas chaves
Como o cluster usa uma arquitetura distribuída, as operações em múltiplas chaves exigem que todas as chaves estejam no mesmo slot. Isso restringe determinadas operações de múltiplas chaves. Para mais informações, consulte Command restrictions for cluster instances and read/write splitting instances.
-
Aplicações sensíveis à latência
Para uma instância implantada em duas zonas de disponibilidade, adicione nós de réplica à zona de disponibilidade primária. Por exemplo, mantenha um nó mestre e um nó de réplica na zona primária, e outro nó de réplica na zona secundária. Isso melhora a confiabilidade da recuperação de desastres e evita picos de latência no acesso entre zonas após um failover.
Notas de uso
Uma instância de cluster cloud-native não pode usar os modos proxy e de conexão direta simultaneamente. Recomendamos o uso do modo proxy.
A arquitetura de cluster Classic suporta apenas configurações de réplica dupla, e não suporta a divisão de leitura e escrita.
Uma instância de cluster cloud-native não suporta a alteração direta do modo de conexão direta para o modo proxy. Não há opção para essa alteração no console. Se precisar alterar, crie uma nova instância de cluster no modo proxy, use o Data Transmission Service (DTS) para migrar os dados da instância original para a nova instância, verifique a consistência dos dados e, em seguida, altere o endpoint de conexão da sua aplicação para o endpoint do modo proxy da nova instância.
Uma instância de cluster Classic fornece o modo proxy por padrão. Se precisar usar o modo de conexão direta, ative-o manualmente no console.
Modificar configurações do cluster
Para adicionar ou remover nós de réplica, acesse a página Node Management da sua instância e clique em Modify.
Para adicionar réplicas de leitura, acesse a página Node Management da sua instância, ative a opção Read/Write Splitting e, em seguida, clique em Modify para adicionar as réplicas de leitura.
Para adicionar shards, acesse a página de detalhes da instância e selecione no canto superior direito.
Para alterar as especificações dos shards, acesse a página de detalhes da instância e selecione no canto superior direito.
FAQ
TairQual é a diferença entre a arquitetura de cluster e o Redis Cluster open source?
Em comparação com o Redis Cluster open source, a arquitetura de cluster do Tair (Redis OSS-compatible) oferece as seguintes vantagens em segurança, desempenho do kernel, balanceamento de carga e escalabilidade:
-
Desempenho de kernel aprimorado: A arquitetura de cluster do Tair inclui inúmeras otimizações de kernel, como:
Recuperação de desastres mais rápida, sem tempestades de broadcast gossip.
Durante o scale-in ou scale-out, o sistema rebalanceia automaticamente os dados dos shards com impacto mínimo nos seus services.
Suporte nativo para um grande número de conexões de curta duração.
O&M simplificado: Em comparação com bancos de dados Redis autogerenciados em servidores, as instâncias de cluster do Tair oferecem controle de acesso multidimensional, dimensionamento flexível, métricas de monitoramento abrangentes e diversas soluções de alta disponibilidade e recuperação de desastres. Para mais informações, consulte Comparison between Tair and self-managed Redis.
Suporte ao modo proxy: As instâncias de cluster do Tair oferecem um modo proxy opcional. Esse modo fornece nós proxy que traduzem a arquitetura, permitindo o uso de uma instância de arquitetura de cluster de forma muito semelhante a uma instância padrão. Os nós proxy também suportam balanceamento de carga, roteamento de solicitações, gerenciamento de tráfego de réplicas de leitura, cache de metadados de hotkey e múltiplos bancos de dados (DBs) na arquitetura de cluster. Para mais informações, consulte Tair Proxy features.
Alterações de código após a atualização
Ao atualizar para uma instância de cluster no modo proxy, não é necessário modificar o código. O nó proxy abstrai a complexidade subjacente do cluster, permitindo o uso da instância como uma instância padrão. Isso reduz significativamente o custo de modificação da sua aplicação.
Ao atualizar para uma instância de cluster no modo de conexão direta, é necessário modificar o código do pool de conexões para usar um cliente compatível com o Redis Cluster.
Também é necessário compreender e seguir as regras para comandos de múltiplas chaves (cross-slot), transações e scripts Lua na arquitetura de cluster. Para mais informações, consulte Command limitations for cluster architecture.
Rebalanceamento automático de dados
Sim. Ao atualizar da arquitetura padrão para a arquitetura de cluster, ou ao adicionar ou remover shards em uma instância de cluster, o service analisa automaticamente a distribuição de dados e os rebalanceia. Não é necessária intervenção manual.
Além disso, o modo proxy suporta seamless scaling. O modo de conexão direta também pode alcançar um dimensionamento sem interrupções se o cliente lidar corretamente com os redirecionamentos MOVED.