Tair (Redis OSS-compatible) oferece instâncias com múltiplas réplicas baseadas em uma arquitetura de cluster. Também é possível ativar a divisão de leitura e escrita nessa 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 você a selecionar aquele que melhor se adapta à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 conectá-las da mesma forma que instâncias de arquitetura padrão. O nó proxy encaminha automaticamente as solicitações do cliente para o shard de dados correto. Além disso, fornece recursos avançados, como cache de hotkey e failover automático. Para obter 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 com 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 que prestam services e garantem redundância para recuperação de desastres. |
|
Shard de dados |
Cada shard de dados utiliza 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) |
Caso um nó mestre falhe, o sistema executa automaticamente o failover para um nó de réplica em até 30 segundos, garantindo a disponibilidade do service e a confiabilidade dos dados. Se sua 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ó. Isso evita aumentos de latência causados pelo acesso da aplicação entre zonas. |
Ativar divisão de leitura e escrita
A arquitetura de cluster cloud-native no modo proxy também suporta a divisão de leitura e escrita. Ative este recurso quando o tráfego de leitura for alto e exceder os limites de desempenho do nó mestre. Para obter mais informações, consulte Enable read/write splitting for a cluster instance.
Modo de conexão direta
No modo de conexão direta, você se conecta ao cluster da mesma maneira que faria com 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 Redis Cluster para acessar todos os shards de dados. A arquitetura de cluster no modo de conexão direta suporta configurações com múltiplas réplicas , mas não suporta divisão de leitura e escrita. A figura a seguir mostra a arquitetura de service deste 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 escalar a capacidade de armazenamento até 16 TB (64 GB × 256 shards). Isso atende às demandas de aplicações em crescimento.
-
Altas cargas de solicitação
A arquitetura padrão não consegue lidar com altas cargas de solicitação. Uma implantação com múltiplos shards é necessária 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 para a arquitetura de cluster.
NotaApenas instâncias de cluster cloud-native no modo proxy suportam divisão de leitura e escrita. Para usar esse recurso, migre 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 intensivas em throughput
Diferentemente da arquitetura padrão, a arquitetura de cluster permite escalar linearmente o throughput adicionando mais shards. Isso oferece melhor suporte para leitura de hot data e gerenciamento de cargas de trabalho com alto throughput.
-
Aplicações com poucas operações multi-key
Como o cluster utiliza uma arquitetura distribuída, as operações em múltiplas chaves exigem que todas as chaves residam no mesmo slot. Isso restringe certas operações multi-key. Para obter 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, configure um nó mestre e um nó de réplica na zona primária, além de outro nó de réplica na zona secundária. Isso melhora a confiabilidade da recuperação de desastres e evita picos de latência decorrentes do acesso entre zonas após um failover.
Notas de uso
Uma instância de cluster cloud-native não pode usar o modo proxy e o modo de conexão direta simultaneamente. Recomendamos o uso do modo proxy.
A arquitetura de cluster Classic suporta apenas configurações dupla réplica e não oferece suporte à 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 de conexão direta para modo proxy. Não há opção disponível no console para essa troca. Caso precise alterar, crie uma nova instância de cluster no modo proxy, utilize o Data Transmission Service (DTS) para migrar os dados da instância original para a nova, verifique a consistência dos dados e, em seguida, atualize 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 chave Read/Write Splitting e 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 aprimorado do kernel: A arquitetura de cluster do Tair inclui diversas otimizações de kernel, tais como:
Recuperação de desastres mais rápida, sem tempestades de broadcast gossip.
Durante o scale-in ou scale-out, o sistema reequilibra automaticamente os dados dos shards com impacto mínimo nos seus services.
Suporte nativo a um grande número de conexões de curta duração.
O&M simplificado: Comparado a 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 várias soluções de alta disponibilidade e recuperação de desastres. Para obter mais informações, consulte Comparison between Tair and self-managed Redis.
Suporte ao modo proxy: As instâncias de cluster do Tair disponibilizam um modo proxy opcional. Esse modo fornece nós proxy capazes de traduzir a arquitetura, permitindo que você utilize 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 obter mais informações, consulte Tair Proxy features.
Alterações de código após upgrade
Ao fazer upgrade para uma instância de cluster no modo proxy, não é necessário modificar seu código. O proxy node abstrai a complexidade subjacente do cluster, permitindo que você use a instância como faria com uma instância padrão. Isso reduz significativamente o custo de modificação da sua aplicação.
Caso faça upgrade para uma instância de cluster no modo de conexão direta, modifique o código do pool de conexões para utilizar um cliente compatível com Redis Cluster.
Também é fundamental compreender e seguir as regras para comandos multi-key (cross-slot), transações e scripts Lua na arquitetura de cluster. Para obter mais informações, consulte Command limitations for cluster architecture.
Rebalanceamento automático de dados
Sim. Ao fazer upgrade 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 dos dados e realiza o rebalanceamento. Nenhuma intervenção manual é necessária.
Além disso, o modo proxy suporta seamless scaling. O modo de conexão direta também pode alcançar dimensionamento contínuo, desde que seu cliente lide corretamente com os redirecionamentos MOVED.